52 ms·

Very interesting info on the overclocking difference between TSMC 7nm and Intel 14nm+++ however a few misconceptions: - Intel staying low core count probably w

Very interesting info on the overclocking difference between TSMC 7nm and Intel 14nm+++ however a few misconceptions: - Intel staying low core count probably wasn't evil intent: the software wasn't there and Intel had better single thread perf than AMD. AMD was basically forced into more cores earlier because of weakness in single thread. Today, the software _is_ there (well, mostly) and we can all take advantage of more cores. - Why did Intel fall behind? Easy: Brian Krzanich's hubris pushed the process too hard, taking many risks, and the strategy failed spectacularly. - PCIe Gen4 does matter. M.2 NVMe has been read limited for a long time already (NAND bandwidth scales trivially). The I/O section of this article is basically nonsense. - There's is nothing magical about x86, nor about the AMD and Intel design team. If the market is there, there will be competitive non-x86 alternatives. The data center market is pretty conservative for good reason - but ML is upending a lot of conventional wisdom so it'll be interesting to see what happens.

walrus01 7y ago
> - PCIe Gen4 does matter Strong disagree there, for threadripper and epyc products based on zen2. There's use cases for two and four port 100GbE PCI-Express NICs in 1RU and 2RU sized x86-64 platform systems where you definitely want as much pci-express bus bandwidth as possible. In addition to the obvious use cases like people putting multiple nvme pci-express bus ssds in pci-express slots. At the low end of the price market things like a pci-express 3.0 x8 card that holds four m.2 2280 SSDs in a $18 part. First generation single socket epyc was already a huge improvement in number of pci-express lanes per CPU socket compared to equivalently priced intel product, if you were, for example looking at building a 2RU system with eight or twelve 100GbE interfaces to run juniper JunOS as VMX. In the single socket higher-end workstation CPU market ($400 to $800 CPUs) Intel has for a very long time had a constrained number of pci-express lanes available per motherboard. In a setup with a single high end video card like a 1080ti or 2080 and a single nvme SSD, it doesn't leave a whole lot of I/O lanes left over.
- FullyFunctional 7y ago
  I cannot follow your argument, so let me give examples: https://www.anandtech.com/show/14729/samsung-preps-pm1733-pcie-4-0-ssd-for-amd-rome-processors https://www.anandtech.com/show/14729/samsung-preps-pm1733-pc... Samsung introduced a 8 GB/s SSD specifically for PCIe Gen4. I used to work in the SSD business many years ago and we could _trivially_ saturate PCIe Gen3 x4 but it wasn't economical to go to more lanes. (Bandwidth is easy, latency is hard).
  - walrus01 7y ago
    Somehow I mistakenly read the parent comment as pcie 4.0 doesn't matter, and typed a whole bunch of paragraphs in answer to that. Point was that 4.0 and more lanes are a much needed improvement so I actually am in agreement with the parent comment. Oops.
- eemil 7y ago
  Maybe I'm missing something, but PCIe Gen4 does seem like a big deal since it's effectively doubling the data rate of the previous gen. Meaning, once all/most of your peripherals are PCIe 4 compatible, you'll theoretically have double the PCIe lanes, on account of only needing half as many. One immediate benefit that comes to mind, is storage controllers. With 8x spinning disks, you might get away with using a single lane which can provide almost 2 GByte/s bandwidth. And controllers previously using 8xGen3 lanes could switch to 4xGen4 without any loss in performance.
ac29 7y ago
> PCIe Gen4 does matter. M.2 NVMe has been read limited for a long time already (NAND bandwidth scales trivially). The I/O section of this article is basically nonsense. I think the author's point was that storage is already plenty fast enough for many tasks. Personally, I cant feel the difference in storage performance between my NVMe system and older SATA SSD ones, despite NVMe being much faster.
- FullyFunctional 7y ago
  Ah, but that’s making assumptions about the user. There are lots of power users for whom IO bandwidth matters; high-end video editing for example.
  - nottorp 7y ago
    They - and any other subset - can get the PCIe 4 SSDs of course. There are "lots" of other subsets where it stopped mattering a while ago though.
  - tjoff 7y ago
    And low-cores are not?! We have been core starved for almost a decade! IO matters but peak bandwidth sequential reads are not such a limiting factor even for power users.
- Ygg2 7y ago
  > I cant feel the difference in storage performance between my NVMe That's because for the most common tasks, real performance had not improved. Manufacturers always display the write/read speed using many cores and with huge queue depth. The typical use case for that is copying files. It's around 3000MB/s When starting OS and loading program you have tasks that use low queue and thread count, which is about 60-70 MB/s.
  - tempguy9999 7y ago
    Genuine questions. I just don't know this area... > Manufacturers always display the write/read speed using many cores... Why does #cores matter? Once the IO is initiated it's handed off to some DMA/coprocessor stuff so the core can get back to starting other IOs without contention. Being clueless I can't see why a single core couldn't saturate IO bandwidth by just blasting out IO requests. > ...and with huge queue depth. Really stupid question now, I thought disk queues were queued up requests caused by issuing a buttload of IO requests, so why does a disk queue of say 20 actually make things any faster over a disk queue of just 2? I know (correction, believe) with spinny disks a longer queue could be used by the controller to optimise access on the disk surface by proximity, but with SSDs that performance characteristic doesn't exist (access is uniform anywhere, I think) so that optimisation doesn't apply.
fmajid 7y ago
I wonder how much of Intel’s stagnation is due to their bringing CPU engineering back to the US from Israel. In other words putting the geniuses behind Netburst and Itanic in charge.
- totololo 7y ago
  Can you elaborate? Do you know why the repatriation was decided? Can you explain why Netburst and (I’m guessing this is a pun on) Itanium were failures? Do you know what Israeli teams did better?
  - cptskippy 7y ago
    Netburst was the Pentium 4 architecture that introduce large execution pipelines that permitted high clock speeds thinking they could out run inefficiency. Latency, power and temperature however became mitigating factors. Alongside Netburst development, Intel had the Israeli team develop a mobile first platform. The team took parts of the bus for Netburst and shit canned the rest if the design in favor of the Pentium III which they optimized the shit out of. They introduced concepts like microop fusion and developed the processor with the goal of sleeping whenever possible to conserve power. The net result was the Banias platform which was incredibly efficient because it was incredibly fast. The original Core line was basically Banias with power saving turned off.
  - ethbro 7y ago
    From memory, the Netburst team ignored power efficiency until power density concerns hard-capped their frequency targets (and this was on 180/130/90 nm!). Itanium is often lazily pointed to as a failure by Intel, but in reality it was a hard task with decent execution. Intel attempted to build an ecosystem around an entirely new architecture. Emphasis on smart-compiler extracted instruction level parallelism, supported by wide but less superscalar hardware. In 2001. As an analogy, this is kind of like asking every driver to toggle a switch to manage the engine mapping while they drive. It could be more effective, but it's also a ton of work and relies on expertise being developed. AMD delivered what the market really wanted in x64: something that looked exactly like x86, with a few modest improvements, and some 32-bit scaling limitations removed. But no big changes. The Israeli teams are usually cited as the caretakers of the P6 (Pentium Pro) legacy, which evolved into the Pentium M, and eventually the Core architectures. They chose to optimize for power efficiency, and so didn't hit the same power caps the Netburst team did. Generally, the internet comments on this are armchair generaling with the benefit of hindsight. There are many reasons things could have gone differently. Sometimes two teams work equally hard, but one chooses a path that leads to success and the other one that leads to failure.
zsrxx 7y ago
>Today, the software _is_ there (well, mostly) and we can all take advantage of more cores. Disagree. Not even "mostly". If I had a dime every time I saw some software stuck at 100% of one core... well, I'd have a few dimes a day.
- caspper69 7y ago
  Well, that's not at all a fair comparison. Who knows what that one core is doing? Not all algorithms are parallelizable, in fact most aren't. So doing standard, everyday things in code might still max out a core.
  - zsrxx 7y ago
    Exactly. So single-core performance wins.
- hajile 7y ago
  Most consumers use their devices for media consumption, games, and surfing the web. ALL of these are heavily multi-threaded. Yes, even dear old Javascript is parsed and compiled in multiple threads, concurrently GC'd and uses web workers, service workers, and webassembly. In the business world, all the commonly-used software I can think of is heavily threaded as well. Generally, the remaining software that comes to mind is simple stuff that could run on a decade-old machine without too much trouble. What typical programs are you running that require so much single-threaded performance?
  - zsrxx 7y ago
    Windows Update, Windows Defender Antivirus, NTFS compression, maybe more I've forgotten. Also old (and not-so-old) games.
  - mtone 7y ago
    Using Acrobat DC, searching for content in all PDFs in a folder takes ages. It is both slow AND single-threaded, the disk is barely moving. Tried with Foxit and a few others, same thing. I had to seek indexed search apps, and those are few and far between and generally poor quality - kudos to Recoll[1] as the standout so far. But I'd much rather just search within the reader. Anyway, it's infuriating, this should go about x times as fast as there are cores. [1]: https://www.lesbonscomptes.com/recoll/ https://www.lesbonscomptes.com/recoll/
gameswithgo 7y ago
> PCIe Gen4 does matter. M.2 NVMe has been read limited for a long time already (NAND bandwidth scales trivially). The I/O section of this article is basically nonsense. It probably does for a great many special use cases on servers or other specialty workloads. But for programming/gaming/normal productivity workloads it really doesn't. The net difference in load times/compile times/boot times is tiny even going from a cheap ssd to the latest pci4 ssds. If you do huge sequential reads/writes, then yeah, large differences are getting unlocked.
- lumost 7y ago
  Has anyone tried adding branch prediction to disk operations? While it would confuse a network, or other peripheral a preemptive random read from a disk ought to have minor impact.
  - zrm 7y ago
    Operating systems have supported readahead for a long time. It's even more benefit for spinning rust than SSDs because the benefit of a correct prediction is larger when the drive is slower. But it's also a trade off, because if you predict wrong you're wasting scarce I/O resources fetching useless data.

walrus01 7y ago

> - PCIe Gen4 does matter Strong disagree there, for threadripper and epyc products based on zen2. There's use cases for two and four port 100GbE PCI-Express NICs in 1RU and 2RU sized x86-64 platform systems where you definitely want as much pci-express bus bandwidth as possible. In addition to the obvious use cases like people putting multiple nvme pci-express bus ssds in pci-express slots. At the low end of the price market things like a pci-express 3.0 x8 card that holds four m.2 2280 SSDs in a $18 part. First generation single socket epyc was already a huge improvement in number of pci-express lanes per CPU socket compared to equivalently priced intel product, if you were, for example looking at building a 2RU system with eight or twelve 100GbE interfaces to run juniper JunOS as VMX. In the single socket higher-end workstation CPU market ($400 to $800 CPUs) Intel has for a very long time had a constrained number of pci-express lanes available per motherboard. In a setup with a single high end video card like a 1080ti or 2080 and a single nvme SSD, it doesn't leave a whole lot of I/O lanes left over.

FullyFunctional 7y ago
I cannot follow your argument, so let me give examples: https://www.anandtech.com/show/14729/samsung-preps-pm1733-pcie-4-0-ssd-for-amd-rome-processors https://www.anandtech.com/show/14729/samsung-preps-pm1733-pc... Samsung introduced a 8 GB/s SSD specifically for PCIe Gen4. I used to work in the SSD business many years ago and we could _trivially_ saturate PCIe Gen3 x4 but it wasn't economical to go to more lanes. (Bandwidth is easy, latency is hard).
- walrus01 7y ago
  Somehow I mistakenly read the parent comment as pcie 4.0 doesn't matter, and typed a whole bunch of paragraphs in answer to that. Point was that 4.0 and more lanes are a much needed improvement so I actually am in agreement with the parent comment. Oops.
eemil 7y ago
Maybe I'm missing something, but PCIe Gen4 does seem like a big deal since it's effectively doubling the data rate of the previous gen. Meaning, once all/most of your peripherals are PCIe 4 compatible, you'll theoretically have double the PCIe lanes, on account of only needing half as many. One immediate benefit that comes to mind, is storage controllers. With 8x spinning disks, you might get away with using a single lane which can provide almost 2 GByte/s bandwidth. And controllers previously using 8xGen3 lanes could switch to 4xGen4 without any loss in performance.

ac29 7y ago

> PCIe Gen4 does matter. M.2 NVMe has been read limited for a long time already (NAND bandwidth scales trivially). The I/O section of this article is basically nonsense. I think the author's point was that storage is already plenty fast enough for many tasks. Personally, I cant feel the difference in storage performance between my NVMe system and older SATA SSD ones, despite NVMe being much faster.

FullyFunctional 7y ago
Ah, but that’s making assumptions about the user. There are lots of power users for whom IO bandwidth matters; high-end video editing for example.
- nottorp 7y ago
  They - and any other subset - can get the PCIe 4 SSDs of course. There are "lots" of other subsets where it stopped mattering a while ago though.
- tjoff 7y ago
  And low-cores are not?! We have been core starved for almost a decade! IO matters but peak bandwidth sequential reads are not such a limiting factor even for power users.
Ygg2 7y ago
> I cant feel the difference in storage performance between my NVMe That's because for the most common tasks, real performance had not improved. Manufacturers always display the write/read speed using many cores and with huge queue depth. The typical use case for that is copying files. It's around 3000MB/s When starting OS and loading program you have tasks that use low queue and thread count, which is about 60-70 MB/s.
- tempguy9999 7y ago
  Genuine questions. I just don't know this area... > Manufacturers always display the write/read speed using many cores... Why does #cores matter? Once the IO is initiated it's handed off to some DMA/coprocessor stuff so the core can get back to starting other IOs without contention. Being clueless I can't see why a single core couldn't saturate IO bandwidth by just blasting out IO requests. > ...and with huge queue depth. Really stupid question now, I thought disk queues were queued up requests caused by issuing a buttload of IO requests, so why does a disk queue of say 20 actually make things any faster over a disk queue of just 2? I know (correction, believe) with spinny disks a longer queue could be used by the controller to optimise access on the disk surface by proximity, but with SSDs that performance characteristic doesn't exist (access is uniform anywhere, I think) so that optimisation doesn't apply.

fmajid 7y ago

I wonder how much of Intel’s stagnation is due to their bringing CPU engineering back to the US from Israel. In other words putting the geniuses behind Netburst and Itanic in charge.

totololo 7y ago
Can you elaborate? Do you know why the repatriation was decided? Can you explain why Netburst and (I’m guessing this is a pun on) Itanium were failures? Do you know what Israeli teams did better?
- cptskippy 7y ago
  Netburst was the Pentium 4 architecture that introduce large execution pipelines that permitted high clock speeds thinking they could out run inefficiency. Latency, power and temperature however became mitigating factors. Alongside Netburst development, Intel had the Israeli team develop a mobile first platform. The team took parts of the bus for Netburst and shit canned the rest if the design in favor of the Pentium III which they optimized the shit out of. They introduced concepts like microop fusion and developed the processor with the goal of sleeping whenever possible to conserve power. The net result was the Banias platform which was incredibly efficient because it was incredibly fast. The original Core line was basically Banias with power saving turned off.
- ethbro 7y ago
  From memory, the Netburst team ignored power efficiency until power density concerns hard-capped their frequency targets (and this was on 180/130/90 nm!). Itanium is often lazily pointed to as a failure by Intel, but in reality it was a hard task with decent execution. Intel attempted to build an ecosystem around an entirely new architecture. Emphasis on smart-compiler extracted instruction level parallelism, supported by wide but less superscalar hardware. In 2001. As an analogy, this is kind of like asking every driver to toggle a switch to manage the engine mapping while they drive. It could be more effective, but it's also a ton of work and relies on expertise being developed. AMD delivered what the market really wanted in x64: something that looked exactly like x86, with a few modest improvements, and some 32-bit scaling limitations removed. But no big changes. The Israeli teams are usually cited as the caretakers of the P6 (Pentium Pro) legacy, which evolved into the Pentium M, and eventually the Core architectures. They chose to optimize for power efficiency, and so didn't hit the same power caps the Netburst team did. Generally, the internet comments on this are armchair generaling with the benefit of hindsight. There are many reasons things could have gone differently. Sometimes two teams work equally hard, but one chooses a path that leads to success and the other one that leads to failure.

zsrxx 7y ago

>Today, the software _is_ there (well, mostly) and we can all take advantage of more cores. Disagree. Not even "mostly". If I had a dime every time I saw some software stuck at 100% of one core... well, I'd have a few dimes a day.

caspper69 7y ago
Well, that's not at all a fair comparison. Who knows what that one core is doing? Not all algorithms are parallelizable, in fact most aren't. So doing standard, everyday things in code might still max out a core.
- zsrxx 7y ago
  Exactly. So single-core performance wins.
hajile 7y ago
Most consumers use their devices for media consumption, games, and surfing the web. ALL of these are heavily multi-threaded. Yes, even dear old Javascript is parsed and compiled in multiple threads, concurrently GC'd and uses web workers, service workers, and webassembly. In the business world, all the commonly-used software I can think of is heavily threaded as well. Generally, the remaining software that comes to mind is simple stuff that could run on a decade-old machine without too much trouble. What typical programs are you running that require so much single-threaded performance?
- zsrxx 7y ago
  Windows Update, Windows Defender Antivirus, NTFS compression, maybe more I've forgotten. Also old (and not-so-old) games.
- mtone 7y ago
  Using Acrobat DC, searching for content in all PDFs in a folder takes ages. It is both slow AND single-threaded, the disk is barely moving. Tried with Foxit and a few others, same thing. I had to seek indexed search apps, and those are few and far between and generally poor quality - kudos to Recoll[1] as the standout so far. But I'd much rather just search within the reader. Anyway, it's infuriating, this should go about x times as fast as there are cores. [1]: https://www.lesbonscomptes.com/recoll/ https://www.lesbonscomptes.com/recoll/

gameswithgo 7y ago

> PCIe Gen4 does matter. M.2 NVMe has been read limited for a long time already (NAND bandwidth scales trivially). The I/O section of this article is basically nonsense. It probably does for a great many special use cases on servers or other specialty workloads. But for programming/gaming/normal productivity workloads it really doesn't. The net difference in load times/compile times/boot times is tiny even going from a cheap ssd to the latest pci4 ssds. If you do huge sequential reads/writes, then yeah, large differences are getting unlocked.

lumost 7y ago
Has anyone tried adding branch prediction to disk operations? While it would confuse a network, or other peripheral a preemptive random read from a disk ought to have minor impact.
- zrm 7y ago
  Operating systems have supported readahead for a long time. It's even more benefit for spinning rust than SSDs because the benefit of a correct prediction is larger when the drive is slower. But it's also a trade off, because if you predict wrong you're wasting scarce I/O resources fetching useless data.