5 ms·

Multicore requires OS rework, Windows architect advises

26 points by abennett 17y ago

rpledge 17y ago
This will become even more relevant as core counts above 32 become common place. Sadly most programmers have a hard time dealing with more than 1 thread. I agree a new paradigm is needed to solve this problem.
- Aegean 17y ago
  One good way to tackle is to use threads for hiding shared data. In a nutshell, instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate. The result is easy, deterministic concurrency, and many cores may be used this way. One of the founding goals of the Go language is also based on this idea.
  - bad_user 17y ago
    > instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate That's not enough. If we are to believe Intel that we'll have processors with thousands of cores, then you have a new problem ... how are you going to keep all those cores busy (regardless of the actual number, from 32 to 20000)? Another problem would be that you also want it to scale horizontally ... there's no reason why you'd want to know if another thread runs in the same process or on some other machine in China. All you care about is that you can spawn it, send a message to it and get some results. Multiple techniques for concurrency will develop in parallel (which is a PITA since devs will need to have a lot of experience to choose), although I'm pretty sure that STM will be the most popular technique (although the handling of concurrency shouldn't be limited just to controlling access to RAM).
- wheaties 17y ago
  Thankfully people are pushing through STM and actor based parallelism. There's already an STM for Boost, Clojure, Erlang, and Scala to name a few.
  - jshen 17y ago
    will there be an issue with stm when core counts get large enough that there are a lot of failed transactions? I'm not well read on stm, but intuitively this would seem to be an issue.
  - dkersten 17y ago
    And dataflow - a little bit, at least.
  - runT1ME 17y ago
    I'm really not sure Actors are the silver bullet. I write telcom software, and its just as easy to get a deadlock (ok maybe a little harder) using Actors than traditional locking.
    - dkersten 17y ago
      I also write (or wrote, up until recently) telecom software and, while I like Actors (certainly compared to monitor-based concurrency), I agree that they aren't really the silver bullet. I spend a lot of time thinking about concurrency and I've come to the conclusion that the dificulties of concurrency all come from the fact that everythings manual - the programmer has to carefully think about how everything fits together, or risk all kinds of problems: deadlock, inconsistent data, bad parallelism etc. The Actor model certainly makes things easier, but doesn't work as well for some problems. Its also still a manual task. STM improves monitor-based systems by alleviating the task of carefully placing locks around critical sections of code, but you must still determine where to place the transactions and this can still be a big task. So far, the only model that, IMHO, lends itself to implicit programmer-free concurrency is dataflow. Ultimately, I think we need a language that exposes all three models (monitor, actor, dataflow) as language primitives, handling it implicitly and transparently where possible.
Aegean 17y ago
That's what my startup is about. Leveraging multiple cores using a hypervisor: http://www.l4dev.org http://www.l4dev.org
- daeken 17y ago
  Someone's actually commercializing L4? I've been hoping for that for a long time; good luck! While my own OS is very different (pure managed and all that jazz), I'll never forget the things I learned from L4, and it's great to see that someone's actually doing something real with it.
  - Aegean 17y ago
    I've been working on it for quite some time. Its nearly ready now, and it supports the quad core Cortex A9 - the latest intel rival mobile cpu.
- impeachgod 17y ago
  If it's not a secret, can you tell us more about your startup?
  - Aegean 17y ago
    Sure. It's a scrappy startup with a small team. Company Name: B Labs Company Founded: 2009 Age: 27 Product: B Labs develops a hypervisor/virtualization platform for high-end embedded systems. Benefits: - Multi-core processors of the future are utilized. - Legacy applications ported over to multiple cpus. - Security and separation of software components. - Real-time and non real-time rich OS deployed on single platform. http://www.b-labs.co.uk http://www.b-labs.co.uk
Retric 17y ago
It was my understanding that this was how PS3's operate. The OS get's to use one of the more limited cores and the running program gets everything else.
aliston 17y ago
I'm not sure I agree with the "common" use case Probert is talking about. Sure, most people have multiple programs running at once, but a lot of the time the background processes are more or less running at idle or minimal CPU usage. So, I'm not sure that assigning a dedicated CPU per process would speed up things all that much...
losethos 17y ago
The LoseThos operating system was designed from scratch and supports multicore. http://www.losethos.com http://www.losethos.com It does master-slave multicore, not SMP. See the multicore flight simulator, done with multicore and not GPU. http://www.losethos.com/videos/flightsim.html http://www.losethos.com/videos/flightsim.html
xilun666 17y ago
Either this is bad journalism or the "architect" is really high. Because proposed re-architecture makes absolutely no sense. The article starts with an obvious observation, being that scheduling (in its largest meaning) often is crap in real (Windows?) systems. It concludes with complete meaningless bullshit where applications, now renamed, would have a dedicated CPU. What the point? Doing hard real-time? What does that even concretely means for "runtimes" of have a "dedicated" CPU (wich, given the complexity of modern architectures, would not really be in a strict fashion) and to do resource management thanks to metadata inserted by the compiler? What is really needed is more effective ways for applications to sends tips to the kernel about what is going on, what should run at high priority, what should be cached, what should not be, and so over. Forbidding some programs to use some cores because you have many makes little sense as a way to re-architecture an operating system. Because it already happens anyway on current designs (not really forbidden, but when you have few services consuming less than 1 percent of 1 core in the background, and/or running with extremely low priority they will be near to unnoticeable, and truly unnoticeable from the point of view of the user). To get a responsive word processor no matter an anti-virus is loaded or not, a simple solution can work really well now; priorities of scheduling. Given that really background priorities are among the rare things that works fairly well under windows (like 10x better than with a vanilla Linux kernel), if the "architect" is experiencing random slow down of Word because of his "antivirus", its because his "antivirus" is total utter crap, not because a new "architecture" of OS is needed.

26 points by abennett 17y ago

This will become even more relevant as core counts above 32 become common place. Sadly most programmers have a hard time dealing with more than 1 thread. I agree a new paradigm is needed to solve this problem.

Aegean 17y ago
One good way to tackle is to use threads for hiding shared data. In a nutshell, instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate. The result is easy, deterministic concurrency, and many cores may be used this way. One of the founding goals of the Go language is also based on this idea.
- bad_user 17y ago
  > instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate That's not enough. If we are to believe Intel that we'll have processors with thousands of cores, then you have a new problem ... how are you going to keep all those cores busy (regardless of the actual number, from 32 to 20000)? Another problem would be that you also want it to scale horizontally ... there's no reason why you'd want to know if another thread runs in the same process or on some other machine in China. All you care about is that you can spawn it, send a message to it and get some results. Multiple techniques for concurrency will develop in parallel (which is a PITA since devs will need to have a lot of experience to choose), although I'm pretty sure that STM will be the most popular technique (although the handling of concurrency shouldn't be limited just to controlling access to RAM).
wheaties 17y ago
Thankfully people are pushing through STM and actor based parallelism. There's already an STM for Boost, Clojure, Erlang, and Scala to name a few.
- jshen 17y ago
  will there be an issue with stm when core counts get large enough that there are a lot of failed transactions? I'm not well read on stm, but intuitively this would seem to be an issue.
- dkersten 17y ago
  And dataflow - a little bit, at least.
- runT1ME 17y ago
  I'm really not sure Actors are the silver bullet. I write telcom software, and its just as easy to get a deadlock (ok maybe a little harder) using Actors than traditional locking.
  - dkersten 17y ago
    I also write (or wrote, up until recently) telecom software and, while I like Actors (certainly compared to monitor-based concurrency), I agree that they aren't really the silver bullet. I spend a lot of time thinking about concurrency and I've come to the conclusion that the dificulties of concurrency all come from the fact that everythings manual - the programmer has to carefully think about how everything fits together, or risk all kinds of problems: deadlock, inconsistent data, bad parallelism etc. The Actor model certainly makes things easier, but doesn't work as well for some problems. Its also still a manual task. STM improves monitor-based systems by alleviating the task of carefully placing locks around critical sections of code, but you must still determine where to place the transactions and this can still be a big task. So far, the only model that, IMHO, lends itself to implicit programmer-free concurrency is dataflow. Ultimately, I think we need a language that exposes all three models (monitor, actor, dataflow) as language primitives, handling it implicitly and transparently where possible.

Aegean 17y ago

That's what my startup is about. Leveraging multiple cores using a hypervisor: http://www.l4dev.org http://www.l4dev.org

daeken 17y ago
Someone's actually commercializing L4? I've been hoping for that for a long time; good luck! While my own OS is very different (pure managed and all that jazz), I'll never forget the things I learned from L4, and it's great to see that someone's actually doing something real with it.
- Aegean 17y ago
  I've been working on it for quite some time. Its nearly ready now, and it supports the quad core Cortex A9 - the latest intel rival mobile cpu.
impeachgod 17y ago
If it's not a secret, can you tell us more about your startup?
- Aegean 17y ago
  Sure. It's a scrappy startup with a small team. Company Name: B Labs Company Founded: 2009 Age: 27 Product: B Labs develops a hypervisor/virtualization platform for high-end embedded systems. Benefits: - Multi-core processors of the future are utilized. - Legacy applications ported over to multiple cpus. - Security and separation of software components. - Real-time and non real-time rich OS deployed on single platform. http://www.b-labs.co.uk http://www.b-labs.co.uk

Retric 17y ago

It was my understanding that this was how PS3's operate. The OS get's to use one of the more limited cores and the running program gets everything else.

aliston 17y ago

I'm not sure I agree with the "common" use case Probert is talking about. Sure, most people have multiple programs running at once, but a lot of the time the background processes are more or less running at idle or minimal CPU usage. So, I'm not sure that assigning a dedicated CPU per process would speed up things all that much...

losethos 17y ago

The LoseThos operating system was designed from scratch and supports multicore. http://www.losethos.com http://www.losethos.com It does master-slave multicore, not SMP. See the multicore flight simulator, done with multicore and not GPU. http://www.losethos.com/videos/flightsim.html http://www.losethos.com/videos/flightsim.html

xilun666 17y ago

Either this is bad journalism or the "architect" is really high. Because proposed re-architecture makes absolutely no sense. The article starts with an obvious observation, being that scheduling (in its largest meaning) often is crap in real (Windows?) systems. It concludes with complete meaningless bullshit where applications, now renamed, would have a dedicated CPU. What the point? Doing hard real-time? What does that even concretely means for "runtimes" of have a "dedicated" CPU (wich, given the complexity of modern architectures, would not really be in a strict fashion) and to do resource management thanks to metadata inserted by the compiler? What is really needed is more effective ways for applications to sends tips to the kernel about what is going on, what should run at high priority, what should be cached, what should not be, and so over. Forbidding some programs to use some cores because you have many makes little sense as a way to re-architecture an operating system. Because it already happens anyway on current designs (not really forbidden, but when you have few services consuming less than 1 percent of 1 core in the background, and/or running with extremely low priority they will be near to unnoticeable, and truly unnoticeable from the point of view of the user). To get a responsive word processor no matter an anti-virus is loaded or not, a simple solution can work really well now; priorities of scheduling. Given that really background priorities are among the rare things that works fairly well under windows (like 10x better than with a vanilla Linux kernel), if the "architect" is experiencing random slow down of Word because of his "antivirus", its because his "antivirus" is total utter crap, not because a new "architecture" of OS is needed.