Billy Brown writes:
> AFAIK, all Microsoft apps have been written as "asynchronous message-passing
> object soup" since sometime in the mid-90s. Also, with the right software
Hey, so they really call OS.send.message() every few 100 machine instructions, or so, and context-switch every 1 us? Really? Mouse handler an object, keyboard handler an object, peripheral storage each an object, each widget an object, each Excel cell an object, almost always sitting in a different node so they have to send messages? We're really talking about Microsoft, Redmond, local universe here, are we?
They can't do it simply because performance on current architectures would suck monumentally. You would have to emulate things, and context switches on current hardware/software architectures are just a tad too expensive for that.
Multithreading!=asynchronous message passing on many tiny objects. We're talking about several thousands primitive (few kBytes) objects which send message packets which are routed by hardware directly -- while the originator code may or may not wait for the ack/result to arrive. If this exists at all, it is academic curiousity at best (Thinking Machines might qualify, though I really doubt they exploited their options fully every time). You certainly can't program these things in standard languages as C/C++ with any efficiency. And I would just love to see a programmer who can handle concurrent nonlinear control flow in a distributed kObject application. This can get arbitrarily hairy.
There's a dearth of apps even for Beowulfs, and god knows how coarse-grain these are. No sir, don't think so.
> you can run a large app over a distributed architecture like this without
> having to explicitly modularize it to fit the hardware's quirks (see
Sure you can. Put x86 opcode sofware emulation into every node, equipartition the old-generation binary over the nodes and send a message to the appropriate node whenever PC leaves your node's address space slice. Redundant as hell (OS nanokernel+ x86 emulator in every node) and efficient as treacle since purely sequential, especially considering that you can't do 4 kCPUs PIII/550 way, and interpreting/compiling existing code into SWAR *would* require true AI.
> http://research.microsoft.com/sn/Millennium/, and especialy
> http://research.microsoft.com/sn/Millennium/Coign.html, for example).
Better yet, the system builds on the existing Windows operating system, so today's software won't become obsolete and programmers can write new software the same way they do now, for one machine or many.
Right. And pilots will worry about pig collision avoidance issues.
Looks nice as a concept, but even if it works it is no panacea. Will alleviate migration psychologically since suggesting you can run your apps on the new platform even if in reality you can't.
> But that isn't especially relevant, anyway. I was talking about programming
> techniques for existing PC hardware. Obviously, radical changes in hardware
Of what possible relevance is existing PC hardware/programming techniques to uploading? I am not sure we're talking in the same language here.
> can require equally radical changes in programming methods.
And even worse: vice versa.