32 ms·

Just speculating but surely it must have something to do with the entire stack being designed under one roof, no? Having the kernel devs be able to walk across

Just speculating but surely it must have something to do with the entire stack being designed under one roof, no? Having the kernel devs be able to walk across the campus and ask the hardware guys what a register is for must speed up development immensely.

pertymcpert 8y ago
Once the CPU reaches peak frequency the OS shouldn't be involved for CPU benchmarks. So it's more down to hardware.
- ken 8y ago
  I can see how the compiler and stdlib (aren't things like memcpy implemented in hand-tuned assembly?) could be highly relevant, though.
  - pertymcpert 8y ago
    They are, but that’s really low hanging fruit. If Android for example doesn’t use optimised memcpy implementations then they don’t deserve to exist as a serious OS.
    - astrange 8y ago
      That reminds me, when I read fast code in the 90s-2000s all the asm hackers were into writing their own cool memcpy. Were they just showing off, or did Windows actually never optimize their standard library? People still seem to like writing their own cool malloc, but memcpy not so much.
      - pertymcpert 8y ago
        There are some cases where it may make sense to write your own implementation, if you have a niche microarchitecture that has unusual performance characteristics that the OS doesn't provide optimized routines for by default. But for most u-archs the default optimized routines should do a good job. Things like malloc are quite a bit more complicated, and more workload dependent so there's still some opportunity specializing an implementation there.
aw1621107 8y ago
I'm not sure that would explain plain CPU performance as shown here. I think SPEC compiles down to native code, so there should be only a fairly limited part of the whole stack involved here --- compiler guys for generating good code, kernel guys for scheduling/power management, SoC team for CPU/memory/GPU subsystem implementation. I also thought kernel devs would be working against processor ISAs, not hardware-specific details beyond the ISA.
Symmetry 8y ago
To some extent. I seem to recall people saying that by restricting the range of page sizes they could make the L1 cache virtually indexed but physically tagged instead of physically indexed and tagged as Android phone processors are. That means you can start the lookup before the address translation is complete but still avoid aliasing problems. EDIT: But I think another part of it is just being willing to throw more transistors at the problem than Android phone SoC manufacturers are and also that their higher income makes spending more on engineering make sense.

pertymcpert 8y ago

Once the CPU reaches peak frequency the OS shouldn't be involved for CPU benchmarks. So it's more down to hardware.

ken 8y ago
I can see how the compiler and stdlib (aren't things like memcpy implemented in hand-tuned assembly?) could be highly relevant, though.
- pertymcpert 8y ago
  They are, but that’s really low hanging fruit. If Android for example doesn’t use optimised memcpy implementations then they don’t deserve to exist as a serious OS.
  - astrange 8y ago
    That reminds me, when I read fast code in the 90s-2000s all the asm hackers were into writing their own cool memcpy. Were they just showing off, or did Windows actually never optimize their standard library? People still seem to like writing their own cool malloc, but memcpy not so much.
    - pertymcpert 8y ago
      There are some cases where it may make sense to write your own implementation, if you have a niche microarchitecture that has unusual performance characteristics that the OS doesn't provide optimized routines for by default. But for most u-archs the default optimized routines should do a good job. Things like malloc are quite a bit more complicated, and more workload dependent so there's still some opportunity specializing an implementation there.

aw1621107 8y ago

I'm not sure that would explain plain CPU performance as shown here. I think SPEC compiles down to native code, so there should be only a fairly limited part of the whole stack involved here --- compiler guys for generating good code, kernel guys for scheduling/power management, SoC team for CPU/memory/GPU subsystem implementation. I also thought kernel devs would be working against processor ISAs, not hardware-specific details beyond the ISA.

Symmetry 8y ago

To some extent. I seem to recall people saying that by restricting the range of page sizes they could make the L1 cache virtually indexed but physically tagged instead of physically indexed and tagged as Android phone processors are. That means you can start the lookup before the address translation is complete but still avoid aliasing problems. EDIT: But I think another part of it is just being willing to throw more transistors at the problem than Android phone SoC manufacturers are and also that their higher income makes spending more on engineering make sense.