3 ms·

Just so that I understand this correctly: he bought a $6000+ Mac Studio with a 20-core M1 Ultra processor and 128GB of RAM. But all these cores, ram, bandwidth,

Just so that I understand this correctly: he bought a $6000+ Mac Studio with a 20-core M1 Ultra processor and 128GB of RAM. But all these cores, ram, bandwidth, storage are not important, but rather the fact it is an "ARM64" workstation is what was the game changer. Seriously? Would a $6000+ x64 workstation be noticeably slower?

dijit 4y ago
Not sure, but anecdotally I have a machine running linux that was $6,000 and definitely feels slower than my M2 macbook air. Mostly its a question of latency I would imagine. My machine: Archlinux “Zen” (lower latency kernel). Threadripper 3970x 256G DDR4 2666MHz 3x4TiB NVMe (PCIe Gen3) in RAID0 Radeon VII GFX card (more than enough for 2D render of terminals).
- znpy 4y ago
  > Archlinux “Zen” (lower latency kernel). that might be the problem low latency kernels aren't of any help unless you're running realtime (or near-realtime) workloads. not only that, in order to guarantee high priority tasks they will hurt regular process performances. for desktop usage running a "low latency" kernel is probably a bad idea (no wonder "low latency" kernel config are not the default choice).
  - dijit 4y ago
    I think you have it backwards. The lower latency kernels are great for desktops (and the default for desktop distros typically). They sacrifice raw power for lower latency. So my compiles take a bit longer as the kernel will switch tasks more often, but keypresses will be captured with reduced latency from my perspective. I have tested this, the stock arch kernel has considerable more latency on inputs.
    - diffeomorphism 4y ago
      "Lower latency" usually means lower peak, not average. E.g. <5 99% of the time and 25 1% of the time is "high" but much better for desktops than <15 100% of the time (made up numbers). So you usually avoid low latency or real time kernels unless you need the <15 guarantee.
      - dijit 4y ago
        I think we're talking about latency in incorrect terms, I'm referring to polling frequency of my task queue to handle interrupts, which is configured as an increase in the polling rate of the scheduled workloads inside linux with the following keys: CONFIG_HZ_100 # Typical for server workloads CONFIG_HZ_250 # For servers that need to switch tasks more often (think: overprovisioned cloud providers) CONFIG_HZ_300 # For Media servers/workstations, typically CONFIG_HZ_1000 # For desktops, typicall. The documentation suggests for “workstation/desktop” operations the timer should be set to 1000MHz. Why does it recommend this? Because the higher the polling rate the quicker it will see inputs from human interface devices like mice and keyboards and respond to them. A higher tickrate here will mean more interrupts (meaning lower throughput but a lower latency to interrupts). If you're talking about process latency of non-interrupted processes then a lower value is prefered because you don't really want your program to wait around for more CPU time while linux polls all of its buffers and tries to schedule other tasks. You can easily see what is configured by asking the kernel for its configuration param: `zcat /proc/config.gz | grep -E '^CONFIG_HZ'`
- zahllos 4y ago
  I attended a talk by a PhD student who specializes in CPU/architectural research, on the M1 as an architecture. There are some key differences in design, such as unified memory etc, but what accounts for a large part of the performance gap with x86 is the fact Apple's compilers can target their specific microarchitecture and optimize for that, because they know its performance characteristics well. We know the performance characteristics of various x86 cores, however there are simply a lot of them, so most precompiled x86 code is generically targeted but likely has suboptimal parts on different architectures. You can, of course, -mtune= with gcc, but you'd basically need to rebuild your distribution. Or in other words, the ideal would be to compare someone running Gentoo vs macOS. So, that was the gist of the talk and I more or less accept the conclusions. Now for my own view, I think what makes ARM processors interesting is their efficiency wrt power consumption. I would love a non-Apple ARM laptop if only because intel cores are much less efficient in terms of power they require.
  - dijit 4y ago
    Interestingly I actually ran gentoo for a while on that machine precisely for that reason, but the overall latency improvement was marginal. Certainly not worth recompiling things all the time in my opinion, even with a beefy machine like mine.
  - Vogtinator 4y ago
    > what accounts for a large part of the performance gap with x86 is the fact Apple's compilers can target their specific microarchitecture and optimize for that, because they know its performance characteristics well. OP is running Arch though, which is probably built with gcc/clang targeting generic ARMv8(.0?).
  - NegativeK 4y ago
    I've a friend in the industrial and academic chip development space. They basically agreed with what you said. ARM isn't some magical compute/watt wand that Apple waved; it's their incredibly tight software and hardware integration that allowed them optimize.
  - twoodfin 4y ago
- lunfard00 4y ago
  depends your workload I guess, if you are just compiling a lot of code or having containers with a non-server-like load, then most of features of this computer are useless. Also GUI software will feel significatively worse. Lastly, threadripper has a NUMA architecture, which is not very user application friendly. Frankly, they are very bad personal computers in general, only worth if you need that much memory or PCI lines, which doesn't seem to be your case.
fargle 4y ago
No doubt having lots of threads and lots of memory make this a very nice workstation. But it's about twice the price of a 16-core AMD 7955 which has about 150% the performance both per core and overall. The M1 certainly might win on power, though. Using a machine of this class is mind blowing, that author isn't wrong about that. But there's still about a 3x price/performance gap. I love ARM and I can't wait for this to get more mainstream, but it's not quite here yet if you are cost conscious. https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+9+7950X&id=5031 https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+9+7950X&i... https://www.cpubenchmark.net/cpu.php?cpu=Apple+M1+Ultra+20+Core&id=4782 https://www.cpubenchmark.net/cpu.php?cpu=Apple+M1+Ultra+20+C...

dijit 4y ago

Not sure, but anecdotally I have a machine running linux that was $6,000 and definitely feels slower than my M2 macbook air. Mostly its a question of latency I would imagine. My machine: Archlinux “Zen” (lower latency kernel). Threadripper 3970x 256G DDR4 2666MHz 3x4TiB NVMe (PCIe Gen3) in RAID0 Radeon VII GFX card (more than enough for 2D render of terminals).

znpy 4y ago
> Archlinux “Zen” (lower latency kernel). that might be the problem low latency kernels aren't of any help unless you're running realtime (or near-realtime) workloads. not only that, in order to guarantee high priority tasks they will hurt regular process performances. for desktop usage running a "low latency" kernel is probably a bad idea (no wonder "low latency" kernel config are not the default choice).
- dijit 4y ago
  I think you have it backwards. The lower latency kernels are great for desktops (and the default for desktop distros typically). They sacrifice raw power for lower latency. So my compiles take a bit longer as the kernel will switch tasks more often, but keypresses will be captured with reduced latency from my perspective. I have tested this, the stock arch kernel has considerable more latency on inputs.
  - diffeomorphism 4y ago
    "Lower latency" usually means lower peak, not average. E.g. <5 99% of the time and 25 1% of the time is "high" but much better for desktops than <15 100% of the time (made up numbers). So you usually avoid low latency or real time kernels unless you need the <15 guarantee.
    - dijit 4y ago
      I think we're talking about latency in incorrect terms, I'm referring to polling frequency of my task queue to handle interrupts, which is configured as an increase in the polling rate of the scheduled workloads inside linux with the following keys: CONFIG_HZ_100 # Typical for server workloads CONFIG_HZ_250 # For servers that need to switch tasks more often (think: overprovisioned cloud providers) CONFIG_HZ_300 # For Media servers/workstations, typically CONFIG_HZ_1000 # For desktops, typicall. The documentation suggests for “workstation/desktop” operations the timer should be set to 1000MHz. Why does it recommend this? Because the higher the polling rate the quicker it will see inputs from human interface devices like mice and keyboards and respond to them. A higher tickrate here will mean more interrupts (meaning lower throughput but a lower latency to interrupts). If you're talking about process latency of non-interrupted processes then a lower value is prefered because you don't really want your program to wait around for more CPU time while linux polls all of its buffers and tries to schedule other tasks. You can easily see what is configured by asking the kernel for its configuration param: `zcat /proc/config.gz | grep -E '^CONFIG_HZ'`
zahllos 4y ago
I attended a talk by a PhD student who specializes in CPU/architectural research, on the M1 as an architecture. There are some key differences in design, such as unified memory etc, but what accounts for a large part of the performance gap with x86 is the fact Apple's compilers can target their specific microarchitecture and optimize for that, because they know its performance characteristics well. We know the performance characteristics of various x86 cores, however there are simply a lot of them, so most precompiled x86 code is generically targeted but likely has suboptimal parts on different architectures. You can, of course, -mtune= with gcc, but you'd basically need to rebuild your distribution. Or in other words, the ideal would be to compare someone running Gentoo vs macOS. So, that was the gist of the talk and I more or less accept the conclusions. Now for my own view, I think what makes ARM processors interesting is their efficiency wrt power consumption. I would love a non-Apple ARM laptop if only because intel cores are much less efficient in terms of power they require.
- dijit 4y ago
  Interestingly I actually ran gentoo for a while on that machine precisely for that reason, but the overall latency improvement was marginal. Certainly not worth recompiling things all the time in my opinion, even with a beefy machine like mine.
- Vogtinator 4y ago
  > what accounts for a large part of the performance gap with x86 is the fact Apple's compilers can target their specific microarchitecture and optimize for that, because they know its performance characteristics well. OP is running Arch though, which is probably built with gcc/clang targeting generic ARMv8(.0?).
- NegativeK 4y ago
  I've a friend in the industrial and academic chip development space. They basically agreed with what you said. ARM isn't some magical compute/watt wand that Apple waved; it's their incredibly tight software and hardware integration that allowed them optimize.
- twoodfin 4y ago
lunfard00 4y ago
depends your workload I guess, if you are just compiling a lot of code or having containers with a non-server-like load, then most of features of this computer are useless. Also GUI software will feel significatively worse. Lastly, threadripper has a NUMA architecture, which is not very user application friendly. Frankly, they are very bad personal computers in general, only worth if you need that much memory or PCI lines, which doesn't seem to be your case.

fargle 4y ago

No doubt having lots of threads and lots of memory make this a very nice workstation. But it's about twice the price of a 16-core AMD 7955 which has about 150% the performance both per core and overall. The M1 certainly might win on power, though. Using a machine of this class is mind blowing, that author isn't wrong about that. But there's still about a 3x price/performance gap. I love ARM and I can't wait for this to get more mainstream, but it's not quite here yet if you are cost conscious. https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+9+7950X&id=5031 https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+9+7950X&i... https://www.cpubenchmark.net/cpu.php?cpu=Apple+M1+Ultra+20+Core&id=4782 https://www.cpubenchmark.net/cpu.php?cpu=Apple+M1+Ultra+20+C...