Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Bif on June 26, 2010, 01:06:18 AM
-
I've been lurking around on here for a while now and I've now seen many posts where people reference the fact that adding support for more than one CPU to any flavour of Amiga OS seems difficult or impossible for some technical reason, especially lately with the X1000 CPU.
However, I've yet to find a detailed explanation/reference as to why it would be difficult. I'm sure such info has been posted somewhere, but I can't find it with a cursory search of Google and amiga.org. If you can point me to it that would be much appreciated.
I can't seem to shake my mid-life crisis which sees me spending way too much time over the last year reading about the Amiga. I was in love with it 20 years ago but then got busy with a software engineering career that took me away from it. I may now have ample free time to return to programming as a hobby and advancing Amiga OS (I guess it will have to be AROS) is something that seems to be drawing me in. While I have nothing against them, I can't stand the idea of Windows/Linux programming as a hobby as it has been beaten to death and there isn't much I feel i can contribute. I always wanted to program Amiga but never got far into it before getting sidetracked. So I don't know too much about Amiga OS.
Anyway my last 5 years I did almost nothing but multi-core software design and programming across a diverse array of hardware. I've never written a multi-core OS though. But from my user view, I don't get why multi-core is hard. Threads can run on whatever CPU, synchronization primitives built into the OS need to be updated to do the proper things across cores, and the kernel needs to know how to schedule cores? I must be missing something, obviously.
In my searching I did read AmigaOS 4.0 slides where it said multi-threading was added or being added - does that mean that an AmigaOS task can not have multiple threads? I guess I find that surprising if true, but not unbelievable, and I guess that would be a key problem since cores could only be allocated per task instead of per thread. And then I guess if AmigaOS/MorphOS/AROS only share common AmigaOS API up to 3.x it becomes a real challenge to create new OS APIs that they all standardize on?
Anyway sorry for all the clueless hypothesizing, but I really am curious where to get the lowdown. If I had more time I'd break out the AROS source and check but I won't have much time on my hands for a few months yet.
Thanks
-
I'd like to know too.
-
SMT? Simultaneous multithreading?
-
I think you mean SMP though. Synchronous multiprocessing. The big IBM PowerPC chips have multithreading?
-
Synchronous multiprocessing
You mean symmetric multiprocessing?
I think it's now appearant why AmigaOS doesn't have either. :lol:
-
Anyway my last 5 years I did almost nothing but multi-core software design and programming across a diverse array of hardware. I've never written a multi-core OS though. But from my user view, I don't get why multi-core is hard. Threads can run on whatever CPU, synchronization primitives built into the OS need to be updated to do the proper things across cores, and the kernel needs to know how to schedule cores? I must be missing something, obviously.
Thanks
AmigaOS uses a lot of public memory like Execbase. To allow multitasking access to these memory spaces, they are often surrounded by Forbid()/Permit() pairs. This is in system code, libraries and user programs.
Problem is that in a multi-core/multi-CPU occasion also the programs running on the other processor(s) have to be paused when a Forbid() call is made. This will make it very difficult to get any advantage of multiple cores or even may make it run slower due to the overhead.
greets,
Staf.
-
You mean symmetric multiprocessing?
I think it's now appearant why AmigaOS doesn't have either. :lol:
You don't hear the term much anymore, they are just called cores plus threads.
-
@Bif,
First off if it already has not been done, allow me to welcome you to the Amiga.org forums. It is always good to see Amiga users with programming experience/talent return to the Amiga community, as we are woefully short on competent programmers (at least compared to the number of Amiga programmers there once were).
I can't answer the technical side of your questions, but you should be able to find previous forum threads that discuss multiple cores/multiple threading support, if not here at a.org I know I saw such a thread over at MorphZone.org not too long ago, but I do not remember the details of the discussion. It would be great to see someone with lots of experience in multiple core/multiple threading software design take a look at the difficulties in implementing such support within AmigaOS4.x/MorphOS2.x/AROS. Perhaps such an experienced person could come up with some new ideas to overcome the obstacles and figure out a way to take advantage of a second core in some way that would speed up the above mentioned OS'es and/or any newly written programs that run on those OS'es that could use the new ideas. The proposed multiple core support planned for AmigaOS4.x is just on the wish list, or their "Road Map" and there is no target date for when (or if) it will be completed, or even if work on implementing it has been started.
Lastly, even if it proves to be impossible, or impractical to implement support for multiple core CPU's within AmigaOS4.x/MorphOS2.x/AROS, I hope that you will find the time to do some other Amiga programming in the future and that what ever code you do write will be able to be compiled for all three OS'es mentioned above. One easy way to accomplish this is to use Hollywood4.5, or just about any C/C++ compiler to write your programs. Hollywood comes with built-in support to compile for multiple OS'es, including MacOSX and Windows in addition to AmigaOS3.x, AmigaOS4.x and MorphOS2.x (I would have to look at the documentation again to see if it supports AROS and/or Linux). Although Hollywood and Hollywood Designer are not "Low Level" programming languages, I have read that some very good programs have been written using them and that is where I am trying to concentrate my learning to program time. From there I will probably try to learn C/C++ next.
-
AmigaOS uses a lot of public memory like Execbase. To allow multitasking access to these memory spaces, they are often surrounded by Forbid()/Permit() pairs. This is in system code, libraries and user programs.
Problem is that in a multi-core/multi-CPU occasion also the programs running on the other processor(s) have to be paused when a Forbid() call is made. This will make it very difficult to get any advantage of multiple cores or even may make it run slower due to the overhead.
greets,
Staf.
Oops, yes, I did mean to say SMP, duh. SMT presents the same problem though.
Thanks for the insight Fats, that sheds a bit of light on it.
So it seems Forbid()/Permit() is a coarse-grained synchronization mechanism to allow shared access to resources. I'm thinking that shouldn't be a huge obstacle preventing multicore. Indeed while one core has a Forbid() taken out, another thread on another core might have to block/idle, which is not desirable.
However, I think every multicore OS already has this problem and suffers from it. There is not much way around it, access to shared resources requires synchronization. The Win32 API for example may not have equivalent Forbid/Permit, but when you call into the API to allocate memory or access the file system, it is performing it's own synchronization anyway. If two threads are accessing the file system, one will have to wait for the other to exit the critical parts of the API. Probably a key difference here is the granularity, in Win32 the file system may have one or more of its own mutexes, and the memory allocator a different one. So the file system access won't block the memory allocation system, and so on. In other ways the Forbid()/Permit() scheme probably has advantages, because each AmigaOS API call doesn't have to include the synchronization and thus will operate more efficiently. I've designed a number of APIs that work just this way, and execute on multicore just fine. Taking out a lock on each API call can get expensive as locks can get expensive.
The main reason I don't see the AmigaOS calls blocking being a huge issue is because a well written program that is using heaps of CPU probably shouldn't be spending all of it inside AmigaOS calls. You shouldn't have to call into AmigaOS to perform DSP, physics, rendering, or whatever other kind of expensive logic you need to execute that requires all that CPU. Memory allocation may be an issue but it shouldn't be too bad I think, and if you have to, you can create your own private heap to allocate from without the need for synchronization - where I come from you try to simply never reallocate memory so you don't even have to deal with the memory system. I'd think most AmigaOS calls would come down to user interface and IO. I can't see 10 programs all trying to access UI at once and having it stall things out. I think probably only file IO should be a real problem. And every other multicore OS is going to have the same blocking problem here. It's really not much of a problem in practice.
I think for multicore all you can do is try to minimize the time the OS holds locks on shared resources. If programs are written poorly such that they put Forbid() calls around large chunks of code it will prevent good multicore execution. But it would also be forbidding good single core execution as well as other tasks won't be able to get their timeslice if they are blocked out.
Ideally you can create lockless APIs...but realistically that's near impossible, especially for OS functionality I would think.
Anyway I'm just kind of babbling ... still wondering if there is something else big preventing AmigaOS going multi-core.
-
Aren't the amiga line of OS's basically flat mode os's? Everything about the original AmigaOS design was a series of compromises to get the most performance. Flatmode is a fast as hell free for all with no security.
-
@Bif
As Fats (or Staf as we know him on the AROS list), has pointed out, AmigaOS shares resources... Ok, the Forbid() problem is a big one, but now think about HOW the amiga shares resources. It's all pointer passing, you basically have no idea which task/process is using what memory... if you need atomic access to a resouce you NEED to stop all tasks/processes that are currently running on the system...
This is just another case of one simple design decision, to share memory pointers for a bit of extra speed, coming back to bite us 25 years later :(
-
bif, you umay do better searching, this is a much hashed topic.
-
@Bif
As Fats (or Staf as we know him on the AROS list), has pointed out, AmigaOS shares resources... Ok, the Forbid() problem is a big one, but now think about HOW the amiga shares resources. It's all pointer passing, you basically have no idea which task/process is using what memory... if you need atomic access to a resouce you NEED to stop all tasks/processes that are currently running on the system...
This is just another case of one simple design decision, to share memory pointers for a bit of extra speed, coming back to bite us 25 years later :(
Strictly speaking, Forbid()/Permit() are not needed for the majority of AmigaOS thread exclusive access to (non-hardware) resources. For the most part, SignalSemaphores do a decent job of mediating access to items and lists in the system.
-
Strictly speaking, Forbid()/Permit() are not needed for the majority of AmigaOS thread exclusive access to (non-hardware) resources. For the most part, SignalSemaphores do a decent job of mediating access to items and lists in the system.
True, but Forbid() was quicker and easier... Let I also not forget that pointer passing also removed Data locality... Two threads on different CPU's could be sharing the same data... and that data could quite easily be located in two different caches unless marked non-cacheable... but no provision was ever made for that!
-
True, but Forbid() was quicker and easier... Let I also not forget that pointer passing also removed Data locality... Two threads on different CPU's could be sharing the same data... and that data could quite easily be located in two different caches unless marked non-cacheable... but no provision was ever made for that!
This assumes that two CPUs are running entirely independently and that no mechanism for enforcing cache coherency exists. This is a very old problem that has been mitigated by hardware advancements quite some time ago. Are you familiar with the MOESI (http://en.wikipedia.org/wiki/MOESI_protocol) cache coherency model?
Most multicore processors use this or a similar strategy, where the assumption is that pushing data between cores to keep their caches coherent is not a bottleneck, but that talking to memory is.
-
This assumes that two CPUs are running entirely independently and that no mechanism for enforcing cache coherency exists. This is a very old problem that has been mitigated by hardware advancements quite some time ago. Are you familiar with the MOESI (http://en.wikipedia.org/wiki/MOESI_protocol) cache coherency model?
Most multicore processors use this or a similar strategy, where the assumption is that pushing data between cores to keep their caches coherent is not a bottleneck, but that talking to memory is.
I'm not aware of that model (until now, will read in a bit), but I am aware of the x86's power cache coherency hardware... What I'm not sure about is how well that can work in a non memory protected environment. I'm not convinced the AmigaOS data model allows for the hardware to detect what apps in AmigaOS are trying to do... please though, do do do prove me wrong :)
-
The quick and dirty answer?
Way too many programmers (including the C= library ones) have been too quick and dirty.
Forbid()/Permit() is actually documented as a macro in the official includes. Same with Disable()/Enable().
That means you can't insert your fix in the jumptables and expect all uses of the Big Lock to get caught. Possible solutions are to do Enforcer style ExecBase hacks to mmu-track the lock or interrupt register.
From there on in I bet there are many more pitfalls.
-
I'm not aware of that model (until now, will read in a bit), but I am aware of the x86's power cache coherency hardware... What I'm not sure about is how well that can work in a non memory protected environment. I'm not convinced the AmigaOS data model allows for the hardware to detect what apps in AmigaOS are trying to do... please though, do do do prove me wrong :)
Memory protection is a tangential issue. It's nice to have, but not a pre-requisite for SMP itself.
There already is a multiprocessing (as defined by having more than one hardware processor running concurrently) precedent on amigaos. It surprises me how quickly people forget it.
Think about old WOS (and PUP) for a moment. You had two completely different CPU's sharing the same memory in a non-memory protected environment, in which both CPUs had L1 cache and delayed writes (copyback in 68K parlance) enabled. Cache coherency was maintained in software, using the performance killing context switch we all learned to hate.
On WOS, every exec Task that invoked a PPC call ended up with a mirror PPC Task. Most inter CPU calls were synchronous (async also possible, if you care to manage the side effects yourself), so your 68K code calls the PPC and goes to sleep until the PPC returns and vice versa. Caches were flushed on whichever CPU was transferring ownership of the data. Conceptually, in WOS, this 68K/PPC pair of Tasks was considered to be a single "virtual Task". All Task signals were routed to whichever one was running.
Imagine I have a WOS application which has the usual mixture of 68K and PPC code. At this instant, the 68K code is executing and is about to invoke a PPC call.
The call is now invoked and my 68K Task goes to sleep and the PPC one wakes up. Since the 68K task is now asleep, exec is free to schedule another. Which it will happily do. At this point, the code for a totally unrelated application is now running on the 68K concurrently with code from my application which is presently busy on the PPC.
You can almost describe the process of putting the 68K thread to sleep and waking up the complementary PPC one during the context switch as moving the "virtual Task" from one CPU to the other. Whether you are switching from 68K to PPC or the other way around, the newly vacated CPU is free to continue executing other Tasks.
This is clearly not the best example of SMP since it's nothing like symmetric and there are in fact two kernels (pretty much unavoidable given that they execute different object code). However, it does demonstrate that two processors can share data in a non-memory protected environment and run concurrently. The main drawback is the software "brute force" cache coherency model used in which each CPU has to flush anything it's touched during the switch, but no alternative was available. Conceptually, you could replace the PPC with an identical 680x0 and the model still holds. It works, it's just let down by the agonizingly slow method of managing cache coherency.
If you can do that, implementing a method for concurrent execution on a dual core CPU that implements a hardware cache coherency model like MOESI (that has no need to flush caches to memory) has got to somewhat easier.
-
^one point to note about the above example however is that the "switch" from one processor to another is a decision made in the application code itself, rather than being pre-emptively moved. In that respect, you could regard it as "cooperative" multiprocessing :lol:
-
Well, I hardly want to point to the mess of PUP and WOS as examples of multiprocessor systems ;)
But I refer back to Staf, who pointed out that SMP is possible on AmigaOS, the problem is that is might actually hurt performance rather than increase it. Anyway we can argue this as much as we like, I know that Michal (I'm pretty sure it was Michal... he did almost all the other CPU resource stuff) wants to set up SMP support on AROS... so lets see a real example when it comes :)
-
Well, I hardly want to point to the mess of PUP and WOS as examples of multiprocessor systems ;)
They may be a mess but they do demonstrate there's nothing fundamentally impossible about it, which is the point. And to be entirely fair, most of that mess in their implementation comes down to the following points, none of which apply to a modern multi core processor:
1) two totally unrelated CPUs are used
2) cache coherency is implemented in software
3) no direct method exists to update the caches in either CPU with data in the other, so flushing cache to memory and rereading it back in must be used
Imagine none of the above complications were the case and you have two identical cores on the same die, with hardware arbitrated coherency that doesn't depend on cache flushes. Suddenly, the entire thing looks a lot less of a mess, doesn't it?
-
Again, I would never point to the impossibility of SMP in Amiga systems, I only suggest that it serves no purpose. What use is two cores when they will run slower than one?
-
Again, I would never point to the impossibility of SMP in Amiga systems, I only suggest that it serves no purpose. What use is two cores when they will run slower than one?
None, of course. However, that is an assumption that has not been proven.
-
None, of course. However, that is an assumption that has not been proven.
This sounds like a job that could be tested on Minimig/Replay...
Make a 2 68K core version and offload tasks like C2P...
-
There already is a multiprocessing (as defined by having more than one hardware processor running concurrently) precedent on amigaos. It surprises me how quickly people forget it.
Very good point - but actually this is asymmetric multiprocessing rather than SMP. Just like the old 'coprocessor architecture' with Copper and Blitter it shows the possibilities of offloading special tasks or subroutines to other hardware. With the PPC and more advanced 68ks, cache coherency becomes an issue - which can be solved at some cost as you've stated.
A somewhat similar approach could be used to utilize a 2nd core, but it'd be very troublesome to get the kernel itself run multithreaded. Novell Netware 4 SMP used something similar where only special programs could make use of additional CPUs.
Real SMP however makes no assumptions to where the code is actually running - this implies to the OS itself as well. Apart from the Forbid/Permit workarounds, you're looking at a complete redesign of the kernel. Remember the Windows 95/98/ME line? These relatively simple kernel designs stood no chance of running SMP, so MS didn't even bother trying.
-
Very good point - but actually this is asymmetric multiprocessing rather than SMP. Just like the old 'coprocessor architecture' with Copper and Blitter it shows the possibilities of offloading special tasks or subroutines to other hardware. With the PPC and more advanced 68ks, cache coherency becomes an issue - which can be solved at some cost as you've stated.
I acknowledged the example was asymmetric here:
This is clearly not the best example of SMP since it's nothing like symmetric and there are in fact two kernels (pretty much unavoidable given that they execute different object code).
Nevertheless, both processors can be executing code concurrently.
A somewhat similar approach could be used to utilize a 2nd core, but it'd be very troublesome to get the kernel itself run multithreaded. Novell Netware 4 SMP used something similar where only special programs could make use of additional CPUs.
Indeed, this was the sort of thing I was hinting at here:
Conceptually, you could replace the PPC with an identical 680x0 and the model still holds. It works, it's just let down by the agonizingly slow method of managing cache coherency.
...
^one point to note about the above example however is that the "switch" from one processor to another is a decision made in the application code itself, rather than being pre-emptively moved. In that respect, you could regard it as "cooperative" multiprocessing :lol:
It's possible to imagine a card with two 680x0 processors on it and a WOS-like system that allows applications to invoke a library call to get a mirror thread running on the other CPU. These mirror threads don't run concurrently, but as soon as such a switch is made, the current CPU is free to run any ready-to-run task from a different application.
This approach is almost certainly going to be agonizingly slow (and slower than a single CPU) though as you'll be left with a software cache concurrency implementation. However, this really only applies to old 680x0 and PPC where you have physically separate processors. A lot of R&D effort has been put into hardware cache coherency for true multicore processors.
It isn't that hard to imagine the scheme working fairly well (well, at least as well as any such "cooperative" SMP model can, it's never going to be as good as genuine SMP) on a modern multicore processor.
Real SMP however makes no assumptions to where the code is actually running - this implies to the OS itself as well. Apart from the Forbid/Permit workarounds, you're looking at a complete redesign of the kernel. Remember the Windows 95/98/ME line? These relatively simple kernel designs stood no chance of running SMP, so MS didn't even bother trying.
Yeah, I'm not suggesting that exec as it stands is suitable for "real" SMP, as you say, it would need a redesign from the ground up.
-
Yeah, I'm not suggesting that exec as it stands is suitable for "real" SMP, as you say, it would need a redesign from the ground up.
That's my vote. :-) We need something modern that has the spirit of AOS but that would be a massive undertaking requiring a significant size dev team and funding for that clean sheet of paper.
-
Well, the usual way to avoid redesigning the kernel is to use an established one and add the desired API to it.
Smell Amithlon, or OS X here?
-
Yeah, I'm not suggesting that exec as it stands is suitable for "real" SMP, as you say, it would need a redesign from the ground up.
Ergo, we no longer would be using AmigaOS! :)
-
Ergo, we no longer would be using AmigaOS! :)
That boat already sailed with OS4, AROS and MOS ;)
-
Yes but in classic Amiga + PPC card systems you are killing one processor to a allow the other to function. If you have to kill the 680x0 CPU for the 603/604 PPC to execute then how is that multi processor supporting OS?
This is one of the big reasons why PPC didn't sell to us, it was a competition between two kludge's to an OS that badly needed help from Commodore for the PPC era....who had decided to blow their last load on some crappy crippled CD console instead....
-
Yes but in classic Amiga + PPC card systems you are killing one processor to a allow the other to function. If you have to kill the 680x0 CPU for the 603/604 PPC to execute then how is that multi processor supporting OS?
It isn't, no one was saying it is, and you're headed off-topic.
This thread is about new implementations of OS4 on new hardware that can support SMP (which the example you've given, even if both processors were used simultaneously, is not an example of.) OS4 on Classic is just about dead and buried.
-
@Bif
This is just another case of one simple design decision, to share memory pointers for a bit of extra speed, coming back to bite us 25 years later :(
I disagree, I'm a big fan of message passing by pointer passing; it is one of the reasons I stay with AROS and did not delve into something like DragonFlyBSD.
IMHO, the bad design decision was that user programs were allowed to call a system wide lock. It is like the linux BKL (bug kernel lock) but then an order of magnitude more difficult as it is also used by user programs.
greets,
Staf.
-
Yes but in classic Amiga + PPC card systems you are killing one processor to a allow the other to function. If you have to kill the 680x0 CPU for the 603/604 PPC to execute then how is that multi processor supporting OS?
Wrong. You have clearly misunderstood how the system worked. Nothing is "killed off", certainly not the CPU.
Your "virtual task" has just moved from 68K to PPC (or vice versa). In practise, your physical 680x0 task goes to sleep whilst the mirror PPC one is running (and vice versa when it returns).
Each processor is running a pre-emptive multitasking kernel. When either the currently active 68K or PPC task goes to sleep, the corresponding processor is immediately able to continue running a different task when the kernel next runs it's scheduling routine.
-
Lots of interesting stuff here, I am learning a lot just sitting back and watching this for a bit =).
@Bif,
First off if it already has not been done, allow me to welcome you to the Amiga.org forums. It is always good to see Amiga users with programming experience/talent return to the Amiga community, as we are woefully short on competent programmers (at least compared to the number of Amiga programmers there once were).
Lastly, even if it proves to be impossible, or impractical to implement support for multiple core CPU's within AmigaOS4.x/MorphOS2.x/AROS, I hope that you will find the time to do some other Amiga programming in the future and that what ever code you do write will be able to be compiled for all three OS'es mentioned above.
Thanks amigadave =). I am keen on a number of potential Amiga projects so hope to help out at some point. The multicore thing was just the only real mystery gnawing at me. When i used the Amiga back in the early 90s my pet peeve was the lack of memory protection and virtual memory that caused the system or apps to go down in flames (multicore wasn't an issue back then =)). So my number one desire is to see Amiga OS get some modern OS conveniences.
In all honesty I'll probably only be doing AROS work because the others are simply impractical for me, at least at this time. I will be cognizant of maintaining compatibility with everything though and I'm an open source kind of guy so someone else can recompile/patch. As a habit I like to write cross-platform code where possible in case I want what I am working on running on something totally different.
@Bif
As Fats (or Staf as we know him on the AROS list), has pointed out, AmigaOS shares resources... Ok, the Forbid() problem is a big one, but now think about HOW the amiga shares resources. It's all pointer passing, you basically have no idea which task/process is using what memory... if you need atomic access to a resouce you NEED to stop all tasks/processes that are currently running on the system...
This is just another case of one simple design decision, to share memory pointers for a bit of extra speed, coming back to bite us 25 years later :(
That sounds plausible. However, how does this even work on a single core system? Isn't access to these resources synchronized across tasks/threads already? Otherwise how do you know if whatever you have written to various memory locations is not in a half baked state when the other thread consuming it or also writing to it wakes up? Does the kernel have some intelligence when swapping tasks to ensure this somehow? I can't imagine that. I'd think this must be what the Forbid()/Permit() type of thing are exactly for if there is no other synchronization mechanism involved in these shared memory locations? I would think the kernel would not allow a task with a Forbid() in place to be swapped for this reason.
I think that multi-threaded programs need to live under pretty much the same constraints on single core systems vs. multicore systems (except for cache coherency issues). The difference when going multicore is that you hit multi-threading bugs much faster because it's all running at the same time. On single core systems you only run into potential problems during a context switch.
Karlos provided a lot of useful information in regards to memory/cache coherency, indeed I think I share the view that these days multicore is fairly evolved and not as challenging as it once was.
The quick and dirty answer?
Way too many programmers (including the C= library ones) have been too quick and dirty.
Forbid()/Permit() is actually documented as a macro in the official includes. Same with Disable()/Enable().
That means you can't insert your fix in the jumptables and expect all uses of the Big Lock to get caught. Possible solutions are to do Enforcer style ExecBase hacks to mmu-track the lock or interrupt register.
From there on in I bet there are many more pitfalls.
Fair enough, but at this point I think we are looking at next-gen amiga systems, and I don't think an application recompile is too unreasonable if required. Is the AROS Forbid() a macro for example? If it's 68k apps then I don't think we care too much about them, they can all run on one CPU or under emulation if need be or whatever. I guess I can see it being a problem where you let 68k apps call directly into the OS kernel that is running PPC/X86 if you can't trap that.
Again, I would never point to the impossibility of SMP in Amiga systems, I only suggest that it serves no purpose. What use is two cores when they will run slower than one?
This is something I struggled with in my day job for years. I think I have a pretty good idea of what kind of code benefits from multicore and what doesn't. This is an argument that is often thrown up to easily avoid the problem of multicore coding. Indeed some code is bloody impossible to make multicore. In the case of an OS, I see it as a facilitator of letting programs go multicore. The OS itself shouldn't be using up all the CPU, your apps should. A well written app should not be banging the OS like crazy. In this context your app shouldn't even be aware that is running on one particular core of the CPU, unless you multi-thread it to take advantage of multiple cores (a good idea if it can be done). In this case the app is pretty much running on the bare metal and the OS shouldn't be getting in the way much. There is no excuse for slow downs at this point except for general memory bandwidth limits that all CPUs will suffer on all OSs, but are well known.
I think you can probably say one thing is true, a multicore friendly kernel will probably run a bit slower on a single core CPU because of the extra code involved. However, I wouldn't think very much slower. No idea at all really, but maybe less than 1%.
I can only see a multicore kernel slowing things down if it needs to be full of crazy hacks like MMU traps and the like to make some arcane thing work.
Multicore is here to stay and becoming more prevalent every day. For AROS/X86 it's hard to find a single core system, and now with the X1000 there is no excuse not to waste that second core.
Real SMP however makes no assumptions to where the code is actually running - this implies to the OS itself as well. Apart from the Forbid/Permit workarounds, you're looking at a complete redesign of the kernel. Remember the Windows 95/98/ME line? These relatively simple kernel designs stood no chance of running SMP, so MS didn't even bother trying.
That's my vote. :-) We need something modern that has the spirit of AOS but that would be a massive undertaking requiring a significant size dev team and funding for that clean sheet of paper.
I'm not sure if adding multicore calls for a complete redesign of the kernel or not? Honestly I don't know the answer to this, I've never even perused any kernel code. I'm out of my element here. However, in the W95->NT case, I think there was a lot more going on there than just multicore. The NT kernel was built from the ground up with security and stability in mind. I think that probably took more precedence for its selection that just multicore. In my crude estimation, bringing AmigaOS up to the NT standard or stability and security would be a far larger undertaking than adding multicore.
In the end I think Amiga OS probably needs a hugely revamped kernel if we want to get all the modern stuff, and I'm not against that. But I'm thinking multicore alone may not require that.
-
I now read the whole 3 pages and still I'm asking myself why AOS should need multicore-support.
I guess there are lots of more important things to be done. First of all we need software. We need an up-to-date office solution, maybe a java runtime environment. Browsers we need too - thx to OWB and Timberwolf there are good solutions on it's way.
When we have lots of good, new and modern software we can talk about raw cpu power.
But without software which would use it, smp is useless and a waste of time to implement it IMHO.
Sorry for this offtopic answer (as my first answer ever here :-)), but it's just true.
-
But without software which would use it, smp is useless and a waste of time to implement it IMHO.
Sorry for this offtopic answer (as my first answer ever here :-)), but it's just true.
All software can take advantage of SMP, it doesn't have to be written for it. All you have to do is run more than one such software application at once to get the benefit of having additional processor cores.
Beyond that, any application that has multiple threads will also potentially benefit if it ever has two threads that are ready to run. Some apps create lower priority background threads for various maintenance purposes that would normally only get the chance to run when nothing more important was using the CPU. In a true SMP system, they'd not be held back.
Lastly, remember that on AmigaOS, for example, the user interface layout often happens in a different thread than the application itself (not so sure about MUI there).
-
I now read the whole 3 pages and still I'm asking myself why AOS should need multicore-support.
I guess there are lots of more important things to be done. First of all we need software.
If you write software first, then all this software would most likely need to be ported afterwards when you change the OS. Most Amiga software is already written, it's the OS that really lags behind, in just about all areas.
-
All software can take advantage of SMP, it doesn't have to be written for it.
Oh, but it has to be ported to this new AmigaOS that does SMP :)
-
@ bif
I hope this is not off topic.
I understand that the Amiga is an Asymetric type machine.
Is it possible to make a library to run software on another core?
If I was running an MPEG decoder, could it be decoded on another core?
I feel like there would be problems similar to what has to be taken care of in an SMP system.
I guess it would make the other cores a co-processor of a sort.
Wake it up, send a small program, get results and then put it to sleep.
I am very new to this sort of thing, I am not for sure what is possible.
Thanks.
http://en.wikipedia.org/wiki/Asymmetric_multiprocessing
-
I hope this is not off topic.
I understand that the Amiga is an Asymetric type machine.
Is it possible to make a library to run software on another core?
If I was running an MPEG decoder, could it be decoded on another core?
You do that every time you use a ppc datatype in OS3.x or run any application that supports WarpOS/PowerUp.
-
Unfortunatley, I do not think this happens to help programs run any faster or be con-current.
-
Unfortunatley, I do not think this happens to help programs run any faster or be con-current.
Nope, offloading image decoding to a CPU with 9.6x the clockspeed of your 68040 makes nooo difference ;)
You should read further up the thread to understand how WOS works. The 680x0 is not idle when the PPC is called to do a task, it is instead busy running some other application's code. The reason is that the calling 68K task goes to sleep. The moment the presently active task goes to sleep, exec it free to switch it out for a task that is ready to run at the next scheduling interrupt.
There seems to be this idea that either the 680x0 is running, or the PPC is running. This is not the case. Both CPUs are running at the same time and only when they both attempt to access memory at the same moment is one physically blocked by another.
What is true is that a synchronous PPC <-> 68K call puts the calling thread to sleep and waits untill the callee's thread has finished executing the code.
There are also asynchronous calls but due to the complexity of using them, not many applications do.
-
Sorry, I should have related to AROS or AOS4.1 instead.
I think that is why some ppc cards had a video card attached, if I remember correctly.
It sounds like it could talk to the video card, hopefuly, without much interuption.
I do not know much about the ppc/68k accel. cards. It has been a long time since I have read anything about them. If the ppc has its own memory and video out, performance should be much better.
-
Fair enough, but at this point I think we are looking at next-gen amiga systems, and I don't think an application recompile is too unreasonable if required.
Let me rephrase what I said:
The Forbid/Permit semaphore is a publicly readable and writeable kernel structure.
You are free to change the definition of how the OS works, but then you are on your own. AROS (very sensibly (IMNSHO)) decided to take 3.1 with warts and all and implement that first. When they are 100% done you can add New Stuff.
-
To: Amiga_Nut
<3: Karlos
(http://www.gdargaud.net/Humor/Pics/DoingItWrong.jpg)
-
To get things straight; I never wanted to imply that SMP is impossible on amiga-like systems. I just answered the question why I think it is hard.
Lots of interesting stuff here, I am learning a lot just sitting back and watching this for a bit =).
However, how does this even work on a single core system? Isn't access to these resources synchronized across tasks/threads already? Otherwise how do you know if whatever you have written to various memory locations is not in a half baked state when the other thread consuming it or also writing to it wakes up? Does the kernel have some intelligence when swapping tasks to ensure this somehow? I can't imagine that. I'd think this must be what the Forbid()/Permit() type of thing are exactly for if there is no other synchronization mechanism involved in these shared memory locations? I would think the kernel would not allow a task with a Forbid() in place to be swapped for this reason.
Exactly and a program in Forbid() state could rely on the fact that it is the only program in the system that is reading and/or writing to memory. On a SMP system this means that you have to stop all other programs on the other processors/cores.
You could implement this as a start and see what is gives for performance but given that Forbid()/Permit() is used over all the code in the libraries, drivers and user land code I think you will need to invest a lot of time to replace usage of Forbid()/Permit() with semaphores or other synchronization systems to get any benefit of SMP.
But like always I like to be proven wrong.
greets,
Staf.
-
To: Amiga_Nut
<3: Karlos
(http://www.gdargaud.net/Humor/Pics/DoingItWrong.jpg)
^ top right: Product Placement Fail.
-
@Karlos
Haha. Maybe it's a suicide talisman--something she forgot to take with her.
Jumping in with my layman response: I like the sandbox idea. Run legacy and blacklisted software--second class processes--in an unprivileged, protected partition and devise a mechanism to marshal messages between first class and second class processes. Calls to privileged instructions could be caught and emulated within the sandbox. OS4 software should, hopefully, already be well-behaved. If not, it can be fixed and recompiled.
Personally, I don't care whether or not my OS4 box runs classic (680x0 or PPC) software, so long-term, I'd like to see support for legacy software disappear entirely. If you wanted to keep them, though, you could keep the first 32 bits of a 64-bit address space reserved for that stuff and create as many individual or shared sandboxes as the user wants. Think VM86 and DOS under OS/2 and Windows NT.
-
I should point out that I'm in no way advocating a WOS like approach, which given my numerous references to it in this thread, people might think. The only reason I mention it at all is that it serves as a demonstration that general multiprocessing (ie two processors that can run code simultaneously, rather than one processor and a custom chip or FPU etc) already has a precedent of sorts.
True SMP is a different beast all together, of course.
-
If anybody can get to the old usenet comp.sys.amiga discussions of this topic from > 15 years ago, they would be very informative. CBM itself, when in business, was looking into this when there were actually many full time people working on the OS, and Dave Haynie was looking into multi-CPU experimental hardware. He may have actually built a dual-68K board, I can't remember now. The basic problem was, as always, it would break too much existing software; of course, that was when there was commercial software still being written!
The 'original' Los Gatos Amiga crew were very much aware of the problems related to the 1983-1985 design decisions, and tried to apply what they learned in their next design, the 3DO operating system. I don't know if they made it SMP friendly or not, but it suffered the same ultimate fate as Amiga.
-
@hardlink
That would be the CBM Gemini card, with two 68030s... IIRC Dave Haynie said that the software side of it was never completed. You are right that the team knew all too well the consequences of their design decisions... Jay Minor listed a few in his last interview :)
-
Actually Haynie's PIOS-One mobo was a quad PPC CPU.
-
There seems to be this idea that either the 680x0 is running, or the PPC is running. This is not the case. Both CPUs are running at the same time and only when they both attempt to access memory at the same moment is one physically blocked by another.
The PPC isn't running AmigaOS though. The hardware isn't the issue.
If you wanted to run two 68000's, then ExecBase would have to change.
Because of things like this:
struct Task *ThisTask; /* pointer to current task (readable) */
But how to change it? It can't have two values at the same time. You could drop support for it, but then software would break. So it wouldn't be compatible enough.
The other alternative is to have a copy of ExecBase for each CPU. This seems like a good idea, except now you have duplicate information. You'll end up with two graphics.library and scsi.device, which isn't going to end well. You also have to overcome the problem that ExecBase is found by loading from $4, so you'd need an MMU on one of the CPU's at least.
Unfortunately AmigaOS 3.1 can't be changed in any meaningful way to offer multiprocessing for all applications. All you can do is add another scheduler, like powerup or warpos for new applications. It can't have memory protection either.
AmigaOS 4/MorphOS is another matter. I don't know enough about there schedulers, but if it followed the AmigaOS 3.1 design then they will have the same issues.
-
@hardlink
Jay Min*o*r listed a few in his last interview :)
Burn the heretic!
-
The PPC isn't running AmigaOS though. The hardware isn't the issue.
If you wanted to run two 68000's, then ExecBase would have to change.
Not in a WOS style implementation, where tasks are "transferred" cooperatively from one CPU to another, it wouldn't (as I said earlier, this isn't a serious option for many good reasons). In a true SMP implementation, of course it would.
-
Not in a WOS style implementation, where tasks are "transferred" cooperatively from one CPU to another, it wouldn't (as I said earlier, this isn't a serious option for many good reasons). In a true SMP implementation, of course it would.
You could also do it by running legacy applications on one CPU with ExecBase and have new applications that are designed for multiple CPUS run on a new scheduler.
However this violates both requirements.
1. It's not AmigaOS
2. It requires new applications.
Technically it would be little different to running AROS hosted on Linux.
-
You could also do it by running legacy applications on one CPU with ExecBase and have new applications that are designed for multiple CPUS run on a new scheduler.
However this violates both requirements.
1. It's not AmigaOS
2. It requires new applications.
Technically it would be little different to running AROS hosted on Linux.
Whose requirements are those? What is AmigaOS, exactly? The kernel? The API? The coupled hardware? Regarding new applications, isn't that the point?
If the legacy kernel is itself a process under a new kernel--one that did all the magic necessary to support the legacy kernel as a process--then barring hardware incompatibilities, how would old applications know the difference? New applications could use the same APIs we use today, minus the bits we know to be "bad."
-
isnt it still the same on win/mac/ix that apps have to be designed in order to take advantage of multiprocessor/multicore? so why makes it any difference on amiga in thi case.
at least i recall such about lightwave or photoshop earlier..
-
isnt it still the same on win/mac/ix that apps have to be designed in order to take advantage of multiprocessor/multicore? so why makes it any difference on amiga in thi case.
at least i recall such about lightwave or photoshop earlier..
Sort of. A thread running on one of those operating systems may be scheduled on any available processor. The same could be done under Exec; however, Windows, Mac OS, and Linux prevent unassisted user code from modifying kernel structures, suspending scheduling, and disabling interrupts. Many (most) Amiga applications (read: programmers) know too much about the kernel, and rather than using a solid and safe design, they manipulate kernel objects directly.
As most Amiga users would rather run software written in 1990 than software written today, these unsafe programming practices pose a problem for innovation.
-
Whose requirements are those? What is AmigaOS, exactly? The kernel? The API? The coupled hardware? Regarding new applications, isn't that the point?
If the legacy kernel is itself a process under a new kernel--one that did all the magic necessary to support the legacy kernel as a process--then barring hardware incompatibilities, how would old applications know the difference? New applications could use the same APIs we use today, minus the bits we know to be "bad."
The question was "Why is SMT (multicore) support hard for Amiga OS?"
If all you want is a decent operating system and compatibility for amiga applications then winuae with a transparent desktop is probablt better for you. I'm sure someone has done this, not sure if it was official/finished though but basically it would look like the amiga windows are on your host operating system desktop. Also tcpip & filesystems can be hooked through to the native OS as well.
If you create a new OS that isn't compatible with anything else then you're going to struggle to get support.
Your only real hope would be to add support for multiple processors to AROS. As it's open source and most software for it is also open source then you can probably afford to break compatibilty.
It's still not trivial, because you have to get both cpu's running & make the changes to exec to support it.
isnt it still the same on win/mac/ix that apps have to be designed in order to take advantage of multiprocessor/multicore? so why makes it any difference on amiga in thi case.
at least i recall such about lightwave or photoshop earlier..
For one application to take advantage all you should need is to have multiple tasks (aka threads). Which is already possible on all versions of AmigaOS. Tasks are generally used if you need the UI to remain responsive while a process is carried out that may involve disk/network/other libraries that may not return immediately.
However two applications (each with a single task) on a multi cpu machine will also be able to take advantage.
-
As most Amiga users would rather run software written in 1990 than software written today, these unsafe programming practices pose a problem for innovation.
What, people are up to 1990 software, you mean some new stuff came out? Were MusicCraft and WordPerfect updated and I missed it? Has Workbench 1.4 been released yet? What about GOMF 3.1?
-
Learning more here and doing some other research, it becomes clearer to me why SMP is hard. I think I probably underestimate the complexity of developing a multi-core kernel itself. I probably spend too much time on the other side of the kernel to think about all the ramifications of handling PCI bus stuff, etc., and I guess some variants of AmigaOS are based on microkernels that might not make it easy to provide SMP, etc (or maybe make it easier, I dunno).
Let me rephrase what I said:
The Forbid/Permit semaphore is a publicly readable and writeable kernel structure.
You are free to change the definition of how the OS works, but then you are on your own. AROS (very sensibly (IMNSHO)) decided to take 3.1 with warts and all and implement that first. When they are 100% done you can add New Stuff.
I wasn't suggesting changing how it works. I think I understood what you said, and I think it is fine if Forbid()/Permit() serializes execution of any apps waiting on a Forbid(). Even with all this contention I think multi-core would be effective where needed, because apps that suck up lots of CPU wouldn't be doing it all within Forbid() sections as that would be completely terrible programming practice. And if they do that, too bad for those apps. From Amiga Classic perspective there wasn't really enough CPU available to do heavy number crunching, so I can see how apps back then could monopolize a lot of the CPU just dealing with the OS for GUI/file IO, etc. I don't think that applies as much going forward.
Also understood about AROS wanting get the basics covered first. I wasn't even suggesting adding multicore to AROS right away, just trying to say it would have to be the sandbox for the experiment if someone like myself wanted to play with it as it's the only one with code to play with.
@Karlos
Personally, I don't care whether or not my OS4 box runs classic (680x0 or PPC) software, so long-term, I'd like to see support for legacy software disappear entirely. If you wanted to keep them, though, you could keep the first 32 bits of a 64-bit address space reserved for that stuff and create as many individual or shared sandboxes as the user wants. Think VM86 and DOS under OS/2 and Windows NT.
Whose requirements are those? What is AmigaOS, exactly? The kernel? The API? The coupled hardware? Regarding new applications, isn't that the point?
If the legacy kernel is itself a process under a new kernel--one that did all the magic necessary to support the legacy kernel as a process--then barring hardware incompatibilities, how would old applications know the difference? New applications could use the same APIs we use today, minus the bits we know to be "bad."
I think the Amiga without the legacy apps wouldn't be too interesting to me. My vision of an Amiga box going forward is something that can be all things Amiga, including historical, with as much modernization of things as possible as well. I don't really care how it does this, running on some unix variant kernel, through emulation, WINE-style, etc., though the better/faster/more compatible it runs the better it is IMO. I think in the end the OS X model is probably where it needs to go. Obviously that might be difficult to get the resources for, no idea how hard that is.
The 'original' Los Gatos Amiga crew were very much aware of the problems related to the 1983-1985 design decisions, and tried to apply what they learned in their next design, the 3DO operating system. I don't know if they made it SMP friendly or not, but it suffered the same ultimate fate as Amiga.
Heh, I am probably one of the rare few who actually developed for the 3DO M2. It's funny because at the time I had no clue there was any kind of Amiga connection. I didn't learn about the people behind Amiga until the last year when I got back into it since that info was scarce in the pre-internet world that my Amiga days existed in before. I've since learned that I previously crossed paths with a few people and techs related to Amiga. Would have been nice to know at the time as I would have got a kick out of it and maybe brought it up.
The M2 seemed quite elegant to program for. It was quite polished for where it was in development. I think because of this I don't remember much about the system. I had to go to wikipedia and look up that it was indeed a dual core power PC box, so it suported SMP! That probably would have messed up programmers pretty good at that time - maybe not a great design decision. The audio DSP did also make the system AMP =). I remember you had to cobble together a bunch of fortran authored objects to create a plugin/signal path. It seemed pretty advanced at the time, hard to believe it even worked, but it did! So there you go, the M2 had both SMP and AMP, which makes it somewhat topical to this thread. =) No idea about the original 3DO.
-
I think in the end the OS X model is probably where it needs to go.
Can you be more specific? Apple dropped support for the classic environment after 10.5, and it was never supported on Intel Macs. I expect Apple will drop Rosetta once all major developers have made the switch to Intel. (Are there any major PowerPC developers left?)
-
The OS X model makes sense. Building a new Workbench on a Linux kernel makes sense. That is precisely why it will be opposed tooth and nail and eventually abandoned. Anyone who had any sense left the community years ago. The voices that seriously think that there are millions that want a '90s OS on very expensive low end dead end hardware are in control...
-
AmigaOS is still a non-mainstream computer operating system. I wouldn't particularly say it's a hobby OS because it's an obscure term IMO.
I don't think there is a need for the multicore support. I'm going to order a new Amiga computer in Asia in the near future and I don't want any price hike on the hardware just because of the multicore support with a more expensive multicore CPU. :(