4 ms·

indeed, developing fast software requires slow hardware.

flenserboy 4y ago
Excellent point. Software testing (not for stability but instead for usability, and certainly not for compiling, lol) ought to be done on minimal-spec systems (the specs of which might possibly be dialed-down further once optimization is done, which would be a bonus). Assuming that a faster system (or one with more RAM or storage) will cure the real problem has allowed all sorts of sloppiness to creep into software.
- LoganDark 4y ago
  We once heard a story about how someone optimized their game engine for a crappy old netbook and ended up with some tens of thousands of frames per second on any vaguely modern system. This works. -Emily
  - mro_name 4y ago
    as you mention gaming – do you know the doom-in-lego-brick? https://kilograham.github.io/rp2040-doom/ https://kilograham.github.io/rp2040-doom/ and brick assembly https://youtube.com/watch?v=6wBrOV2FJM8 https://youtube.com/watch?v=6wBrOV2FJM8 There are some video links in the (german) article https://heise.de/-7448263 https://heise.de/-7448263. Mind-blowing.
- rahen 4y ago
  NetBSD is still routinely tested on 486s and old Vaxen, and developed on ARM SBCs or Pinebooks. It helps keep the code base light and efficient. The latest minimal kernel will still boot on 4MB of memory on 32 bits machines, although it will take more than that to be usable. Unfortunately NetBSD can only do so much considering the sad state of the Linux ecosystem. GCC has become so big it won't self host on most platform, making cross compilation mandatory for them. Switching to PCC would be a solution, but a lot of software won't compile with PCC and obviously their maintainers couldn't care less. Then you have the newer behemoths like Rust and Go. Once they start creeping in some majors projects like GCC or OpenSSL, a lot of machines will turn into e-waste, and the resource requirements will climb even further.
Sesse__ 4y ago
It does not. Slow hardware _can_ give you a certain amount of _motivation_ for speeding up your software, but this is by no means a given (if software running slowly on your own computer automatically made you optimize it, there would not be software that is really slow even on fast hardware, and there clearly is). If you care about making software fast, you invest time in the measurements-ideas-measurements loop, where having fast hardware helps a lot (it allows you get measurements faster, and try out more ideas in a given time frame). Since any sane measurement is based on benchmarking and not eyeballing, slower CPUs don't help you. And you certainly can care about fast software without having a slow computer personally.
- andai 4y ago
  >if software running slowly on your own computer automatically made you optimize it I recently changed 1 byte in Chrome.dll and decreased the lag for copying large images by a factor of 2-3. (The UI freezes for 5-10 seconds. Turns out it's re-encoding a 2MB JPG into a 20MB PNG for the clipboard, at compression level 6 no less!) I put up with it for years thinking there was nothing I could do, but one day I decided to ask some people smarter than me, and they gave me enough info to track down the code in IDA (I had never used it before). My point is, motivation is a powerful thing! (Offtopic but turns out Firefox copies the original file, so you can paste it right into Windows explorer—blew my mind!)
  - alexchantavy 4y ago
    This sounds cool, you should write a blog on it
  - charcircuit 4y ago
    For those curious. https://source.chromium.org/chromium/chromium/src/+/main:ui/base/clipboard/clipboard_win.cc;l=736;drc=0c4306fc554c80506eb0f9b833a5d2a5fdd452d5 https://source.chromium.org/chromium/chromium/src/+/main:ui/... An improvement would be to replace EncodeBGRASkBitmap with FastEncodeBGRASkBitmap so that it uses the fastest zlib level instead of the default (6). This is what the Linux X11 (ozone) implementation uses. This would be an easy fix to upstream if someone wants to do it.

Excellent point. Software testing (not for stability but instead for usability, and certainly not for compiling, lol) ought to be done on minimal-spec systems (the specs of which might possibly be dialed-down further once optimization is done, which would be a bonus). Assuming that a faster system (or one with more RAM or storage) will cure the real problem has allowed all sorts of sloppiness to creep into software.

LoganDark 4y ago
We once heard a story about how someone optimized their game engine for a crappy old netbook and ended up with some tens of thousands of frames per second on any vaguely modern system. This works. -Emily
- mro_name 4y ago
  as you mention gaming – do you know the doom-in-lego-brick? https://kilograham.github.io/rp2040-doom/ https://kilograham.github.io/rp2040-doom/ and brick assembly https://youtube.com/watch?v=6wBrOV2FJM8 https://youtube.com/watch?v=6wBrOV2FJM8 There are some video links in the (german) article https://heise.de/-7448263 https://heise.de/-7448263. Mind-blowing.
rahen 4y ago
NetBSD is still routinely tested on 486s and old Vaxen, and developed on ARM SBCs or Pinebooks. It helps keep the code base light and efficient. The latest minimal kernel will still boot on 4MB of memory on 32 bits machines, although it will take more than that to be usable. Unfortunately NetBSD can only do so much considering the sad state of the Linux ecosystem. GCC has become so big it won't self host on most platform, making cross compilation mandatory for them. Switching to PCC would be a solution, but a lot of software won't compile with PCC and obviously their maintainers couldn't care less. Then you have the newer behemoths like Rust and Go. Once they start creeping in some majors projects like GCC or OpenSSL, a lot of machines will turn into e-waste, and the resource requirements will climb even further.

Sesse__ 4y ago

It does not. Slow hardware _can_ give you a certain amount of _motivation_ for speeding up your software, but this is by no means a given (if software running slowly on your own computer automatically made you optimize it, there would not be software that is really slow even on fast hardware, and there clearly is). If you care about making software fast, you invest time in the measurements-ideas-measurements loop, where having fast hardware helps a lot (it allows you get measurements faster, and try out more ideas in a given time frame). Since any sane measurement is based on benchmarking and not eyeballing, slower CPUs don't help you. And you certainly can care about fast software without having a slow computer personally.

andai 4y ago
>if software running slowly on your own computer automatically made you optimize it I recently changed 1 byte in Chrome.dll and decreased the lag for copying large images by a factor of 2-3. (The UI freezes for 5-10 seconds. Turns out it's re-encoding a 2MB JPG into a 20MB PNG for the clipboard, at compression level 6 no less!) I put up with it for years thinking there was nothing I could do, but one day I decided to ask some people smarter than me, and they gave me enough info to track down the code in IDA (I had never used it before). My point is, motivation is a powerful thing! (Offtopic but turns out Firefox copies the original file, so you can paste it right into Windows explorer—blew my mind!)
- alexchantavy 4y ago
  This sounds cool, you should write a blog on it
- charcircuit 4y ago
  For those curious. https://source.chromium.org/chromium/chromium/src/+/main:ui/base/clipboard/clipboard_win.cc;l=736;drc=0c4306fc554c80506eb0f9b833a5d2a5fdd452d5 https://source.chromium.org/chromium/chromium/src/+/main:ui/... An improvement would be to replace EncodeBGRASkBitmap with FastEncodeBGRASkBitmap so that it uses the fastest zlib level instead of the default (6). This is what the Linux X11 (ozone) implementation uses. This would be an easy fix to upstream if someone wants to do it.