The pride of the xServer/xSeries systems were "complex" setups -- multiple chassis -- with up to 32 sockets, and 512 GB of RAM. These required a lot of IBM internal engineering, where they made pin-compatible sockets for what Intel was offering at the time, and glued those chips into _hugely_ different topologies than Intel had in mind.
These systems sound small today, but back in 2001, this was a really big deal for x86. The IBM-proprietary chipsets were much more expensive than off-the-shelf systems, but still a fair bit cheaper than going with NCR or Unisys, competing vendors with proprietary x86 MP designs.
IBM had a lot at stake when that socket changed. Achieving pin-compatibility is hard! Intel is very jealous of their documentation, and prefers to offer paper only, with water-marked copies. It's like owning a gutenberg bible. Engineering something pin-compatible with an Intel x86 CPU has never been easy.
It was no doubt worth it to their "big" x86 server business to ask Intel to make a special run of chips with the old socket layout, but the new emt64 extensions. I bet it was a complete no-brainer compared to the costs of integrating a new socket!
From 2002: https://www.extremetech.com/extreme/73498-serverworks-ships-...
I actually think the ibm systems used the grandchampion chipset.
Serverworks was later acquired by broadcom.
Still their chipsets had neat features worth remembering, such as the ability to use local main memory as a last-level cache of memory read from remote nodes. And of course they went to 64 sockets which was respectable.
Opteron had vastly better architecture than the Intel chipsets of the day, but it topped out at four or eight sockets, I forget.
IBM, at the time, could offer you Opteron-like architecture and performance, with up to 32 sockets, using Intel chips. That was worthwhile to some customers. "Intel" wasn't the selling position. It was x86 or x86-64, with "big" as the selling position.
I'm not here to apologize for Intel. I'm just saying, those IBM proprietary chipsets had their nice bits.
However, with custom glue logic, one could expand it very far - AMD offering in that space was "Horus" chipset which connected 4 sockets with external fabric (infiniband, iirc) to create 64 socket systems. Similar tactic was (and still is) offered by SGI in their UltraViolet systems which utilize the same principle using NUMAlink fabric and Xeon cpus.
There just wasn't enduring customer demand to make an ongoing hardware/software product out of it.
Customers got engineering samples in their hands and they were very, very slow.
The concept is not fine. Itanium was predicated on saving transistors in the OoO machinery, and spending those on making the machine wider and thus performance. However, it turns out that without any OoO, the machine is terrible at hiding memory latency, and the only way to get this back was to ship it with heroically large and low latency caches. And implementing those caches was harder and many times more expensive than just using OoO.
In the end, Itanium saved transistors and power from one side, only to have to spend much more on another side to recoup even part of the performance that was lost.
VLIW had been tried before Itanium. I had some very minimal exposure to both Multiflow and Cydrome, somewhat more with i860. The general feeling at the time among people who had very relevant knowledge or experience was that compilers were close to being able to deal with something like Itanium sufficiently well. Turns out they were wrong.
Perhaps the concept is not fine, but we should be careful to distinguish knowledge gained from hindsight vs. criticism of those who at least had the bravery to try.
So how many times do you have to fail before being brave is just a bad business decision. The "concept" wasn't fine for Multiflow or the i860 (I used both, and would call it terrible for the i860). It didn't work for Cydrome. Trimedia is gone. Transmeta flamed out. There's, what, a couple of DSP VLIW chips that are actually still sold?
But, hey, let's bet the company on Itanium and compilers that will be here Real Soon Now. I remember the development Merced boxes we got.
The general feeling at the time among people who had very relevant knowledge or experience was that compilers were close to being able to deal with something like Itanium sufficiently well.
That's revisionism. There was a general feeling we were getting good at building optimizing compilers, but I don't recall any consensus that VLIW was the way forward. The reaction to Itanium was much less than universally positive, and not just from the press.
Turns out they were wrong.
Very, very wrong. Again.
That's a very good question. More than once, certainly. How many times did Edison fail before he could produce a working light bulb? How many times did Shockley/Bardeen/Brattain fail before they could produce a working transistor? Even more relevantly,how many ENIAC-era computer projects failed before the idea really took off? Ditto for early consumer computers, mini-supers, etc. Several times at least in each case, sometimes many more. Sure, Multiflow and Cydrome failed. C6X was fairly successful. Transmeta was contemporaneous with Itanium and had other confounding features as well, so it doesn't count. There might have been a couple of others, but I'd say three or four or seven attempts before giving up is par for the course. What kind of scientist bases on a conclusion on so few experiments?
> The reaction to Itanium was much less than universally positive, and not just from the press.
Yes, the reaction after release was almost universal disappointment/contempt, but that's not relevant. That was after the "we can build smart enough compilers" prediction had already been proved false. During development of Itanium, based on the success of such an approach for various RISCs and C6X, people were still optimistic. You're the one being revisionist. It would be crazy to start building a VLIW processor now, but it really didn't seem so in the 90s. There were and always will be some competitors and habitual nay-sayers dumping on anything new, but that's not an honest portrayal of the contemporary zeitgeist.
Is it? What’s the point of a processor that we don’t know how to build compilers for? We still don’t know how to schedule effectively for that kind of architecture today.
VLIW architectures are often proposed to simplify the superscalar logic, but the problem with VLIW is that it forces a static schedule, which is incompatible with any code/architecture where the optimal schedule might be dynamic based on the actual data. In other words, any code that involves unpredictable branches, or memory accesses that may hit or miss the cache--in general CPU terms, that describes virtually all code. VLIW architectures have only persisted in DSPs, where the set of algorithms that are trying to be optimized is effectively a small, closed set.
No that's different - the big idea with the Itanium was specifically to shift the major scheduler work to the compiler. We didn't build the first computers with the idea we'd build compilers later.
Also, these days you would pretty much just need to fix LLVM, C2, ICC, and the MS compiler, and almost everyone would be happy.
I spent a lot of time pulling drives and reselling systems that were end of life. I mostly dealt with switches and networking gear I was still encountering old 32bit dual and quad socket X-series semi regularly when I moved on in 2015ish.
"Having such a unique processor at your disposal, it’s absurd not to build a powerful x64-retro system on it. One of the options for using such a system in general can be to build a universal “PC-harvester” that supports all Microsoft operating systems from DOS to Windows 10."
All Microsoft OS'es on the same PC? Cool! Also, if that's indeed the case, my guess is that most versions of x86 Linux and other x86 OS'es, historic to present, would work too... which is no small feat for a single PC...
IDK, did the seller delid and relid it with something exotic? Or did I snag one of the first prototypes? What was up with that lid? Does anyone have a clue?
MB identified an E6300, and it had amazing overclocking potential, it went 7x333Mhz without any voltage increase. Not sure what the max was, but considering only a few people were bidding on it (I'm guessing most were turned away due to that lid), I was quite lucky to get a CPU with a lot of potential for very little cash.
The CPU I bought was working fine though, the seller guaranteed it and he had the reputation on eBay to back it.
My (possibly) naive logic then, was that an early sample was likely to be made from the best silicon, which often correlates with good OC potential...
Yep, that's exactly it, except it was Core2Duo, IDK, must've been around 2009 or so, when I bought it used.
I thought all modern intel/amd cpus are backwards compatible back to the 8086, and so capable of doing that?
That and the question of drivers for OSs newer than DOS (which is not as big of a problem, since they can still be written and doing so is easier than changing the BIOS. The existence of USB drivers for DOS, and HD Audio for Windows 3.1x are examples of that.)
Modern x86 CPUs are theoretically still backwards compatible, but I suspect they don't test things like 16-bit mode and VME much anymore.
It's presumably easier to find a socket 478 motherboard with ISA slots and very old-style firmware.
A couple seconds of digging finds motherboards that cost an average of $300. Assuming you (unfortunately) _have_ to support whatever it is you're supporting...
- Socket 478 (P4/Celeron), 2GB max, RS422/485, MiniPCI, $???: https://adek.com/product/MB-800V
- Socket 478, 2GB max, $???: https://www.bressner.co.uk/products/motherboards/mb-g4v620-b...
- Socket 478, 6xUSB2, $???: http://vegashine.sell.everychina.com/p-104455439/showimage.h...
- Socket 478, 2GB max, CF, 6xUSB2, $???: http://vegashine.sell.everychina.com/p-104455440-4-pci-3-isa...
- LGA775 (Core 2 Quad), 4GB max, 1xPCIx16, M-SATA, 2xLAN, IrDA, 5xRS232, $320: https://www.ebay.com/itm/283550673178
- LGA775, 6xRS232, 8xUSB2.0, CF, RS422/485, $179: https://www.aliexpress.com/item/32892452763.html
- LGA775 (Intel G41), 4GB max, DVI, 4xSATA 3G, 2xLAN, 8xRS232, (does not support ISA bus mastering), $???: http://vegashine.sell.everychina.com/p-104455435/showimage.h...
All of the above have 3xISA, at least one RS232 and at least one LPT.
The same is true for the LGA775-based 32-bit Prescotts. 64-bit disabled by fuses.
Actually let me line up the https://en.wikipedia.org/wiki/Orders_of_magnitude_(data)
.. ?? YB ZB EB PB TB GB MB KB
Blinks a few times
Ultimately fails to mentally grasp and make useful sense of the number due to its sheer size
As an aside, apparently DNA can store a few TB/PB (I don't remember which). The age of optimizing for individual bytes as a routine part of "good programming" is definitely over, I guess. (I realize this discussion is about address space and not capacity, but still)
wouldn't 64bit (16 Exabytes theoretical max) already allow for this? are there any projects in that direction?
Furthermore, the upside is only at best 2x. It's likely to be worse, because you're still going to be throttled by waiting for memory loads and stores. Knowing that we have 2 64-bit adders available to us to use each cycle, we can still do 128-bit additions at full throughput, although it requires slightly more latency for the carry propagation.
Hardware quad-precision floating point is a more useful scalar 128-bit value to support.
Even though it is a big int problem, floating point is used. Their are integer FFT algoritms that are usable (NTTs), but they are much slower than floating point FFTs on modern CPUs.
Power9 has for a few years.