@Fransexy

I believe that multicore-support might be quite handy. It gives better multitasking but in hardware-form, allowing several high CPU-tasks to work in parallel with each other.

Why shouldn't Amiga be able to do the same, and when having that support, the Amiga might as well handle such multitasking far better than anything else out there? Why? Because the Amiga was bornt with Pre-emptive multitasking, and was in fact the FIRST to introduce it to the computer industry, and it was several years ahead of any PC and Mac on that area!

_________________
Probably Pegasos 2 G4 1Ghz 1GB DDR-system, ATI Radeon 9250, ESI@Juli PCi-soundcard, all running
AmigaOS 4.1 with latest updates, or a new powerful
Amiga! Fingers crossed!

@vox

True

@swoop

Yeah, the co-processors did work asynchronously and in parallel with the 68k, but they were just that: co-processors. They couldn't run any 68k code, and therefore couldn't share that load. In that sense, software had to be coded specifically to use them, just like the PPC under OS3.x. Applications running on the 68k chip only had one possible place to run: the 68k chip.

The idea of multi-core and multi-CPU is that all the cores are essentially the same - they execute the same code, and therefore share the load by running different tasks on different cores. For example, launching OWB while core #1 is busy means it might end up running on core #2, thus the tasks running on core #1 aren't slowed down. This should be transparent to the application; it shouldn't care what core it's running on, or even if it's split across cores.

It's extra complicated on the Amiga because a library can be accessed by several tasks at the same time while existing in only one place in memory. So, an appliation on core #1 and an application on core #2 might both try to run a routine in a library which is opened and running on core #2. You can't always guarantee that an application and its sub-tasks (libraries, devices etc.) are running on the same core, which means a totally new system needs to be created for dealing with this... And that's effectively a new OS

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

@Georg @Fransexy
On further thought, I realised that I misunderstood your suggestion - my mistake for reading it too quickly, sorry.

@Georg
The basic idea of using extra cores as simple "co-processors" is actually quite a neat idea. One can imagine that you have a restricted set of OS function calls available to tasks that are not running on the 1st core. Initially these functions would just cover the basic communication needed to use other cores as simple "co-processors", but they could gradually be expanded over time to cover other OS functions, until (after some years) you have completely duplicated most AmigaOS functionality, but in a way that supports multi-core (i.e. avoiding giving direct access to OS objects).

At that point the original AmigaOS functions would be depreciated, and coders would be encouraged to use the newer function calls. Probably it would be best for the multi-core functions to be implemented as a separate OS4 Interface for each library.

What do people think?

Last edited by ChrisH on 10-Sep-2009 at 09:11 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@Daedalus
Quote:

It's extra complicated on the Amiga because a library can be accessed by several tasks at the same time while existing in only one place in memory. So, an appliation on core #1 and an application on core #2 might both try to run a routine in a library which is opened and running on core #2. You can't always guarantee that an application and its sub-tasks (libraries, devices etc.) are running on the same core, which means a totally new system needs to be created for dealing with this

Something's wrong here... A library is not a task (at least not in pre-OS4. Have they changed that in OS4?) so it can not run "on a core". A device is indeed a task, but there is no principle problem to run it on a different core since the application tasks are communicating with the device task via messages.

I have never seen the source code of AmigaOS, but I assume that the problem with multiple cores simply is: when the programmers wrote the OS, they assumed at certain places that "if code execution is here at time t, nobody else can be here at the SAME time". This would need to be fixed for a multi-core capable OS. In addition to that principle problem, there are other problems, such as how to distribute the tasks on the cores, but those are problems every OS has

@all

As once was described to Linus Torvalds on some finnish discussion forum: AmigaOS is flexible like rubber, everything is possible.

Amiga used multiple CPU cores in a special way in the past.
Even 68k apps could take advantage of PPC co-processor by using system libraries(etc) that were PPC native (if PPC was installed in the system).

Did AOS3.5/3.9 have WarpUP as default? IIRC it did. So, AmigaOS has officially supported multiple CPU cores in AMP way.

IMO: AMP is a good way to go. Not sure if SMP is any better in the long run. They have different problems/challenges to overcome.

For example SMP is difficult to use in real time systems. It's hard to guarrantee exact behaviour when processes jump between CPU's. And also part of the performance is lost in those jumps.

...

Perhaps AMP would be the better way to start with. The community have already some competence of it. AOS/MOS/AROS is so lightweight that it self does not need multiple cores to be insanely fast and it simplifies things.
step1: everything on one core
step2: libraries on the second core
step3: clusterUP library (or something like that) to enable the use of more cores (perhaps even in heterogenous way)


It's a stupid wintelnux world idea that everything in computing needs to be "GAY". Amiga has been able to do things ALSO in a "hetero" way, already since day 1.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK Quote:

Amiga used multiple CPU cores in a special way in the past. Even 68k apps could take advantage of PPC co-processor by using system libraries(etc) that were PPC native (if PPC was installed in the system). Did AOS3.5/3.9 have WarpUP as default? IIRC it did. So, AmigaOS has officially supported multiple CPU cores in AMP way.

Sorry, but you are wrong. WarpUp & PowerUp "supported" 68k + PPC by disabling one of the processors while the other was running (and using an expensive cache flush when switching processors). That was a severe hack that allow a slow 68k OS limited usage of a far more powerful (PPC) processor. It is NOT a general purpose solution, and is most certainly useless for multi-core (as only one core could be active at any time!).

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@Daedalus

I am not any kind of expert, but from users pointy of view:

a) "Cell approach" : give each core/unit only one kind of tasks, like mentioned that 68k CPU used to run OS calls and PPC was "muscles", one core could go to OS calls, another one to applications.

b) CPU load approach: I remember it from first dual CPU (not dual core) approach was that single CPU is used, and once it becomes heavily loaded, other CPU takes the application calls. This was something like +30% Speed Up

c) Current PC approach: Make applications that does not make a single CPU load, but a lot of "threads" that can be divided amongst core, so no core gets overloaded
and overall system gets more stable.

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

@RodTerl

Quote:

RodTerl wrote: Um, given theres Arexx Deamon on aminet, where the arexx stream can be sent from machine to machine,e ven over TCPIP etc, would it be possible, given Amigas really weird and obscure method of actually using a microkernal, ExecSG, of physically placing an independant instance of the kernal on each extant core, then using Amigas existing multiprocessing, multiprocessor intercommunication methods to allow simultaneous reads to library files etc, given 040 and 060 have copyback and bus snoop functions for checking to see if something else has alterd the memory they were looking at? Insted of one instance trying to run on multiple cores, why not just have multiple machines on a single chip?.. Is Screamernet part of Open Toaster for Amiga? Can its code be looked at and used for parralisation products, simplest being maybe one thread per core, look at webpages, lots of threads, or even per macroblock or group decoding etc? Ok, so audio might be a problem with not being able to apply multiple simultneous effects on different cores, but at least they can handle multiple notes, channels simultaneously? Just trying. 8)

Interesting approach but this would require each core to have its own private mem. Or you need a API for the MMU and have MP - but this seems not feasible w/o breaking backwards compability.
IIRC qnx does it in a very efficient way. Maybe there is some inspiration to borrow from them...

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

One way would be to make some more expensive / often running system functionality run on another core. Things like audio mixing, blitting graphics, perhaps also part of OpenGL library (as it often doesn't require things to happen immediately on function call).

Of course even that would be far from easy.

Something on the level of "getting special dnetc client running on another core" should be trivial (and of course, totally useless)

@ChrisH

Quote:

WarpUp & PowerUp "supported" 68k + PPC by disabling one of the processors while the other was running (and using an expensive cache flush when switching processors).

Don't know what you mean by "disabling", but there were a number of applications which used the 68k to handle IO, C2P conversion etc concurrently with the PPC. That is, at the same time as the PPC was rendering the next frame(s) worth of audio and video. Communication (as in passing data) was done through non-cachable memory (like CHIP RAM) which meant no cache flushes were required...

I think the main issue is a single memory bus shared by two different CPUs running at different speeds taking different amount of time to fetch the data. The 68k would therefor slow down the PPC quite a bit, but the relativly large caches of the PPC helped a bit...

I may be wrong, but I think the boards with a 060 would allow the PPC to run somewhat faster as the 060 could access memory faster than the 040, thus blocking the bus for shorter periods of time...

@ChrisH

"PPC by disabling one of the processors while the other was running"

Oh?
I thought only either one could access system RAM at a time, during that time the other could process it's data in caches. And IIRC, cache coherency etc. made the thing very complex.

I can not understand how powerUP Amigas were that fast and ran that smooth if in real life CPUs ran one at a time....?

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@ChrisH

Quote:

WarpUp & PowerUp "supported" 68k + PPC by disabling one of the processors while the other was running

Both 68k and PPC can run simultaneously.

Quote:

(and using an expensive cache flush when switching processors).

No need to if you communicated via non-cacheable memory. PowerUp allowed that but I recall WarpUp didnt (but could be I remember wrong).

Quote:

It is NOT a general purpose solution

It indeed was not. Half of PPC ports at Aminet (at least for WUP) are broken or run slower than the 68k port. Only very few developers were capable of creating useful PPC applications.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

No need to if you communicated via non-cacheable memory. PowerUp allowed that but I recall WarpUp didnt (but could be I remember wrong).

Works fine with WarpUP as well. You could either allocate memory as non-cachable or simply use CHIP RAM as that's always non-cachable. Did that myself for the Paula audio playback routine in AMP for example...

@ara

Yes, I may have simplified it a little there - a library is not a task, but it is loaded into memory and run from wherever it is by the processor when required. I can imagine all sorts of issues arising from this system with multiple cores as, like you say, more than one CPU could potentially want the same routine at the same time, where up to now that has been impossible. You might get away with it in some libraries, but others would need a fundamental redesign to work like that.

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

@AmiDog

I was wondering because some this functionality is not supported in Frank Wille's PowerUp wrapper for WarpUp. Memory allocation functions in WarpUp dont seem to support it. And I would not use chip ram either because it is very slow and limited resource...

EDIT: I just checked WarpUp docs and it seems you can pass special MEMF_#? flags to memory alloc calls to alloc non-cached fast ram.

Last edited by itix on 10-Sep-2009 at 04:59 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix Quote:

Both 68k and PPC can run simultaneously.

Are you sure about that? I thought that when 68k made a PPC call, the 68k flushed caches & then suspended it, while the PPC did it's job, and then when the PPC finished, it flushed it's cache, and allowed the 68k to continue. And vice versa when PPC made a 68k call.

Maybe it is possible that the 68k continued to run certain limited OS stuff, when the PPC was active?

@Kimmok Quote:

And IIRC, cache coherency etc. made the thing very complex.

There wasn't any cache coherancy AFAIK. i.e. They just used expensive cache flushes.

@AmiDog Quote:

Don't know what you mean by "disabling", but there were a number of applications which used the 68k to handle IO, C2P conversion etc concurrently with the PPC.

You seem to know about the implementational details (I don't!), so I will have to assume you are right!

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

You can call PPC code asynchronously or synchronously. If you make synchronous PPC calls your own 68k task is suspended but other 68k tasks would continue running.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix
Ah, OK, that make sense.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@HKvalhe

Quote:

Why shouldn't Amiga be able to do the same, and when having that support, the Amiga might as well handle such multitasking far better than anything else out there?

Because AmigaOS uses shared systems structures that are not protected against other CPU accesses. SMP is impossible with AmigaOS. ASMP (using other CPU cores as coprozessor) might be possible but not for genreral AmigaOS Tasks.

Quote:

Because the Amiga was bornt with Pre-emptive multitasking, and was in fact the FIRST to introduce it to the computer industry

I hope this was meant as irony.

Last edited by Arko on 10-Sep-2009 at 07:46 PM.

_________________
AmigaONE. Haha. Just because you can put label on it does not make it Amiga.

I borrowed this comments from here (#27 & #28):
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=38873&forum=2&start=20&order=0

@HKvalhe

Or a poor history lesson? Are we forgetting OS/360, Unix, and research taking place in the 1960's? The Amiga was definitely not the first system to use preemptive multitasking.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603