| ▲ | Joel_Mckay a day ago |
| [flagged] |
|
| ▲ | kstrauser a day ago | parent | next [-] |
| You've mentioned Intel's compilers a few times but they're not a magic thing that could make Itanic not-suck. Suppose they make general purpose code that's twice as fast as GCC when the whole computer is dedicated to running one specific process. They don't, but let's pretend. Even in that ideal scenario, it falls apart as soon as you're processing unpredictable input. VLIW sucks hard at chewing through data that's not precisely what it's expecting. You could probably make a video codec that performed really well, but it would be impossible to make a database that performed consistently not-badly. It's not that the existing compilers weren't good enough, not even the magic Intel ones. It's that it's not possible to pre-generate VLIW opcodes that do well when the input value isn't a homogeneous stream. Even if Intel's code was 2x better than GCC's — and again, it wasn't — twice abominable was still abominable. I wasted more time SSHed into an Itanic than most people had to, so I'm speaking from first-hand experience. Some very, very specific Itanium code was a bit faster than the equivalent x86 or similar. That was always some very tightly scoped thing that did the exact same tight loop a gazillion times, like en-/decrypting a data stream. Anything more heterogenous ran poorly, as in multiple times the wall-clock time of the same workload on the x86 server next to it that cost a tenth as much. And that's even when using the magic Intel compilers. Itanium was bad. The compiler tech didn't exist to make it not-bad, and in retrospect I think it become obvious that it couldn't exist. It wasn't a matter of the compiler authors needing to be clever. It was more like making Itanium live up to the hype required making P=NP. |
| |
| ▲ | Joel_Mckay a day ago | parent [-] | | My point was most modern software developers still do not understand systems at an architectural level. I don't buy the VLIW paradigm was inherently inferior argument, but the code written for it with mystery failure modes at the time was a mess. And ia64 was only around 23% slower and several times more costly than amd64 options at the time. Both toads had their warts, but one was actually usable by mere mortals. Its true just about everything either ran slow on not at all on ia64... Thankfully, we were still running Sparc based platforms at that time, as the Intel clown-show still looked like more work. But I do empathize with the ia64 trauma, as the roll out had a lot of collateral damage in some firms as people started jumping ship early to avoid accountability. =3 | | |
| ▲ | qubex 20 hours ago | parent [-] | | One immediate advantage that rescheduling-capable cores have that rigid compiler-based ones don’t nor ever would is that reschedules can notice patterns in execution in the current context and keep the ALU fed from well-provisioned caches even going as far as speculative execution. IA-64 and typeless or typed-at-runtime (JIT scripts, for example, like JavaScript or Python) would’ve been implemented very differently on Itanium. |
|
|
|
| ▲ | abbeyj a day ago | parent | prev | next [-] |
| I think they meant EPIC https://en.wikipedia.org/wiki/Explicitly_parallel_instructio..., not EPYC https://en.wikipedia.org/wiki/Epyc. |
| |
| ▲ | Joel_Mckay a day ago | parent [-] | | Indeed, my point was not all chips do well with Desktop application loads. People were bad at handling parallelism with ia64, and still have problems today on better amd platforms with less janky compilers. The fact an $800 chip still can beat a $14000 chip at some tasks probably should tell people something about concurrency scaling overhead. =3 | | |
| ▲ | qubex 20 hours ago | parent [-] | | EPIC was Explicit Parallel Instruction Computing, the underlying engineering architecture of AI-64. Epyc is an AMD brand name. And pivoting to concurrency on a rescheduler-intensive core as opposed to concurrency on a scheduler-based core isn’t very pertinent, particularly since we have 25 years of Moore’s Law between then and now. | | |
| ▲ | Joel_Mckay 20 hours ago | parent [-] | | "AI" responses are silly, and optimal 24 core count efficiency premise in Desktop applications offer diminishing returns on a highly concurrent 32/64/192 core Epyc line of OoO chips... How many strings does a Bass play with in water? =3 |
|
|
|
|
| ▲ | shrubble a day ago | parent | prev [-] |
| EPIC is Explicitly Parallel Instruction Computing; nothing to do with the AMD trademark word, EPYC. |
| |
