9 ms·

Mixed feelings. On the one hand, Itanium (as a platform) was batshit insane, impossible to write good compilers for and the pinnacle of Intel overengineering. G

• roblabla 8y ago
  OS research is still active though. I see many interesting microkernels being developed left right and center. RedoxOS is trying to build a unix microkernel. Nintendo built Horizon, a capabilities-based microkernel for the Nintendo Switch. Many of Plan9's features have been incorporated into Linux. We have seL4, a formally proven kernel that is still in active development (they are currently working hard on getting a formally proven SMP component). I don't think it's fair to say Kernel research is a thing of the past.
  • pcwalton 8y ago
    Also Fuchsia at Google.
    • josteink 8y ago
      Let’s be honest: the only reason Fuschia exists, is so Google can ship a Android-platform 100% free of GPL-code in the future. There’s nothing in it for anyone else.
      • q3k 8y ago
        I think Fuchsia exists mostly to keep talented OS research people busy and make them stay at the company.
        • max76 8y ago
          It would be an awful waste of talent if it's just busy work.
          • glangdale 8y ago
            The argument exists (I'm not saying it's true) that Google hoovers up the smartest people to stop them making another Google. People used to make the same argument about Microsoft.
            • pjmlp 8y ago
              I don't remember the source, so I might be making this up, I kind of remember Bill Gates stating that they would rather hire someone and keep them busy as letting them work for the competition.
              • glangdale 8y ago
                I have a similar vague memory. That being said, that also works as a pretty good post hoc justification for having some guys randomly doing research and not really delivering what you hoped they'd deliver ("Hey, at least they didn't go off and make another Microsoft!").
            • vfclists 8y ago
              That is why today we have Java and its IDEs instead of Smalltalk and its evolvents like StrongTalk
      • vardump 8y ago
        Fuchsia is a pretty nice and clean design. I do see other use for it as well. Although I'm a little worried about driver performance, especially in cases when there's just ~100 microseconds time for the driver to react.
    • q3k 8y ago
      You're right, Fuchsia might be the closest modern day equivalent of Bell Labs and their OS research.
      • pjmlp 8y ago
        MS Research also does quite a few cool things, some of them landed up on Windows USB stack, WSL, SQL Server deployment on Linux, .NET Native, async/await, driver validation with Z3, for example.
        • lemoncucumber 8y ago
          The Midori project out of Microsoft seemed pretty interesting, despite not ever turning into a shipping OS.
          • pjmlp 8y ago
            At least it influenced async/await, TPL, .NET Native, Span<>, local refs, ref structs, blittable structs, and few other C# 7.x and 8.0 features. Reading between the lines of some Joe Duffy posts, I think Midori was a victim of rise to power from WinDev after that whole Longhorn/Vista history, only to end with UWP slowly getting back all the .NET features that they decided to throw away on the initial version of WinRT. Apparently post .NET Core 3.0 there will be some changes happening to .NET Native. It was briefly mentioned at Connect 2018, but they didn't wanted to precise what exactly.
• tw04 8y ago
  I doubt OpenPower is going anywhere anytime soon, IBM has their Z chips, and opensparc is going to remain open (whether anyone decides to adopt it or not).
• greglindahl 8y ago
  There's a ton of innovation happening right now for machine-learning optimized ISAs. And RISC-V has excellent support for extensions. The funniest part of Itanium for me was that it was supposedly helpful to compilers. Yet the compiler people I knew did not like to use the "helpful" parts of the ISA. The loop unrolling stuff got in the way of software pipelining, for example. Mill is an example of a processor that's actually helpful to compilers, because its design is being led by an actual compiler person.
  • vbezhenar 8y ago
    I wonder how did it happen? Intel has its own compiler, surely they could ask their compiler gurus to help with ISA design.
    • greglindahl 8y ago
      I don't know who they asked, but it's safe to say that compiler gurus are a diverse lot. The particular concern I mentioned (software pipelining) might not be something that the Intel compilers do.
    • gaius 8y ago
      Intel has its own compiler, surely they could ask their compiler gurus to help with ISA design. Well that kinda was the concept - but they greatly underestimated the difficulty of producing a "sufficiently smart compiler". If VLIW had worked it would have greatly simplified processor design, no (or at least much less) need to worry about cleverly handling out-of-order execution for example. That in turn would have meant e.g. bigger L1 caches because you would have the die space to play with, or more execution units, or whatever. It didn't work out and Intel did make some stupid decisions along the way (also underestimating the importance of backwards compatibility with existing code - not only binaries, but you also needed to be able to compile existing source well) but it was worth a punt, and maybe will be again someday - maybe a DL-based compiler could produce good VLIW code? Maybe a new (or old) language will be more amenable to VLIW compilation than C?
      • 8y ago
• Twirrim 8y ago
  There's MIPS as well out there, which is being opened up: https://wavecomp.ai/mipsopen https://wavecomp.ai/mipsopen Not sure it presents much of an advantage over any of the existing architectures, or RISC-V, though.
  • classichasclass 8y ago
    MIPS today isn't what it used to be. It mostly occupies the "we're too cheap to use ARM" segment of the market these days, which is an ignominious fate for what used to be a great architecture. But it's well known and it still has its wonderful instruction set, so maybe someone can make it shine again once it goes fully open.
    • deleted 8y ago
      [deleted]
    • int_19h 8y ago
      It also seems to be popular for countries playing catch-up on that whole "we can make our own computers from grounds up" metric - both China and Russia make their own MIPS CPUs, mostly for military use at the moment.
      • wolfgke 8y ago
        > It also seems to be popular for countries playing catch-up on that whole "we can make our own computers from grounds up" metric - both China and Russia make their own MIPS CPUs, mostly for military use at the moment. I am no expert on this, but my personal impression is that projects of this kind slowly try to migrate towards RISC-V.
    • Twirrim 8y ago
      The few times I've dealt with MIPS architecture, it has seemed like software isn't really that well optimised for it. It works. Just... not as fast as it can do, e.g. zlib. There are some forked versions of the main zlib library with MIPS optimisations in them that really fly, but nothing that has ever hit upstream, and I'm not crazy enough to want to rely on unpatched/unsupported code like that.
• captainbland 8y ago
  You're right, it is kind of disappointing. I think the fact that it would cost so much to come up with something novel and then optimise it to the point that conventional CPUs are at that it seems hardly worth the expenditure. The next major frontier in CPU design would appear to be in materials and manufacturing rather than architecture - although no doubt whatever the post-silicon world looks like will influence future architecture substantially. Mind you, if nothing beyond the smallest silicon processes turns out to be practical then we might see attention turning back to re-thinking CPU architecture, but until then I think a lot of money will be spent looking at materials and manufacturing over interesting ISAs.
  • danmaz74 8y ago
    I wonder if something new could emerge to help with massive parallelism, beyond what gpus already do.
    • greglindahl 8y ago
      An instruction to insert into a queue on another core would be a great thing. The T3E had it, InfiniPath / OmniPath has it between boxes, and I've heard of a research project that did it on a modern cpu.
  • ghaff 8y ago
    Although the possibilities are arguably greater for new designs to get traction today. There are a lot of reasons. Open source, cloud providers, etc. But a big one is that you can't just depend on CMOS process shrinks to make processors faster. Therefore, your new design isn't necessarily going to be eclipsed by whatever new x86 CPU comes out in 12 months.
    • captainbland 8y ago
      That's true, but the difficulty is it's not just going to take 12 months to do something like this. A radically new architecture would take years to become competitive with today's processors for all of the use cases that would make it marketable. Meanwhile the x86 guys aren't just going to sit still, there's almost certainly more IPC to squeeze and they can add fixed function hardware (as they've already done for video encoding/decoding) or FPGA area in new product ranges and keep building new markets that way.
• pcwalton 8y ago
  x86-64 is anything but "boring" and "safe". :) Real mode, Mod R/M and SIB byte encoding weirdness, REX prefixes, 80-bit floats, parity flag, hard-wired registers for shifts/multiplies/divisions, builtin CRC32 over the wrong polynomial, Pascal calling convention support, binary-coded decimal, high halves of 16-bit registers, MMX overlap with x87 floating point, etc. etc.
  • q3k 8y ago
    Right, but most of these are just past crimes^W^Wlegacy that Intel has to deal with in the name of backwards compatibility.
    • Klathmon 8y ago
      >most of these are just past crimes^W^Wlegacy This is completely off topic, but I've seen things like the "^W^W" a few times before, and I don't know what it means. Is this a weird encoding mismatch thing? is it from some editor/system that people instinctively type? Is it from some other forum which has a strange markup syntax for something?
      • SteveCoast 8y ago
        Delete word.
      • q3k 8y ago
        Emacs/readline bindings for Delete Word. Open up a bash shell, type in `foo bar baz`, then press ctrl-W twice. '^W' is what would appear instead if you weren't in a readline/emacs editor, but instead a dumb line terminal. Thus, leaving '^W' behind makes it look like you didn't realize what you just corrected is still visible. It's a joke. I've now explained and ruined it.
        • Klathmon 8y ago
          Ah okay makes sense! It's amazing the gaps in knowledge I still have with a lot of things. I've used Linux daily for like 15 years now, and I know about control characters, but since I never really used emacs (or readline beyond the copy+pasted command here or there) I just completely missed the meaning.
• trhway 8y ago
  The ghost of VLIW is still rumbling around like https://en.wikipedia.org/wiki/Elbrus-8S https://en.wikipedia.org/wiki/Elbrus-8S And the RISC (possibly DEC Alpha "inspired") - https://en.wikipedia.org/wiki/Sunway_SW26010 https://en.wikipedia.org/wiki/Sunway_SW26010
• spamizbad 8y ago
  PA-RISC was my favorite from that time. If it had the software stack of Sun commercial Unix might still be a thing.
  • hawflakes 8y ago
    Itanium was created precisely because HP thought it couldn't keep PA-RISC competitive. So they threw in with Intel to create the next great server architecture. As an aside, Merced too forever for Intel to tape out. Part of the agreements between HP and Intel was that they needed to ship chips for HP. As a result, Intel had to fab some of the last PA-RISC chips due to the schedule slip and contractual obligations. I worked on some Itanium system software once upon a time.
    • ghaff 8y ago
      Timing was at least part of the problem with Itanium. Arguably, had Merced (or, ideally, McKinley) shipped while the great Internet buildout was going on, Itanium might have made it over birthing pains before the dot-com crash and then been in a position to ward off Opteron and AMD64 when those arrived. I could argue it was doomed from the beginning as well for various technical reasons given how the industry evolved. But there's at least an argument that better time to market might have been enough to get established as a dominant 64-bit architecture.
      • acdha 8y ago
        Being a couple years late definitely was bad but they also completely blew the performance, especially for ia32 compatibility. Shipping on time would have made the performance gap less bad but I rarely saw it being competitive with what would have been the competition at that time even before you factored cost in. Unless your workload was just Intel’s hand-tuned assembly it was usually cheaper to buy 2 x86 boxes and pocket the difference.
        • ghaff 8y ago
          You're absolutely right, hence my hesitancy. IA-32 emulation performance was one particular weak spot. A fellow analyst at the time said something along the lines of "Itanium's IA-32 performance was not only not in the ballpark; it was not in the parking lot outside the ballpark." Itanium was also, in many ways, designed for a world where ILP, rather than TLP, ruled. That distinction wouldn't become terribly important for a few more years but it would have eventually. Intel made a number of decisions in this vein. See also NetBurst Architecture. (An Intel exec told me, at some point after it had become obvious that multi-core was the future, that Microsoft had really pressured Intel to go down the few/fast cores route.)
• bogomipz 8y ago
  >"Itanium is what EFI was first developed for." What is EFI here - extensible firmware interface? If so what is the connection between that and Itanium?
  • als0 8y ago
    Yes, the standard firmware interface. Those working on the Itanium platform (Intel and presumably HP) wanted to have a boot solution that didn't have the technical shortcomings of existing BIOS designs. That drove an initiative to create a formal spec and an implementation. I believe Itanium was the first platform with EFI, but someone can correct me if I'm wrong.
• ch_123 8y ago
  > the pinnacle of Intel overengineering. I think the i432 would be a worthy challenger to that title https://en.m.wikipedia.org/wiki/Intel_iAPX_432 https://en.m.wikipedia.org/wiki/Intel_iAPX_432
  • kabdib 8y ago
    I think of the iAPX 432 as "over-designed and under-engineered". Intel was writing architectural checks (bit-aligned instructions, capability-based permissions, "everything is an object") they couldn't cash (very, very bad performance). I'm a software guy, so naturally I took a course in VLSI design in college. It was fun. This was maybe a year before the iAPX 432 was canceled; our teacher had some sample chips embedded in clear plastic, gewgaws handed out at some conference he'd been to. He passed them around one day in class, and they were huge and there were like four of them in the processor chipset. And I remember thinking "how the heck is that thing going to be fast with all that off-chip traffic?" And of course it wasn't. Elliot Organick, of Multics fame, wrote a book about the 432 architecture. I just found it on my bookshelf and leafed through it again; I'd forgotten that all of his code examples were in Ada (another "big bet" at the time).
    • GnarfGnarf 8y ago
      I learned FORTRAN from Organick's book in 1965.
    • watersb 8y ago
      "I'm a ____, so naturally I took a course in ______" opens up so many possibilities for me.
• fiddlerwoaroof 8y ago
  There still are interesting cpus available. Like the Greenarrays forth chips: www.greenarraychips.com/home/products/index.html
  • fiddlerwoaroof 8y ago
    Clickable link: http://www.greenarraychips.com/home/products/index.html http://www.greenarraychips.com/home/products/index.html
• iforgotpassword 8y ago
  That's the way it goes. Strongest survive. We're also left with only three browser engines by now, two of them being related.
• garmaine 8y ago
  > Itanium is what EFI was first developed for. Itanium is where the C++ ABI got started. I’m legit confused. Are those supposed to be good things.
  • kijiki 8y ago
    People have different opinions on EFI, but in the time before the modern C++ ABI, every compiler (and often different versions of the same compiler) generated code with different ABI expectations, which made libraries and software distribution absolute hell.
    • garmaine 8y ago
      Sure but as far as ABIs go it is absolute garbage and extremely difficult to work with.
• emXdem 8y ago
  And EFI is a good thing, especially considering the monster dumpster fire that is UEFI?
  • microcolonel 8y ago
    > And EFI is a good thing, especially considering the monster dumpster fire that is UEFI? Well it may be a dumpster fire, but it is the finest, most consistent flame we've gotten from the firmware dumpster; which is why it is fast becoming the only standard firmware interface in actual use. UEFI is fast becoming the standard for ARMv8, it's creeping back to ARMv7, and it's becoming popular with RISC-V. You will either learn to love it, or you will suffer forever. Mark my words, UEFI will still be booting your machine in 2040, when the President is literally a deep fake controlled by a troika of Jack Dorsey, Jeff Bezos, and Priscilla Chan.
    • abecedarius 8y ago
      Not that I've ever coded firmware, but https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware sounded nice.
      • microcolonel 8y ago
        Open Firmware was beautiful, but if you're not on POWER, you're probably not going to see it.
        • watersb 8y ago
          Sun SPARC workstations used it. I wonder how many of those are still in use?
      • burfog 8y ago
        It was FORTH, which most developers really hated. Sometimes the end users even got exposed to bits of FORTH poking out, for example in the syntax for booting. We really just wanted a nice clean 64-bit BIOS, with all the datatypes 64-bit. The BIOS is pretty decent if you strip out redundant interfaces, segmentation, and never-used functionality. Adding extra functionality to firmware is madness. Firmware needs to initialize key hardware like RAM, load a boot loader, and get out of the way. Firmware doesn't need to be practically an OS. The old 16-bit BIOS was actually working OK. Sure, it was nasty to program for, but almost nobody had to deal with that.
• kjs3 8y ago
  Mill is/was nothing but performance art, and apparently is now dead. Proof of this is unlike 1-2 years ago, this thread isn't full of the Mill-shills telling you how Mill would solve all the problems the idiots who developed things like Itanic didn't, but faster, cheaper and with more style.
• zebraflask 8y ago
  Well, shit, so you're saying all of that Itanium was a waste of time?
• MagicPropmaker 8y ago
  Actually, it's been a very exciting time for "CPUs" if you include "GPUs". The programming I can do in CUDA on an NVIDIA GPU is incredible. (Our company is using it for large-scale audio processing.) You can get a true Supercomputer on your desk now for $1,000 -- something that would have been the fastest computer in the world 15 years ago.
• lisper 8y ago
  > Itanium being discontinued further reduces mainstream CPUs to the most boring, safe designs possible IMHO, as someone who cares about security, that's not necessarily a bad thing. (I do lament the passing of tagged architectures, but that ship sailed a long, long time ago.)
  • pjmlp 8y ago
    That ship is back, although in smaller size, because tagged memory is the only way to actually tame C. Solaris with SPARC ADI, Android with the upcoming ARM Memory Extensions are two examples of it.