5 ms·

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 s

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.
  - andai 4y ago
    Yeah, like you said they literally already wrote the code that does that, not sure why they didn't use it. Setting compression to 0 is still 2 full seconds of lag for me (down from 8s), so there's still a lot of overhead. There are faster png implementations but I think re-encoding a 2MB JPEG into a 20MB PNG (to be re-encoded back to JPG by whatever program you paste it into) is kind of missing the mark.
    - charcircuit 4y ago
      Funnily enough a CL moving the computation to a background thread was submitted a week ago. This would prevent the UI freeze. https://chromium-review.googlesource.com/c/chromium/src/+/4216473/2#message-d71ab0b025a75a11023f8bd324d041d91bc9c99f https://chromium-review.googlesource.com/c/chromium/src/+/42...
asveikau 4y ago
How about the fact that performance best practices vary on different hardware? CPUs have changed a lot, in that caches, speculative execution, and parallelism are the way to get performance, and that was not true in the heyday of a classic Mac. I'm still in favor of porting to old platforms for various reasons. But we need to keep in mind that performance optimization is not one size fits all.
anarazel 4y ago
Strongly agreed. In fact, I found an over-dimensioned workstation to be one of the best tools improving performance of non-trivial programs. There's a lot of performance issues that don't stand out sufficiently on today's common-place enduser hardware, that will be very visible on a current two socket system. And fixing the issues benefits the lower end hardware of today. More often than not, the large issue one can see in large machines today, are issues seen on lower-end hardware in a few years. It's easy to see using too many cycles on enduser hardware. The effects of memory latency, various forms of cache contention, etc however, not so much. > Since any sane measurement is based on benchmarking and not eyeballing, slower CPUs don't help you I do find that somehow, to a non-rational degree, I have a considerably easier time getting a "feeling" for the performance bottlenecks when benchmarking on my workstation, than when benchmarking on a server. Which I guess kinda falls out of proper benchmarking.
wahern 4y ago
In the case of OpenBSD itself, the popularity of the PCEngines APU2 has definitely provided motivation for improving the performance of PF. Also, ironically, people elsewhere in this article thread keep mentioning that older hardware is too power intensive. But the reason the APU2 is still around is because neither Intel nor AMD offer modern chips with a maximum TDP as low as the AMD G series. At maximum load, with all 4 cores, DRAM, and NICs at full throttle, the APU2 only dissipates something like 10W of heat. Modern x86 chips are more power efficient, but their maximum TDPs are just too high. Some of the laptop and embedded series get close at ~15W (not sure if that includes DRAM and NICs), but that's too hot. The APU2 is designed to only require passive cooling, without finned cases, without conditioned air, and still provide years of reliable always-on service. I see the same issue with higher-end AMD and Intel chips. Under light load their power draw is very low, but under load their chips are often more power hungry than comparable models from 10 years ago. Yes, they get more work done per watt, but there are many situations where I'd rather know that a server will never draw more than, say, 50-60W, even if that means requests end up being throttled. But I don't want to use their crippled low-end chips, either, especially when I can just continue using my 10+ year-old servers that provide better performance. (Theoretically you could manually throttle requests to maintain the power envelope, but I don't want to be burdened managing software configurations.) I prefer the "edge computing" series of chips from Intel and AMD, but over the years their max TDP has slowly crept up. Thankfully there are still a few options that work well, but it's definitely a niche that doesn't see much attention.
- johnklos 4y ago
  Back when Fry's Electronics was still around, they had a sale on old AMD MSi AM1 motherboards and Athlon 5350 quad core 2 GHz CPUs (APUs) for $45 or so for a set. I bought quite a few, and now I regret not buying more. At 100% CPU load they take less than 25 watts measured at the wall, and less than 40 watts with two spinning rust 3.5" disks. They make excellent NAT routers / firewalls / DNS servers, et cetera. They can route / NAT a full gigabit and still have cycles to spare. The closest thing we have today is getting a quad core Ryzen and running sysctl -w machdep.cpu.frequency.target=1600. Personally, I'd rather have more of those wonderful 2014 motherboards and CPUs.
- 4y ago

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.
- andai 4y ago
  Yeah, like you said they literally already wrote the code that does that, not sure why they didn't use it. Setting compression to 0 is still 2 full seconds of lag for me (down from 8s), so there's still a lot of overhead. There are faster png implementations but I think re-encoding a 2MB JPEG into a 20MB PNG (to be re-encoded back to JPG by whatever program you paste it into) is kind of missing the mark.
  - charcircuit 4y ago
    Funnily enough a CL moving the computation to a background thread was submitted a week ago. This would prevent the UI freeze. https://chromium-review.googlesource.com/c/chromium/src/+/4216473/2#message-d71ab0b025a75a11023f8bd324d041d91bc9c99f https://chromium-review.googlesource.com/c/chromium/src/+/42...

asveikau 4y ago

How about the fact that performance best practices vary on different hardware? CPUs have changed a lot, in that caches, speculative execution, and parallelism are the way to get performance, and that was not true in the heyday of a classic Mac. I'm still in favor of porting to old platforms for various reasons. But we need to keep in mind that performance optimization is not one size fits all.

anarazel 4y ago

Strongly agreed. In fact, I found an over-dimensioned workstation to be one of the best tools improving performance of non-trivial programs. There's a lot of performance issues that don't stand out sufficiently on today's common-place enduser hardware, that will be very visible on a current two socket system. And fixing the issues benefits the lower end hardware of today. More often than not, the large issue one can see in large machines today, are issues seen on lower-end hardware in a few years. It's easy to see using too many cycles on enduser hardware. The effects of memory latency, various forms of cache contention, etc however, not so much. > Since any sane measurement is based on benchmarking and not eyeballing, slower CPUs don't help you I do find that somehow, to a non-rational degree, I have a considerably easier time getting a "feeling" for the performance bottlenecks when benchmarking on my workstation, than when benchmarking on a server. Which I guess kinda falls out of proper benchmarking.

wahern 4y ago

In the case of OpenBSD itself, the popularity of the PCEngines APU2 has definitely provided motivation for improving the performance of PF. Also, ironically, people elsewhere in this article thread keep mentioning that older hardware is too power intensive. But the reason the APU2 is still around is because neither Intel nor AMD offer modern chips with a maximum TDP as low as the AMD G series. At maximum load, with all 4 cores, DRAM, and NICs at full throttle, the APU2 only dissipates something like 10W of heat. Modern x86 chips are more power efficient, but their maximum TDPs are just too high. Some of the laptop and embedded series get close at ~15W (not sure if that includes DRAM and NICs), but that's too hot. The APU2 is designed to only require passive cooling, without finned cases, without conditioned air, and still provide years of reliable always-on service. I see the same issue with higher-end AMD and Intel chips. Under light load their power draw is very low, but under load their chips are often more power hungry than comparable models from 10 years ago. Yes, they get more work done per watt, but there are many situations where I'd rather know that a server will never draw more than, say, 50-60W, even if that means requests end up being throttled. But I don't want to use their crippled low-end chips, either, especially when I can just continue using my 10+ year-old servers that provide better performance. (Theoretically you could manually throttle requests to maintain the power envelope, but I don't want to be burdened managing software configurations.) I prefer the "edge computing" series of chips from Intel and AMD, but over the years their max TDP has slowly crept up. Thankfully there are still a few options that work well, but it's definitely a niche that doesn't see much attention.

johnklos 4y ago
Back when Fry's Electronics was still around, they had a sale on old AMD MSi AM1 motherboards and Athlon 5350 quad core 2 GHz CPUs (APUs) for $45 or so for a set. I bought quite a few, and now I regret not buying more. At 100% CPU load they take less than 25 watts measured at the wall, and less than 40 watts with two spinning rust 3.5" disks. They make excellent NAT routers / firewalls / DNS servers, et cetera. They can route / NAT a full gigabit and still have cycles to spare. The closest thing we have today is getting a quad core Ryzen and running sysctl -w machdep.cpu.frequency.target=1600. Personally, I'd rather have more of those wonderful 2014 motherboards and CPUs.
4y ago