6 ms·

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 distrib

by 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.
    - rcxdude 13y ago
      I don't think it's that difficult for package managers to deal with. All of them have a way to hook post-install actions to run an arbitrary script. You might wind up with another step added to the scripts used to produce the package which automatically generates this hook, and the checksums might be slightly difficult (but then storing specialised binaries separately isn't hard). I guess the biggest infrastructure change might be running the specialisation on a dedicated machine and hosting your own packages. This way you could also checksum and sign the specialised binaries as well.
      - rst 13y ago
        I'm not sure what you're suggesting here. Adding the "specialization" hooks to the post-install script in every single package is genuinely hard --- Debian, for example, has literally thousands of packages, maintained by hundreds of packagers, some of which squirrel .so files and the like in all sorts of places you might not expect them without detailed knowledge of the package in question. And that's before you even consider software installed on Debian boxes by other systems entirely, like npm or Rubygems. Running the specialization on build machines is easier, if you have compilers there that produce binaries directly, and not IR. But that's exactly what the Mill crew is trying to avoid by producing the IR! (Though it may actually be a better fit to an infrastructure which is already set up to produce distinct binaries for different processor architectures (x86, x86-64, ARM, and several others), and which is not set up to expect the "specialization" hook as a necessary post-install step which each package must separately provide for...)
_wmd 13y ago
Assuming their translation step is as cheap as they claim (single pass rewrite/substitute missing hardware for software macros), it's conceivable that there isn't much value in persistently caching the result. In that case, everything could be contained to a single ld.so patch, or (doubtfully) a modification to the kernel ELF loader Finally, and although it is less common now, in prior days Linux already had a post-install processing step for binaries on certain distributions - prelink(8) ( https://en.wikipedia.org/wiki/Prelink https://en.wikipedia.org/wiki/Prelink )
- rst 13y ago
  Also Mac OSX "prebinding" and (in later releases) dyld cacheing. Though just skipping the cache entirely is certainly the quickest way to get something running --- and quite a few plausible server workloads will pay the penalty mainly at startup, when it might not matter so much. (But yeah, keep it in user space, if only to make it easier to debug!)
SigmundA 13y ago
Sounds like Java and .Net Bytecode. I don't deal with Java much, but in .Net world IL is jitted on demand into memory and thrown away when the process is recycled unless you do ngen, which is difficult to do in many situations (web applications). I think many underestimate the overhead involved in compiling IL to native including MS themselves. There are user perceivable delays in application startup time in larger code bases that lead to a worse user experience. Why they don't cache jitted code to disk after 5-6 version of .Net is beyond me, even Mono has a AOT compiler. I am starting to appreciate the AOT approach of "native" code (C,C++,GO), do as much as possible one time, at compile time. Don't make the user wait because you want to distribute a single portable binary.
- ajanuary 13y ago
  It's often recommended to run ngen as a part of the user install process for larger applications.
  - snuxoll 13y ago
    Sometimes ngen produces worse code than the JIT does since it has no knowledge of execution state. Compile your assemblies which can be easily optimized, but you may actually be better off losing a couple of cycles waiting for the JIT to compile a method on first call in certain cases.
jfb 13y ago
I would like it very much if alternative to '70s era operating systems were to flourish on newer hardware platforms. If Mill hardware backs up the performance claims, it would open an interesting door that's been shut to non Multics-likes for too long.

by rst 13y ago

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.
  - rcxdude 13y ago
    I don't think it's that difficult for package managers to deal with. All of them have a way to hook post-install actions to run an arbitrary script. You might wind up with another step added to the scripts used to produce the package which automatically generates this hook, and the checksums might be slightly difficult (but then storing specialised binaries separately isn't hard). I guess the biggest infrastructure change might be running the specialisation on a dedicated machine and hosting your own packages. This way you could also checksum and sign the specialised binaries as well.
    - rst 13y ago
      I'm not sure what you're suggesting here. Adding the "specialization" hooks to the post-install script in every single package is genuinely hard --- Debian, for example, has literally thousands of packages, maintained by hundreds of packagers, some of which squirrel .so files and the like in all sorts of places you might not expect them without detailed knowledge of the package in question. And that's before you even consider software installed on Debian boxes by other systems entirely, like npm or Rubygems. Running the specialization on build machines is easier, if you have compilers there that produce binaries directly, and not IR. But that's exactly what the Mill crew is trying to avoid by producing the IR! (Though it may actually be a better fit to an infrastructure which is already set up to produce distinct binaries for different processor architectures (x86, x86-64, ARM, and several others), and which is not set up to expect the "specialization" hook as a necessary post-install step which each package must separately provide for...)

_wmd 13y ago

Assuming their translation step is as cheap as they claim (single pass rewrite/substitute missing hardware for software macros), it's conceivable that there isn't much value in persistently caching the result. In that case, everything could be contained to a single ld.so patch, or (doubtfully) a modification to the kernel ELF loader Finally, and although it is less common now, in prior days Linux already had a post-install processing step for binaries on certain distributions - prelink(8) ( https://en.wikipedia.org/wiki/Prelink https://en.wikipedia.org/wiki/Prelink )

rst 13y ago
Also Mac OSX "prebinding" and (in later releases) dyld cacheing. Though just skipping the cache entirely is certainly the quickest way to get something running --- and quite a few plausible server workloads will pay the penalty mainly at startup, when it might not matter so much. (But yeah, keep it in user space, if only to make it easier to debug!)

SigmundA 13y ago

Sounds like Java and .Net Bytecode. I don't deal with Java much, but in .Net world IL is jitted on demand into memory and thrown away when the process is recycled unless you do ngen, which is difficult to do in many situations (web applications). I think many underestimate the overhead involved in compiling IL to native including MS themselves. There are user perceivable delays in application startup time in larger code bases that lead to a worse user experience. Why they don't cache jitted code to disk after 5-6 version of .Net is beyond me, even Mono has a AOT compiler. I am starting to appreciate the AOT approach of "native" code (C,C++,GO), do as much as possible one time, at compile time. Don't make the user wait because you want to distribute a single portable binary.

ajanuary 13y ago
It's often recommended to run ngen as a part of the user install process for larger applications.
- snuxoll 13y ago
  Sometimes ngen produces worse code than the JIT does since it has no knowledge of execution state. Compile your assemblies which can be easily optimized, but you may actually be better off losing a couple of cycles waiting for the JIT to compile a method on first call in certain cases.

jfb 13y ago

I would like it very much if alternative to '70s era operating systems were to flourish on newer hardware platforms. If Mill hardware backs up the performance claims, it would open an interesting door that's been shut to non Multics-likes for too long.