Coming back to a
posting
from 2004, I'm happy to report that fiction is now science.
The Science Blog has an
article
on the first official use of MRI to
"investigate the potential innocence of a woman convicted of poisoning a child in her care."
Link
to the source article in European Psychiatry.
/citations |
permanent link
(0 writeback)
During lunch Paul Dale and I talked about self modifying code and how it might apply to real world systems. Later that same day I did a quick check on Wikipedia to read up on the current state of the art. I was surprised to find a link to a paper about self modifying kernel code by Henry Massalin.
Reading his PhD thesis about the Synthesis kernel, like learning Lisp, is a mind altering experience. This guy is a genius! My first thought after reading the introduction was:
This has to be added to the Movitz kernel!
The Synthesis paper lists four new ideas:
- Run-time code synthesis — a systematic way of creating executable machine code at runtime to optimize frequently-used kernel routines — queues, buffers, context switchers, interrupt handlers, and system call dispatchers — for specific situations, greatly reducing their execution time.
- Fine-grained scheduling — a new process-scheduling technique based on the idea of feedback that performs frequent scheduling actions and policy adjustments (at sub-millisecond intervals) resulting in an adaptive, self-tuning system that can support real-time data streams.
- Lock-free optimistic synchronization is shown to be a practical, efficient alternative to lock-based synchronization methods for the implementation of multiprocessor operating system kernels.
- An extensible kernel design that provides for simple expansion to support new kernel services and hardware devices while allowing a tight coupling between the kernel and the application, blurring the distinction between user and kernel services.
I was curious what a guy like Henry had been doing since finishing his PhD in 1992. Some googling showed that he's working for MicroUnity, a startup that somehow never got any serious traction, filing one patent after another. He is famous
for giving people piggyback rides (the inventors of UNIX among them) and he is now known as Ms. Alexia Massalin. Talk about self modification!
Links:
/citations |
permanent link
(5 writeback)
Wowza... - posted by
Perry E. Metzger
- 10/08/2007 12:51:52
I knew (as Dr. Massalin was then named) Henry at the Columbia CS department twenty years ago. Lots of cool ideas -- superoptimizer, real time kernel code generation, etc -- but not a lot of people have taken them up.
Henry used to work a lot with hardware he'd built himself, and would sometimes rewire breadboards while machines were running without crashing them. It was pretty amazing to watch.
BTW, your email is bouncing, or at least was when I last tried sending you a note.
patents + takeup - posted by
anonymouse moocow
- 10/08/2007 19:25:43
Uhm. "not a lot of people have taken them up" and "filing one patent after another" just might be related. Patent monopolies have long been known to slow innovation, contrary to the patentist propaganda. If the patent-restricted ideas (in practice, software patents cover ideas, whatever the theory) are any use, expect greater takeup when the monopolies expire, much like with public key crypto (once-RSA) or decent virtualisation (once-IBM).
- posted by
Marijn Haverbeke
- 10/10/2007 22:48:45
It is interesting how nicely the partial evaluation could be mapped to closures. It should be possible for a Lisp implementation to re-compile the code inside a closure, substituting known values for the closed-over variables. You wouldn't want to do this for *every* closure, I suppose, so either the compiler would have to be clever enough to figure out when it is worthwhile (hard to do -- after a closure has been called X times?), or the programmer could somehow specify it in his program text.
- posted by
Marijn Haverbeke
- 10/13/2007 18:50:19
(that is, if the closed-over variables are not mutated, which could be checked statically)
Comments on Henry Massalin - posted by
Tim Josling
- 01/21/2008 21:10:41
I came across Henry's paper at 10:30 the other night and stayed up to 2am reading it. There are some really powerful ideas in there. When I finished reading it though, there is a lot more I would have liked to know eg how exactly did he manage the tradeoffs involved? About 10 years ago I actually implemented a similar design to Henry's. In our case it was a complex table lookup routine which had been rewritten twice already for performance (it was being called over 2X10**8 times per day). We took a high level description of the tables and generated templates for the lookup routines. When the lookups arrived, we used the templates to generate custom code for that set of keys and values. This sped up the routines by a factor of 6 (similar to what Henry achieved). So I know this stuff works. Interestingly the total number of lines of code was reduced with our approach due to the generated templates etc. It was also robust - there was more validation and every one of the ~10**11 calls since then has worked correctly. This sort of thing could be used for dynamic languages to make them as or more efficient than statically types languages. One key to success with this approach is keeping the high level description of the problem space. You generate machine code right from the high level description, which allows a lot of powerful optimisations. Going through layers messes things up.
