3 ms·

What do you mean by latency here exactly?

by simias 6y ago

dijit 6y ago
I'm not exactly sure what I mean and that's part of the issue, when using an ARM CPU with desktop software which has not been optimised to hide UI "lag" there's something that feels like it just.. lags. You can feel it on a rpi if you use it for a day, it's not that it's underpowered, you can grab a 15yo celeron that is much slower and single core and it will have less perceptable latency. The Celeron will "feel" as if it's working, the ARM chip will "feel" as if it's laggy. I can't quantify this behaviour, but it's consistent across all ARM CPU's I've ever used with traditional desktop software. Notably these issues don't seem to exist on Android or iOS, someone once told me this is due to the UI elements having a higher priority than anything else on the system.
- ianai 6y ago
  I forget the specifics, but risc winds up feeling slower because it’s a more “correct” arch than cisc. Been a while since this came up!
- _bxg1 6y ago
  Do those ARM systems have graphics chips, or are they rendering the UI on the CPU? Modern x86 processors have integrated graphics for GUI basics, video, etc. Linux desktops can theoretically run off of just the CPU, just... not super well.
  - zozbot234 6y ago
    Even Raspberry Pi has an integrated GPU. They feel slower because they're lower-frequency in-order chips, and while the chips themselves have multiple cores many applications don't use them properly - more specifically, they don't render the UI in a dedicated thread.
    - fouc 6y ago
      RPI are cheap hardware not really designed for desktop computing I guess.
- icedchai 6y ago
  Yes, I've noticed this as well. ARM Linux desktops feel sluggish. It is not IO, because I have done tests after everything has been cached, loaded once. I have a RPi 4 here, as well as some older Pine64 boards.
- DCKing 6y ago
  If your experience with "desktop UI on ARM" is based on the RPi and other ARM SBCs, the overwhelmingly likely explanation for this perceived lag is lacking I/O performance. Running a Raspberry Pi (or any system) from any cheap flash storage setup like SD cards or cheap eMMCs degrades desktop responsivity a lot. The ARM desktop hardware most of us have experience with has significant I/O problems, but that's due to them being cheap hardware, and not due to ARM. I/O is actually the real prevalent bottleneck for desktop interactivity on all modern hardware. Even older x86 systems with spinning platter hard drives are set up for a more responsive desktop experience due to the I/O performance being suited for the desktop. Modern Android phones and iPhones also have much better I/O setups for interactive use (UFS for high end Android, Apple actually uses NVME because responsiveness is so crucial) . Certainly CISC vs RISC has nothing to do with it as that discussion really has no bearing on the situation anymore on discussions about modern ARM and Intel (see my other post).
  - zozbot234 6y ago
    > Running a Raspberry Pi (or any system) from any cheap flash storage setup like SD cards or cheap eMMCs degrades desktop responsivity a lot. Not really, if the system has enough free RAM to use as disk cache. For many scenarios, that suffices to run quite acceptably.
    - DCKing 6y ago
      RAM as disk cache is only useful for things you have already loaded. It doesn't help your boot times, new program launches, or loading new content in your program. I'm not saying SBCs are "unusable" for desktop use cases, I'm saying I/O is the likely explanation for desktop responsiveness issues they encounter on SBCs.
      - dijit 6y ago
        Nobody here is talking about boot times, I was talking about responsiveness.. it's easy to test your theory, you can boot USB on the new RPI, and USB3.0 has quite a high bandwidth, definitely comparable to SATA2, nearly SATA3
ianai 6y ago
RISC cpus have historically been under-clocked and perceivable slower than their cisc competitors. Apple was running on risc cpus before going intel x86. They were constantly marketing their speeds as less important than speeds matter to x86 architecture. I hope they’re able to devote two cores to UI/UX at a much higher frequency than the general compute cores. That would take some engineering know how, but could negate the performance complaints largely.
- Symmetry 6y ago
  That's just a matter of the process node Apple's PowerPC chips were on. When RISC chips came out their big selling point was that they could be clocked many times faster than CISC chips at the time could because it was easier to pipeline them and because you could put the entire CPU on a single chip.
- kmeisthax 6y ago
  "RISC" isn't a single architecture, it's a philosophy for designing architectures. The "RISC" Apple was using before x86 was called PowerPC, and it was designed mostly by IBM. It was also a horrible piece of overheating garbage that I'm still honestly surprised wound up in the Xbox 360 and PlayStation 3. The "RISC" Apple is using now, ARM, is a far more practical architecture that Apple has already beat Intel with in single-thread perf... at a lower clock rate, with strict power limits. Letting the A13 stretch it's legs with wall power and a big heatsink would completely crush Intel and x86 in every benchmark except multi-threading. User-perceived latency has little to do with the clock rate of a processor, though. What you need is: 1. Immediate feedback upon user input 2. Progress animations that move, even if progress is indeterminate 3. High frame rates on your animations 4. No frame stutter or torn frames Out of the four, low clock rate will mainly impact frame rates and pacing, but that can still be mitigated by using what you have as efficiently as possible.

What do you mean by latency here exactly?

by simias 6y ago

What do you mean by latency here exactly?

I'm not exactly sure what I mean and that's part of the issue, when using an ARM CPU with desktop software which has not been optimised to hide UI "lag" there's something that feels like it just.. lags. You can feel it on a rpi if you use it for a day, it's not that it's underpowered, you can grab a 15yo celeron that is much slower and single core and it will have less perceptable latency. The Celeron will "feel" as if it's working, the ARM chip will "feel" as if it's laggy. I can't quantify this behaviour, but it's consistent across all ARM CPU's I've ever used with traditional desktop software. Notably these issues don't seem to exist on Android or iOS, someone once told me this is due to the UI elements having a higher priority than anything else on the system.

ianai 6y ago
I forget the specifics, but risc winds up feeling slower because it’s a more “correct” arch than cisc. Been a while since this came up!
_bxg1 6y ago
Do those ARM systems have graphics chips, or are they rendering the UI on the CPU? Modern x86 processors have integrated graphics for GUI basics, video, etc. Linux desktops can theoretically run off of just the CPU, just... not super well.
- zozbot234 6y ago
  Even Raspberry Pi has an integrated GPU. They feel slower because they're lower-frequency in-order chips, and while the chips themselves have multiple cores many applications don't use them properly - more specifically, they don't render the UI in a dedicated thread.
  - fouc 6y ago
    RPI are cheap hardware not really designed for desktop computing I guess.
icedchai 6y ago
Yes, I've noticed this as well. ARM Linux desktops feel sluggish. It is not IO, because I have done tests after everything has been cached, loaded once. I have a RPi 4 here, as well as some older Pine64 boards.
DCKing 6y ago
If your experience with "desktop UI on ARM" is based on the RPi and other ARM SBCs, the overwhelmingly likely explanation for this perceived lag is lacking I/O performance. Running a Raspberry Pi (or any system) from any cheap flash storage setup like SD cards or cheap eMMCs degrades desktop responsivity a lot. The ARM desktop hardware most of us have experience with has significant I/O problems, but that's due to them being cheap hardware, and not due to ARM. I/O is actually the real prevalent bottleneck for desktop interactivity on all modern hardware. Even older x86 systems with spinning platter hard drives are set up for a more responsive desktop experience due to the I/O performance being suited for the desktop. Modern Android phones and iPhones also have much better I/O setups for interactive use (UFS for high end Android, Apple actually uses NVME because responsiveness is so crucial) . Certainly CISC vs RISC has nothing to do with it as that discussion really has no bearing on the situation anymore on discussions about modern ARM and Intel (see my other post).
- zozbot234 6y ago
  > Running a Raspberry Pi (or any system) from any cheap flash storage setup like SD cards or cheap eMMCs degrades desktop responsivity a lot. Not really, if the system has enough free RAM to use as disk cache. For many scenarios, that suffices to run quite acceptably.
  - DCKing 6y ago
    RAM as disk cache is only useful for things you have already loaded. It doesn't help your boot times, new program launches, or loading new content in your program. I'm not saying SBCs are "unusable" for desktop use cases, I'm saying I/O is the likely explanation for desktop responsiveness issues they encounter on SBCs.
    - dijit 6y ago
      Nobody here is talking about boot times, I was talking about responsiveness.. it's easy to test your theory, you can boot USB on the new RPI, and USB3.0 has quite a high bandwidth, definitely comparable to SATA2, nearly SATA3

ianai 6y ago

RISC cpus have historically been under-clocked and perceivable slower than their cisc competitors. Apple was running on risc cpus before going intel x86. They were constantly marketing their speeds as less important than speeds matter to x86 architecture. I hope they’re able to devote two cores to UI/UX at a much higher frequency than the general compute cores. That would take some engineering know how, but could negate the performance complaints largely.

Symmetry 6y ago
That's just a matter of the process node Apple's PowerPC chips were on. When RISC chips came out their big selling point was that they could be clocked many times faster than CISC chips at the time could because it was easier to pipeline them and because you could put the entire CPU on a single chip.
kmeisthax 6y ago
"RISC" isn't a single architecture, it's a philosophy for designing architectures. The "RISC" Apple was using before x86 was called PowerPC, and it was designed mostly by IBM. It was also a horrible piece of overheating garbage that I'm still honestly surprised wound up in the Xbox 360 and PlayStation 3. The "RISC" Apple is using now, ARM, is a far more practical architecture that Apple has already beat Intel with in single-thread perf... at a lower clock rate, with strict power limits. Letting the A13 stretch it's legs with wall power and a big heatsink would completely crush Intel and x86 in every benchmark except multi-threading. User-perceived latency has little to do with the clock rate of a processor, though. What you need is: 1. Immediate feedback upon user input 2. Progress animations that move, even if progress is indeterminate 3. High frame rates on your animations 4. No frame stutter or torn frames Out of the four, low clock rate will mainly impact frame rates and pacing, but that can still be mitigated by using what you have as efficiently as possible.