9 ms·

It's really exciting, but here are a few worries I have about their ability to meet their performance claims: 1) I don't see that they'll be able to save much

It's really exciting, but here are a few worries I have about their ability to meet their performance claims: 1) I don't see that they'll be able to save much power on their cache hierarchy relative to conventional machines. Sure, backless memory will save them some traffic but on the other hand they won't e able to take advantage of the sorts of immense optimization resources that Intel has, so that fraction of chip power to performance isn't going away. 2) The bypass network on a conventional out of order chip takes up an amount of power similar to the execution units, and I expect that the Mill's belt will be roughly equivalent. 3) I'm worried on the software front. The differences between how they and LLVM handle pointer is causing them trouble, and porting an OS to the Mill looks to be a pretty complicated business compared to most other architectures. It's certainly not impossible, but it's still a big problem if they're worried about adoption. All of which is to say, I think the 10x they're talking about is unrealistic. The Mill is full of horribly clever ideas which I'm really excited about and I do think their approach seems workable and advantageous, but I'd expect 3x at most when they've had time to optimize. The structures in a modern CPU that provide out of order execution and the top-level TLB are big and power hungry, but they're not 90% of power use. If they're going to hit it big they'll probably start out in high-end embedded. Anything where you have a RTOS running on a fast processor, and your set of software is small enough that porting it all isn't a big problem. Also, the metadata isn't like a None in Python, it's like a Maybe in Haskell! You can string them together and only throw an exception on side effects in a way that makes speculation (and vector operation) in this machine much nicer. EDIT: Whatever the result of the Mill itself, it contains a large number of astoundingly clever ideas some of which would be useful even without all the other ideas. Like you could drop in Mill load semantics to most in-order processors and you'd have to do something different with how they interact with function calls but it would still be pretty useful. EDIT2: I may sound pessimistic above, but I would still totally give them money if I were a registered investor. The outside view just says that new processors that try to change lots of things at once is pretty bad even if, on the inside view, they have a good story for how their going to overcome the challenges they'll face.

rst 13y ago
One tricky issue in porting an existing OS to the Mill is their AS/400-style portability strategy (as outlined by Godard in the comments): binaries are distributed as "Mill IR", and compiled to local binary, which gets cached for the next execution. The problem is where to put this cache, and how the OS deals with it. Say, for example, you put the cache in the file system. OK, who has write permission, and can the "cached local binary" be written on first execution by a user who doesn't have write permission on the binary being "localized"? (Or could the translator be run on "apt-get install ..." --- and if so, who trains apt to do that?) And so forth. Putting the cache someplace that is hidden from the "normal" OS is possible, but that has problems, too. At the very least, you'd need to figure out what to do if the hidden whatever-it-is runs out of space. (And how doing I/O to it would interfere with other OS-level performance optimizations, like scheduling of disk seeks.) IBM could finesse these problems on the AS/400 because they controlled everything about it, hardware to OS to UI. And there are niches with high performance requirements that could live with a nonstandard OS. But for general-purpose computing, it could get awkward. (Perhaps awkward enough to consider TransMeta's strategy of doing JIT translation to actual machine instructions, which let them keep the "real instruction" cache entirely in dedicated RAM --- though that has problems too.)
- Symmetry 13y ago
  I sort of assumed that they would just use fat binaries, and store the cached, translated version in the same file as the intermediate code.
  - igodard 13y ago
    Exactly. Most will specialize at install-time. Code without an install step will specialize at first execution; the IR is designed for specialize speed. The specializer can also be run free-standing as well, to create ROMS and where installations want to ensure distribution uniformity.
    - rst 13y ago
      Specialization at install time is, in a lot of ways, the most reasonable answer. (It completely sidesteps the permissioning issues involved in write permission on a global cache at first execution, for example.) However, hacking an existing package manager to do this job may not be entirely trivial --- and, in typical server environments these days, there will often be more than one package manager to hack. Language-based package managers like Rubygems and npm, for example, build binary extensions for Ruby and Node/Javascript as part of their job. Updating any of them to deal with an additional "specialization" step may not be much of a big deal --- but dealing with all of them might be. (Particularly if you have sysadmins that like to, say, run something like debsums to verify that the installed files are exactly the same as the ones in the package --- which might fail on a "fattened" binary.) If you've already had coffee with the maintainers of, say, apt (or rpm), npm (or Rubygems, or PIP), and a few others, hashed out the issues, and have worked out that it's no big deal, that's great! But if not --- management of servers these days is complicated in ways that you'd never guess from just looking at the hardware, and a few of those coffee chats might be enlightening.

rst 13y ago

One tricky issue in porting an existing OS to the Mill is their AS/400-style portability strategy (as outlined by Godard in the comments): binaries are distributed as "Mill IR", and compiled to local binary, which gets cached for the next execution. The problem is where to put this cache, and how the OS deals with it. Say, for example, you put the cache in the file system. OK, who has write permission, and can the "cached local binary" be written on first execution by a user who doesn't have write permission on the binary being "localized"? (Or could the translator be run on "apt-get install ..." --- and if so, who trains apt to do that?) And so forth. Putting the cache someplace that is hidden from the "normal" OS is possible, but that has problems, too. At the very least, you'd need to figure out what to do if the hidden whatever-it-is runs out of space. (And how doing I/O to it would interfere with other OS-level performance optimizations, like scheduling of disk seeks.) IBM could finesse these problems on the AS/400 because they controlled everything about it, hardware to OS to UI. And there are niches with high performance requirements that could live with a nonstandard OS. But for general-purpose computing, it could get awkward. (Perhaps awkward enough to consider TransMeta's strategy of doing JIT translation to actual machine instructions, which let them keep the "real instruction" cache entirely in dedicated RAM --- though that has problems too.)

Symmetry 13y ago
I sort of assumed that they would just use fat binaries, and store the cached, translated version in the same file as the intermediate code.
- igodard 13y ago
  Exactly. Most will specialize at install-time. Code without an install step will specialize at first execution; the IR is designed for specialize speed. The specializer can also be run free-standing as well, to create ROMS and where installations want to ensure distribution uniformity.
  - rst 13y ago
    Specialization at install time is, in a lot of ways, the most reasonable answer. (It completely sidesteps the permissioning issues involved in write permission on a global cache at first execution, for example.) However, hacking an existing package manager to do this job may not be entirely trivial --- and, in typical server environments these days, there will often be more than one package manager to hack. Language-based package managers like Rubygems and npm, for example, build binary extensions for Ruby and Node/Javascript as part of their job. Updating any of them to deal with an additional "specialization" step may not be much of a big deal --- but dealing with all of them might be. (Particularly if you have sysadmins that like to, say, run something like debsums to verify that the installed files are exactly the same as the ones in the package --- which might fail on a "fattened" binary.) If you've already had coffee with the maintainers of, say, apt (or rpm), npm (or Rubygems, or PIP), and a few others, hashed out the issues, and have worked out that it's no big deal, that's great! But if not --- management of servers these days is complicated in ways that you'd never guess from just looking at the hardware, and a few of those coffee chats might be enlightening.