Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Worst CPUs Ever Made (2021)

extremetech.com

Post reply on HN
Print view View original

141–150 of 155 posts

Re: The Worst CPUs Ever Made (2021)

#141

Post by jsjohnst »

djmips wrote: post #122
jsjohnst wrote: post #105

Earlier quoted context omitted.

> You can find many people singing it's praises, including me. Until today, I’ve never once seen someone “singing it’s praises” that’s actually written code for one. At best, they’d curse it under their breath while saying it had its benefits. Usually however it was a full throated rant about how bad the experience was.

Every single one of them came out a better coder. They might have been dragged kicking and screaming to the multi-core but they would've had to get there in the end.

> Every single one of them came out a better coder.

Sure that may be true, but that does not mean they are singing its praises either.

Just look at this very post on HN where folks who’ve written code for it have commented on the experience, how many would you say are:

- singing its praises (you)

- cursing it under their breath while saying it had its benefits (few)

- full throated rant about how bad the experience was (few)

Re: The Worst CPUs Ever Made (2021)

#142

Post by sifar »

jcranmer wrote: post #86
cogman10 wrote: post #68

Earlier quoted context omitted.

The reverse is true. SIMD is harder because you have to have a uniform operation across a set of data. Imagine a for loop that looks like this int[] x, y, z; int[] p, d, q; for (int i = 0; i For SIMD, this is a complicated mess for the compiler to unravel. What the compiler would LIKE to do is turn this into 3 for loops and use the SIMD instructions to perform those operations in parallel. The itanium optimization, h…

That loop is actually nicely vectorizable, at least assuming that you replace int with float (there is no integer division vector instruction on x86). All of the array accesses are uniform, so the resulting vector code is roughly: for (i = 0 .. size by vector width) { r0 = vector load x[i..i + vw] r1 = vector load y[i..i + vw] r2 = vector load z[i..i + vw] r3 = r0 / r2 r4 = r2 * r0 r5 = r1 + r2 vector store r3 to p[i…

and any vliw compiler worth it's salt would bundle the load, div/mul/alu, store into one instruction packet

Re: The Worst CPUs Ever Made (2021)

#143

Post by sifar »

therealcamino wrote: post #119
cogman10 wrote: post #44

Earlier quoted context omitted.

Funnily, I feel like SIMD instructions are slowly reinventing what the itanium did out of the box. I think a modern compiler could likely do a good job with itanium now-a-days. However, when it first came out, there simply wasn't the ability to keep those instruction batches full. Compiler tech was too far behind to work well with the hardware.

The problem is, compile-time instruction scheduling for VLIW vs an out-of-order, superscalar processor is inherently unequal because there is an information gap. At compile time you cannot see the actual dependences, and have to statically schedule for the worst case. You can do great on regular, array-based code. But VLIW can never beat OOO superscalar processors on irregular or pointer-chasing code, because there i…

Both VLIW & Ooo Superscalar are doing a different tradeoff to achieve similar goal - maximize ILP.

With VLIW the compiler unrolls the code and tries to find the parallelization but has no control over runtime stalls and results in larger code size. The complexity is in the compiler while the machine is simpler.

With an OOO superscalar machine, you have to dedicate significant piece of HW for stuff that would be easily done by the compiler. The advantage is you can get reduced code size and better performance for non-linear code.

Re: The Worst CPUs Ever Made (2021)

#144

Post by sifar »

cogman10 wrote: post #68
zamadatix wrote: post #57

Earlier quoted context omitted.

I'm not sure I'd say many compilers are even that great with SIMD these days and that is easier than what the itanium was asking of compilers. There are real gains to be had by using SIMD but it tends to be massively parallel data processing workloads with specially written SIMD code or even hand tuned assembly (image/video processing, neural networks) not just feeding in a source file and compiling with the SIMD fla…

The reverse is true. SIMD is harder because you have to have a uniform operation across a set of data. Imagine a for loop that looks like this int[] x, y, z; int[] p, d, q; for (int i = 0; i For SIMD, this is a complicated mess for the compiler to unravel. What the compiler would LIKE to do is turn this into 3 for loops and use the SIMD instructions to perform those operations in parallel. The itanium optimization, h…

>> For SIMD, this is a complicated mess for the compiler to unravel

this is trivially vectorizable for simd, would fit nicely in a vliw packet too. The only issue is if there was a runtime memory stall with any access, then the entire pipeline would stall.

with predication, modern simd even parallelize if conditions like below.

int[] x, y, z; int[] p, d, q;

    for (int i = 0; i n) {
         q[i] = y[i] + z[i]  ;
       } else {
         q[i] = y[i];
       } 
    }

Re: The Worst CPUs Ever Made (2021)

#145

Post by hajile »

cogman10 wrote: post #68
zamadatix wrote: post #57

Earlier quoted context omitted.

I'm not sure I'd say many compilers are even that great with SIMD these days and that is easier than what the itanium was asking of compilers. There are real gains to be had by using SIMD but it tends to be massively parallel data processing workloads with specially written SIMD code or even hand tuned assembly (image/video processing, neural networks) not just feeding in a source file and compiling with the SIMD fla…

The reverse is true. SIMD is harder because you have to have a uniform operation across a set of data. Imagine a for loop that looks like this int[] x, y, z; int[] p, d, q; for (int i = 0; i For SIMD, this is a complicated mess for the compiler to unravel. What the compiler would LIKE to do is turn this into 3 for loops and use the SIMD instructions to perform those operations in parallel. The itanium optimization, h…

VLIW architecture is so bad that AMD and Nvidia couldn't make it work well with embarrassingly parallel graphics code. AMD first moved from VLIW-5 to VLIW-4 because they couldn't find enough data to reliably keep unit 5 busy.

AMD then followed Nvidia into the world of SIMD/SIMT because it offered better real-world performance for the majority of applications.

VLIW has been tried repeatedly only to be replaced with something that worked better.

Re: The Worst CPUs Ever Made (2021)

#146

Post by hulitu »

StillBored wrote: post #50

Man, that 6x86 CPU is still getting the short end of the stick nearly three decades later despite being a pretty solid chip. So, first it generally had a higher IPC than anything else available (ignoring the P6). So, the smart marketing people at cyrix decided they were going to sell it based on a PR rating which was the average performance on a number of benchmarks vs a similar pentium. AKA a Cyrix PR166 (clocked at…

6x86 PR200 was really fast in Linux of the day. The fact that it had 256 kB cache also helped.

Re: The Worst CPUs Ever Made (2021)

#147

Post by hulitu »

xbar wrote: post #7

I'm so ashamed to have owned a Cyrix, a P4, and an AMD Bulldozer. They were all awful.

For P4 i underestand ( legend says that P3 was faster at the same clock rate and that's why there are no P4 at the same speed as P3). But Cyrix and Buldozer ?

Re: The Worst CPUs Ever Made (2021)

#148

Post by p_l »

cogman10 wrote: post #75
p_l wrote: post #63

Earlier quoted context omitted.

The critical difference is that EPIC (the architecture model of Itanium) essentially exposed CPU pipelines naked to the code - so you didn't just have to reorder instructions as optimizers do today, you also had to figure out changes that experience so far suggests is doable either in hw with runtime-only data, or in very tight numerical code. This includes compiler taking the place of branch predictor as well as OOO…

I'm not sure that branch prediction would need to go to the compiler, but definitely agree it'd likely subsume the OOOE scheduling (at very least, it'd be less effective). That, though, seems like it might make for a good power/performance tradeoff. Those circuits aren't free. We just didn't get to the point where compilers were doing a good job of that OOOE reordering (not until after EPIC died). The real reason, th…

The x86 emulator built into Itanium 1 was very bad, yes, but it didn't matter that much outside of workstation use. HP build Itanium 2 without it, and provided software emulators for x86 and HP-PA that worked apparently "well enough".

The real deal breaker was Itanium being ridiculously expensive and quickly destroying any possibility of increased market by pricing itself out of it - and even in the markets that had the money, it was considered overpriced (nicest thing I heard about Itanium was "overpriced DSP masquerading as general purpose CPU"). I remember reading intel's published roadmaps before news about amd64 landed - We would be running 32bit x86 much longer under it, with Itanium being kept at extra premium prices.

Even customers that had Itanium as the only upgrade path available - thanks to HP - found the performance so bad - on natively compiled code! - they effectively forced HP to produce Alpha till Itanium was pretty much confirmed dead and the customers migrated out of HP vendor-locked stack (at one of the largest mobile telcos in Poland we migrated from Alpha to IBM POWER, many OpenVMS customers kept buying/hoarding Wildfire and Marvel architecture servers).

Re: The Worst CPUs Ever Made (2021)

#149

Post by StillBored »

hulitu wrote: post #146
StillBored wrote: post #50

Man, that 6x86 CPU is still getting the short end of the stick nearly three decades later despite being a pretty solid chip. So, first it generally had a higher IPC than anything else available (ignoring the P6). So, the smart marketing people at cyrix decided they were going to sell it based on a PR rating which was the average performance on a number of benchmarks vs a similar pentium. AKA a Cyrix PR166 (clocked at…

6x86 PR200 was really fast in Linux of the day. The fact that it had 256 kB cache also helped.

Which brings up another fact, which was that microsoft disabled the cache on cyrix processor in one of the versions of windows NT (3.51 or 4?). And so you had to download a driver from Cyrix to turn it back on. But that didn't keep various people from claiming it's perf sucked in windows NT too.

IIRC the official excuse when this became public was that a MS engineer turned it off because one of their test machines couldn't complete a stress test with it enabled, but later it turned out the root cause was a bad motherboard. The curious part being that it didn't result in MS immediately issuing a hotfix to turn the cache back on.

edit: found one of the articles mentioning this. https://www.tomshardware.com/reviews/bananas,9.html

Apparently it was just writeback mode that got disabled, either way that link mentions a 30% perf hit.

Re: The Worst CPUs Ever Made (2021)

#150

Post by notacoward »

pinewurst wrote: post #125
sanguy wrote: post #106

Earlier quoted context omitted.

i860 did well in embedded applications and for awhile was the mainstay in most RAID controllers and network communication processors. Not what Intel wanted from it but it did have a long life in such applications. I spent many years working on the i860 and i960 and learned to live with its oddities. As for the Cell it was overly complex architecture and had remarkable performance under very optimized code. The hope w…

I think you mean 960 in RAID and comm controllers. The 860 had incredibly bad, almost unbelievably slow context switches. You’d never ever use it in a controller. A dedicated render pipeline is pretty all it was good for, for some value of ‘good’.

I had the same reaction. The i860 and i960 were very different beasts. I owned an 860-based Oki/Stardent workstation, bought for peanuts at the latter company's fire sale, for a while. Later I found the 960CA (in particular) in many storage/network devices. So I kind of know both, but I would never speak of them as if they were the same. Other than sharing a corporate logo, they had little to do with one another.
Post reply on HN