Comment by 6510 | Hacker News Reader

Comment by 6510 | Hacker News Reader

It is quite surreal to me that this was not the road taken. Optimizing software doesn't have the same potential as optimizing hardware but i'd say 1/70 is significant. If thousands of people would work on this indefinitely the time would drop to seconds. That code would also be completely incomprehensible. The argument that people should just buy a faster computer could just as easily have worked out the other way around, just write faster software. Going the hardware way gave us really really readable code which is great. The other direction however would have given us really really cheap devices. Receiving and sending a signal for [say] a chat application requires very little stuff. It would be next to impossible to add images, word suggestions or spell checkers. We could still bake mature applications onto dedicated chips. But until now those efforts went pretty much nowhere(?) I imagine one could quite easily bake a mail client or server, or a torrent client, irc, perhaps even a gui for windowed applications. Maybe an error console?

In the ~30 years I've used computers, they've become ~1,000,000 times faster. My daily experience with computers doesn't show it. There's someone out there who took the time to measure UI latency and has shown that, no only isn't it faster, it's actually slowed down. And yet, our hardware is 1,000,000 times faster...

Edit: this is the latency project I was thinking about https://danluu.com/input-lag/

What beautiful table in how it is seems sorted both by time and latency with the exception of some systems that are ahead of their time in slowness.

If you put a bit of load on the modern hardware things get dramatically worse. As if there is some excuse for it.

I had this thought long ago that the picture on the monitor could be stitched together from many different sources. You would have a box some place on the screen with an application or widget rendered in it by physically isolated hardware. An input area needs a font and a color scheme. The text should still be send to the central processor and/or to the active process but it can be send to the display stitcher simultaneously.

You could even type a text and have it encrypted without the rest of the computer learning what the words say.

I look at and click around KolibriOS one time, everything is so responsive it made me slightly angry.

> If thousands of people would work on this indefinitely the time would drop to seconds.

Even the small Apple II screen takes 7.5 kilobytes of RAM. Reading https://imapenguin.com/2022/06/how-fast-can-a-6502-transfer-..., just writing all of that to the screen takes a tenth of a second, for just over 50,000 pixels, and that’s ignoring the idiosyncratic video memory layout of the Apple II.

Going below ten seconds for decompressing that would mean you must produce 5 output pixels every millisecond, which means you have about 200 CPU cycles per pixel. On a 6502, that’s less than 100 instructions.

That makes me doubt it can get under 10 seconds.

⇒ if you want to get down to seconds, I think you’ll have to drop even more image data than this does, and do that fast.

Oh yes the dithering takes 10 seconds all to itself. The Quicktake 100 format is much more simple (4-bits nibbles) and it still needs 22 seconds to decode 640x480.

(Decoding and dithering are done in two passes for memory reasons and space on floppy disk reasons but it brings auto-levelling)

It's about 450 cycles per pixel for decoding QT100 (1200 for QT150), and 230 cycles per pixel for dithering.

When we had this tiny memory and the slow cpu to work with everyone was into optimization. It quite regularly happened that someone would find a new way to do something way beyond what everyone else thought possible. You would quite literally sit in front the screen stuck in a loop saying "What?" then "How?" with 5 second pauses in between. I'm not bragging about my amazing skills here, more the opposite. I've just adjusted my estimated accordingly. If enough people spend enough time the solution will turn out much weirder than the quake inverse square root.

> I’ll be using the revised version as I think it’s a well-established example of doing a real-world block transfer. Sure there may be faster ways, but this is a realistic way, which is what we’re going for.

   NEXT  LDX #NUMBER  
         LDA BASE,X 
         STA DEST,X 
         DEX 
         BNE NEXT

Something unrolled like:

    $1000 LDA $2000
    $1003 STA $3000
    $1006 LDA $2001
    $1009 STA $3001
    etc...

Isn't even the fastest solution but 3 out of 5 instructions are gone and I think the two remaining are faster. The transfer in the book is of course really practical while this one is already almost unworkable. You can do worse tho:

    $1000 LDA #$12
    $1002 STA $30
    $1004 LDA #$34
    $1006 STA $31
    etc...

For the truly insane solution you would have to consider if you even have to read the data. Maybe you can present the image as-is and modify it... or worse... turn it into code...

but it still should happen. every project (of a certain size) should have at least 1-2 programmers whose job it is to make the code faster & smaller. frankly, this could well be the best use of AI on code — not to generate it, but to use its potential speed to chew through existing code bases, outputting squashed-down, streamlined code which is tested to return the same results as the original (think the dream of gentoo, but every program on your system optimized for your particular hardware).

You could do it client side as well! Based on how the user uses the application. Make the things I use 1000 times per day faster and things I'm never going to use may grow slightly slower.

Reply on news.ycombinator.com