However my biggest gripe with Apple Maps in Poland is that Siri does not understand Polish and cannot be told to navigate to a Polish address. It just can’t understand the street and city names :(

Btw: I haven’t counted the times Google Maps wanted me to go through the worst possible traffic jam (where the traffic jam was not visible on the map) or a closed road. I guess it just happens with every navigation system that errors happen.

If the signal has a carrier (like in AM or FM) or some other regular pattern (e.g. digital signal) then the typical the way to recover it from under the noise floor is to use a narrow-band PLL.

I’m experimenting with it right now and just found that a quartz/ceramic oscillator pulled by a varicap controlled by a PLL gives pretty good results - low phase noise, good noise rejection and ability to recover the carrier from a very noisy signal. But for that to work, the signal has to be shifted to a constant frequency through heterodyning first.

There are so many options and all are very cool to explore.

Yet, I still need to wait about 1 second (!) after each key press when buying a parking ticket and the machine wants me to enter my license plate number. The latency is so huge I initially thought the machine was broken. I guess it’s not the chip problem but terrible programming due to developers thinking they don’t need to care about performance because their chip runs in megahertz.

And it pops up in the profiler immediately with a nice stack trace showing where it rooted from. Then you fix it by e.g. moving cleanup to background to unlock this thread, not cleaning it at all (e.g. if the process dies anyway soon), or just remodel the data structure to not have so many tiny objects, etc.

Essentially this is exactly "way more deterministic and easier to understand and model". No-one said it is free from performance traps.

> And free itself can be expensive.

The total amortized cost of malloc/free is usually much lower than the total cost of tracing; unless you give tracing GC a horrendous amount of additional memory (> 10x of resident live set).

malloc/free are especially efficient when they are used for managing bigger objects. But even with tiny allocations like 8 bytes size (which are rarely kept on heap) I found modern allocators like mimalloc or jemalloc easily outperformed modern GCs of Java (in terms of CPU cycles spent, not wall clock).

Such a simple radio can be a gateway drug to a very complex and deep hobby. In my case it went like that:

1. Built a simple radio

2. Could hardly hear anything, need to add an amplifier to it 3. Now it’s better but captures a lot of noise

4. Design a filter to select just that one station

5. Now I want to listen to more stations.

6. Ugh, you can’t design a good filter with variable frequency. Enter the superheterodyne world.

7. Now finally got something that resembles a tunable AM radio, but it kinda whistles / hums a lot. Ah, so the mirror image is a real thing?!

8. Need a higher IF to be able to better reject the image before the mixer. Ok, let’s make a double conversion superhet then.

9. Buy a set of ceramic filters and play with them to get the best selectivity.

10. Try to add more amplification only to learn if you go too far you get an oscillator instead of an amplifier.

11. The sound level is not stable. Add AGC.

12. Pick up some stations from 5000+ km away. Nice. But there is some weird distortion. Oh, I’ve been a culprit of frequency selective fading…

Fast forward and now I’m building a PLL synchronized AM product demodulator with a squaring loop for carrier recovery.

Fun. Lot of fun! Wholeheartedly recommend!

An obvious advantage of doing it that way is you don’t need any runtime/OS-level support. Eg your runtime doesn’t need to even have a concept of threads. It works on bare metal embedded.

Another advantage is that it’s fully cooperative model. No magic preemption. You control the points where the switch can happen, there is no magic stuff suddenly running in background and messing up the state.