5 ms·

Also, this paper suggests that the answer to multi-tasking problems is to move the complexity out into the language. It's funny how PL researchers will always s

Also, this paper suggests that the answer to multi-tasking problems is to move the complexity out into the language. It's funny how PL researchers will always spin the situation so that it demands more PL research. If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching. Of course, you'd need a simple system and not a billion daemons running in the background waiting to be exploited by criminals.

tmurray 15y ago
"If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching." You probably don't want that either because the cost of moving data between cores will be so high from both a performance and a power consumption POV. The days of free coherency between cores will eventually come to an end; you can already see evidence of that in multi-socket Intel and AMD machines (if you try to ignore the NUMA nature of memory, you swamp the link between sockets and perf tanks in a variety of apps).
- javascriptlol 15y ago
  Why would you be moving data between cores? I'm talking about an arrangement where each core is dedicated to a single program. No sharing of memory, even via the kernel. Each hardware devices talks to a single core only. Multiplexing of hardware would be done in.. hardware. For all intents and purposes the "core" could be out on the network. All this throughput nonsense is benchmrk lies. Websites are not as a general rule highly responsive. They have huge variability in response times. Who cares if it costs a bit more to run the system if it means having a nice predictable system built for simplcity and safety from the ground up?
  - jedbrown 15y ago
    You need an event-driven system because the number of "tasks" rarely matches the number of physical cores available. One tried and true, fault-tolerant event-driven interface is provided by the kernel: processes (and threads). It has interfaces for binding to NUMA regions and such. Any system you design will have to tackle a lot of the hard problems that kernels deal with. Now maybe you have a simpler system in mind, but it has to be drastically better for anyone to consider giving up binary compatibility.
    - javascriptlol 15y ago
      You are completely misunderstanding me. I am not saying "let's all move to this new utopian system". I am suggesting that we move away from the idea of making universal systems entirely. Write software that is small enough that complete rewrites can be accomplished without trouble. The current situation is to build ourselves a problem that gets harder and harder to undo as time goes on. You can't call something that's been around for less than 100 years "tried and true". I'm not saying we can't have "virtual CPUs" for tasks that can handle a performance hit. But it is becoming an unavoidable impediment. "Simple" doesn't mean "easy". It means predictable, small and undoable. The exact opposite to where we are heading.
      - jedbrown 15y ago
        I write a lot of code that runs in funny environments like the Compute Node Kernel running on Blue Gene systems, with offset-mapped memory (no TLB) and no over-subscription. It's fantastic for reproducible performance, but it's a specialized environment and people want to do things like run Python (as "glue" for some scientific applications) which needs dynamic loading. Since all IO is exported to separate IO nodes, and due to file system consistency semantics, dynamic loading is a tremendous bottleneck. This has escalated to the point where people burn a quarter million core hours to load Python (plus C extension modules) once on a large machine. To really solve the scalability problem, we needed to make dlopen() avoid touching the file system (by patching ld.so and implementing the POSIX file API with collective semantics served over the fast network). The point here is that there are good reasons to want to use different systems together and then you end up putting in lot of effort working around the limitations of the specialized environments.
      - tmurray 15y ago
        It sounds like you're basically proposing Plan 9--lots of very small, single-purpose components with one standardized way of passing data between them used across the entire system. Also, you can ask a lot of people to give up binary compatibility and be okay, but asking people to give up source compatibility and change applications is a much, much harder pill to swallow. Specialized environments (like the syscall-shipping CNK on Blue Gene like jedbrown mentions) are usually seen as something to work around because they are impediments to productivity. A more robust system wouldn't be considered useful if everyone has to start from scratch.
  - smcdow 15y ago
    How do you handle DMA and other I/O in your system?
    - javascriptlol 15y ago
      Each hardware device is accessed by a single process at a time. Any multiplexing that needs to be fast is done in hardware. Other multiplexing can be done in user space. For example, and application can request a dedicated channel to some blocks on the hard disk (adjudicated by the OS) or just use another hard disk. Remember, we're building simple applications here so things don't need to constantly write off the the disk for various tasks. You would only be dealing with the disk if your actual data was too big to fit into memory. Cases like that need careful design, not delegation off to some other programmer who doesn't know your problem. If you're running a server application you split it into some reasonable number of tasks and allocate cores to them as needed. Nothing else runs on the system at all. If you need more cores either upgrade your hardware or you build another identical machine and talk to it over the network. If you look at the way Moore designs, he's crafting a complete artifact to solve a specific problem, not just throwing generic parts together.
lusr 15y ago
Jonathan Shapiro is not a traditional PL researcher. He is the architect and lead developer of EROS (www.eros-os.org) and CapROS (http://www.capros.org http://www.capros.org), and the author of a vast number of papers on secure and high-performance reliable real-time operating systems. The confinement mechanism in EROS was provably secure (i.e. provably impossible for applications to leak permissions) by Shapiro, and AFAIK is still the only meaningful and practical security mechanism demonstrated to do so, which is a pretty significant contribution in the field of computer science. (Although having been a voyeur of his work for over a decade now, I'm sure he would be quick to point out that much of EROS was based on formalising ideas from GNOSIS and KeyKOS, and the work of Hardy, Franz, Landau et al. over 20-30 years earlier.) BitC evolved out of a need to prove that the implementation of the confinement mechanism (prototyped in EROS) matched the model (proven in his PhD thesis), and so the CapROS system (built in BitC) was born (well that plus some architectural changes based on lessons learned from EROS). From that perspective it's much more than just another systems programming language - it has a definitive purpose to advance the state of the art in practical and theoretical computer science. (FWIW, they never did accomplish this goal [http://www.bitc-lang.org/docs/bitc/bitc-origins.html] http://www.bitc-lang.org/docs/bitc/bitc-origins.html]).
- javascriptlol 15y ago
  A better idea would be to just build a small system whose security was obvious. Computer scientists are right to mimic mathematics. They're just mimicking it too directly. Mathematics is based on construction from simple axioms and cross-checking of different theories. Computer systems should be reduced to small parts with redundant checks against human error. If you prove a kernel "correct" that just means it will be that much harder to rewrite it if it turns out not to be what you wanted.
  - javascriptlol 15y ago
    Why downvote? HN has really gone down the tubes. Why do peopel who downvote harmless comments without a response get downvote privileges?
    - 15y ago

tmurray 15y ago

"If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching." You probably don't want that either because the cost of moving data between cores will be so high from both a performance and a power consumption POV. The days of free coherency between cores will eventually come to an end; you can already see evidence of that in multi-socket Intel and AMD machines (if you try to ignore the NUMA nature of memory, you swamp the link between sockets and perf tanks in a variety of apps).

javascriptlol 15y ago
Why would you be moving data between cores? I'm talking about an arrangement where each core is dedicated to a single program. No sharing of memory, even via the kernel. Each hardware devices talks to a single core only. Multiplexing of hardware would be done in.. hardware. For all intents and purposes the "core" could be out on the network. All this throughput nonsense is benchmrk lies. Websites are not as a general rule highly responsive. They have huge variability in response times. Who cares if it costs a bit more to run the system if it means having a nice predictable system built for simplcity and safety from the ground up?
- jedbrown 15y ago
  You need an event-driven system because the number of "tasks" rarely matches the number of physical cores available. One tried and true, fault-tolerant event-driven interface is provided by the kernel: processes (and threads). It has interfaces for binding to NUMA regions and such. Any system you design will have to tackle a lot of the hard problems that kernels deal with. Now maybe you have a simpler system in mind, but it has to be drastically better for anyone to consider giving up binary compatibility.
  - javascriptlol 15y ago
    You are completely misunderstanding me. I am not saying "let's all move to this new utopian system". I am suggesting that we move away from the idea of making universal systems entirely. Write software that is small enough that complete rewrites can be accomplished without trouble. The current situation is to build ourselves a problem that gets harder and harder to undo as time goes on. You can't call something that's been around for less than 100 years "tried and true". I'm not saying we can't have "virtual CPUs" for tasks that can handle a performance hit. But it is becoming an unavoidable impediment. "Simple" doesn't mean "easy". It means predictable, small and undoable. The exact opposite to where we are heading.
    - jedbrown 15y ago
      I write a lot of code that runs in funny environments like the Compute Node Kernel running on Blue Gene systems, with offset-mapped memory (no TLB) and no over-subscription. It's fantastic for reproducible performance, but it's a specialized environment and people want to do things like run Python (as "glue" for some scientific applications) which needs dynamic loading. Since all IO is exported to separate IO nodes, and due to file system consistency semantics, dynamic loading is a tremendous bottleneck. This has escalated to the point where people burn a quarter million core hours to load Python (plus C extension modules) once on a large machine. To really solve the scalability problem, we needed to make dlopen() avoid touching the file system (by patching ld.so and implementing the POSIX file API with collective semantics served over the fast network). The point here is that there are good reasons to want to use different systems together and then you end up putting in lot of effort working around the limitations of the specialized environments.
    - tmurray 15y ago
      It sounds like you're basically proposing Plan 9--lots of very small, single-purpose components with one standardized way of passing data between them used across the entire system. Also, you can ask a lot of people to give up binary compatibility and be okay, but asking people to give up source compatibility and change applications is a much, much harder pill to swallow. Specialized environments (like the syscall-shipping CNK on Blue Gene like jedbrown mentions) are usually seen as something to work around because they are impediments to productivity. A more robust system wouldn't be considered useful if everyone has to start from scratch.
- smcdow 15y ago
  How do you handle DMA and other I/O in your system?
  - javascriptlol 15y ago
    Each hardware device is accessed by a single process at a time. Any multiplexing that needs to be fast is done in hardware. Other multiplexing can be done in user space. For example, and application can request a dedicated channel to some blocks on the hard disk (adjudicated by the OS) or just use another hard disk. Remember, we're building simple applications here so things don't need to constantly write off the the disk for various tasks. You would only be dealing with the disk if your actual data was too big to fit into memory. Cases like that need careful design, not delegation off to some other programmer who doesn't know your problem. If you're running a server application you split it into some reasonable number of tasks and allocate cores to them as needed. Nothing else runs on the system at all. If you need more cores either upgrade your hardware or you build another identical machine and talk to it over the network. If you look at the way Moore designs, he's crafting a complete artifact to solve a specific problem, not just throwing generic parts together.

lusr 15y ago

Jonathan Shapiro is not a traditional PL researcher. He is the architect and lead developer of EROS (www.eros-os.org) and CapROS (http://www.capros.org http://www.capros.org), and the author of a vast number of papers on secure and high-performance reliable real-time operating systems. The confinement mechanism in EROS was provably secure (i.e. provably impossible for applications to leak permissions) by Shapiro, and AFAIK is still the only meaningful and practical security mechanism demonstrated to do so, which is a pretty significant contribution in the field of computer science. (Although having been a voyeur of his work for over a decade now, I'm sure he would be quick to point out that much of EROS was based on formalising ideas from GNOSIS and KeyKOS, and the work of Hardy, Franz, Landau et al. over 20-30 years earlier.) BitC evolved out of a need to prove that the implementation of the confinement mechanism (prototyped in EROS) matched the model (proven in his PhD thesis), and so the CapROS system (built in BitC) was born (well that plus some architectural changes based on lessons learned from EROS). From that perspective it's much more than just another systems programming language - it has a definitive purpose to advance the state of the art in practical and theoretical computer science. (FWIW, they never did accomplish this goal [http://www.bitc-lang.org/docs/bitc/bitc-origins.html] http://www.bitc-lang.org/docs/bitc/bitc-origins.html]).

javascriptlol 15y ago
A better idea would be to just build a small system whose security was obvious. Computer scientists are right to mimic mathematics. They're just mimicking it too directly. Mathematics is based on construction from simple axioms and cross-checking of different theories. Computer systems should be reduced to small parts with redundant checks against human error. If you prove a kernel "correct" that just means it will be that much harder to rewrite it if it turns out not to be what you wanted.
- javascriptlol 15y ago
  Why downvote? HN has really gone down the tubes. Why do peopel who downvote harmless comments without a response get downvote privileges?
  - 15y ago