Thread

A software thing I built: GPS on a 25MHz 486-SX

71 points · 23 comments · JPLeRouzic

Loading the complete thread in the background. This saved snapshot is available now. Refresh

JPLeRouzic · 1789537712 · focus · HN ↗
The author says:
"It used Voronoi Cells and reduced most math to 8- and 16-bit integer calculations with one or two single-precision floating-point calculations."
I wonder if it can be used to speed up LLM inference.
1. Neywiny · 1789555892 · focus · HN ↗
  That's what quantization and stuff is, basically. So yes. Been done for years on all neural net types not just LLMs.
  1. JPLeRouzic · 1789558875 · focus · HN ↗
    Please can you provide some links to intro level articles?
    Neywiny · 1789593780 · focus · HN ↗
    This seems worth the read but I didn't dig too deep <a href="https://medium.com/@sergiopr89/float-point-quantization-the-maths-behind-it-explained-for-everyone-fc674d313d67" rel="nofollow">https://medium.com/@sergiopr89/float-point-quantization-the-...
  2. 4RealFreedom · 1789564954 · focus · HN ↗
    Quantization compresses the model’s parameters and you lose precision in the process. My understanding from the article was that precision wasn't lost - 'It actually had higher resolution than Extended-precision floating point math!'. The point of quantization is to make the model smaller to fit into available ram. I think the OP is referring to computation which is a different beast.
    Neywiny · 1789572346 · focus · HN ↗
    You may be conflating distillation, which may be a fault of other people getting it wrong. Going from floating to fixed point doesn't change precision or size. It changes representation. For example, if all your values are between 0 and 1 or -1 and 1, you're not using the entire range of a standard IEEE float. If you instead use Q31 format, you get basically 31 instead of 23 bits of mantissa. So it's an increase in precision if and only if you can basically stretch your sub-range that you were using over a larger range of bit representations. You have to think of the total number of values. 32 bit is 4 billion. 80 bit extended precision is a lot more than that. But he didn't say I think what his fixed point bit width was. That's what matters.
    Now maybe you don't need to represent 1/2^32 in precision. Maybe you just need to know to 1/8th. That's where you can quantize to a lower precision to save space.
    But if you start with 32 bit float and quantize to 32 bit fixed, I struggle to think how that saves storage.
    4RealFreedom · 1789594279 · focus · HN ↗
    I wasn't conflating distillation. You are basically repeating what I said - you're describing quantization. The OP was talking about changing the computation. The article says the 8- and 16-bit integer approach actually had higher resolution than the floating-point approach. You said we already had quantization to do this but quantization isn't what the OP was describing.
razashaikh92 · 1789540667 · focus · HN ↗
Cool software keep it up
svag · 1789543847 · focus · HN ↗
I believe the library mentioned in the article should be this one <a href="https://geodyssey.github.io/overview/overview.html" rel="nofollow">https://geodyssey.github.io/overview/overview.html and here <a href="https://www.lukatela.com/geodyssey/" rel="nofollow">https://www.lukatela.com/geodyssey/
SillyUsername · 1789544809 · focus · HN ↗
I built one, tracking fleet vehicles with a custom box, using tiled maps, on behalf of Vodafone, back in 2002. I still remember I wrote a basic trans-mercator library too!
Of course Mercator projection may go out of fashion soon <a href="https://www.independent.co.uk/news/world/africa/world-map-equal-earth-projection-un-mercator-b3050761.html" rel="nofollow">https://www.independent.co.uk/news/world/africa/world-map-eq... :)
Hope I'm called back to update the library ;)
1. philipallstar · 1789554488 · focus · HN ↗
  Probably not if navigation is involved:
  > This is why most online mapping platforms like Google Maps or Apple Maps rely on a variation of the Mercator projection to provide directions. Using the Equal Earth projection for navigation would not be as effective as the Mercator projection.
  > What the UN did was endorse the broader message that Equal Earth is a fairer projection that more equitably displays the true size of the Earth’s land
  You are right about this though - it's a moral fashion. Who cares about land size on a map unless you've got the priorities and advancement of a prehistoric king? People with plenty of spare time who constantly talk in an echo chamber[0], that's who.
  [0] <a href="https://un.org/en" rel="nofollow">https://un.org/en
guenthert · 1789545640 · focus · HN ↗
"real-time GPS-driven moving map display"
Not the IMHO more interesting analog tech which lifts signals out of thermal noise.
1. JPLeRouzic · 1789558778 · focus · HN ↗
  That looks interesting, what technology "lifts signals out of thermal noise"?
  1. FrankPetrilli · 1789561090 · focus · HN ↗
    [dead]
  2. y04nn · 1789564028 · focus · HN ↗
    DSSS, direct sequence spread spectrum, used for encoding GPS signal
  3. peaseagee · 1789564797 · focus · HN ↗
    Spread spectrum, it's pretty magical.
  4. JPLeRouzic · 1789570315 · focus · HN ↗
    Thanks @FrankPetrilli.
  5. squantor · 1789586390 · focus · HN ↗
    I found this an interesting writeup on the technologies needed to receive GPS signals:
    <a href="http://www.aholme.co.uk/GPS/Main.htm" rel="nofollow">http://www.aholme.co.uk/GPS/Main.htm
    The combination of RF electronics and then doing the signal processing in an FPGA for the timing critical stuff and the actual DSP with a raspberry pi, very interesting.
    JPLeRouzic · 1789743930 · focus · HN ↗
    Thank you @squantor
ErroneousBosh · 1789546539 · focus · HN ↗
One of the things I discovered a while back is that even fairly crude trig approximations don't put that much error into your position, over a small enough distance.
To calculate things like straight-line range from where you are now to where you need to put a unit for an emergency, you're probably not working over an area of more than a couple of hundred kilometres radius and the error will be within a few dozen metres. And once you get within about half a k, you're driving towards the column of smoke anyway ;-)
orielhaim · 1789547650 · focus · HN ↗
[dead]
contingencies · 1789558065 · focus · HN ↗
In Y2K I built a Linux on PC104 solution with GPS, bonded dual-channel mobile 9600 baud data links, and a (slow) image feed.
tomaskafka · 1789559048 · focus · HN ↗
A bit related - I tried if I can push Fable to write a Garmin map renderer that would be comparably fast (or faster) on Fenix 8 than the one they claim is possible on Fenix 9 only. I think I got very close, rendering detailed topographical vector map at over 15 fps on QEMU simulated single core simple CPU comparable to actual Fenix 8.
<a href="https://www.reddit.com/r/Garmin/comments/1vzaz4w/we_live_in_an_age_when_you_can_have_a_garmin_map/" rel="nofollow">https://www.reddit.com/r/Garmin/comments/1vzaz4w/we_live_in_...
AshamedCaptain · 1789564838 · focus · HN ↗
I once worked on a handheld garmin gps that used a 386 ... not sure if it ever became a product, though. It definitely had moving map... 1MB of it.
1. palmotea · 1789568415 · focus · HN ↗
  IIRC, the Garmin eMap had a 386: <a href="https://www.gpsrchive.com/eMap/eMap.html" rel="nofollow">https://www.gpsrchive.com/eMap/eMap.html.
  I think it was one of their first models that had a map, earlier ones would just display coordinates/tracks/waypoints.
  Edit: here's a teardown of an older model where you can see the CPU: <a href="https://www.eevblog.com/forum/repair/garmin-gps-12map/" rel="nofollow">https://www.eevblog.com/forum/repair/garmin-gps-12map/, and the wiki for the CPU has a clearer picture: <a href="https://en.wikipedia.org/wiki/Intel_80386EX" rel="nofollow">https://en.wikipedia.org/wiki/Intel_80386EX
fegu · 1789588124 · focus · HN ↗
Oh how I have fond memories of Dr.Dobb's journal.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.