As add Multicore support for the AmigaOS at kernel level has a lot of problems.Could be a solution add extra core support as OPENCL library? feasible?, has the same problems? your thoughts

Last edited by Fransexy on 09-Sep-2009 at 11:28 AM.

_________________
No PowerPC, No Fun
Make Amiga Great Again

@Fransexy

I would do multi core support like this:

- Everything defaults to run on core #1 only.

- Tasks can enter and leave a special multi core safe state by calling some new Exec functions ~MultiCoreRocks(), ~MultiCoreSucks().

- While in multi core safe state the task scheduler is allowed to run the task on other cores.

- Apps/libs would manually switch into and out of that state when doing cpu intensive things like large mem copies/ops and things like that.

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)

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

@Georg

Quote:

- Tasks can enter and leave a special multi core safe state by calling some new Exec functions ~MultiCoreRocks(), ~MultiCoreSucks(). - Apps/libs would manually switch into and out of that state when doing cpu intensive things like large mem copies/ops and things like that.

App developers would not know if 3rd party libraries are multicore safe. They would have to disable/enable multicore support constantly and in the end developers just give up and leave it on.

If multicore support is not transparent to apps it is useless and works like VM on Amiga. Works nice when it is not being used but bombs randomly when it is being used.

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

@Thread

Please forgive some stupid questions from a non-programmer.

1. How did/does AmigaOs support multiple proccesors?

2. how is this different from supporting multiple cores?


See, I said they were probably stupid. (me ducks)

_________________
Peter Swallow.
A1XEG3-800 [IBM 750FX PowerPC], running OS4.1FE, using ac97 onboard sound.

"There are 10 types of people in the world: those who understand binary, and those who don't."

@Swoop

AmigaOS doesn't really support multiple processors at all, and it never has. If you add an accelerator to an Amiga (e.g. a 1230 board in an A1200), the original processor is disabled and the second processor takes over. For PPC boards there's a special system which applications have to be aware of to use - the OS itself doesn't really have anything to do with it and runs solely on the (single) 68k processor. This also applies to all software that wasn't specially written to use the PPC chip...

Basically, think of the PPC in classics as a coprocessor like an FPU, rather than a second processor available for general use.

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

@itix

I think of it as something which you enable on "demand", not something which you (need to) disable around stuff which is not safe. So it's to be used a bit like a semaphore, but in an inverted kind of way. You use it to enclose stuff which is safe. You wouldn't use it around. things which calls other libs.

Similiar to doing things like altivec/sse/whatever-optimizing speed critical code in encoders, converters, etc. only much much easier. If you have for example a cpu intensive routine and split the work to two tasks it's only a matter of adding 2 lines or so of code and you would have doubled the speed on a dual core.

@Georg

Quote:

You use it to enclose stuff which is safe.

And only where you want. Where you think it makes sense. In the same way as one would do atlivec/sse/whatever optimizations to a game or a lib like SDL only in those places where it makes sense not each and every place where it is possible.

@Daedalus

Quote:

AmigaOS doesn't really support multiple processors at all, and it never has.

What about Agnus, Paula etc, they were co-processors?

_________________
Peter Swallow.
A1XEG3-800 [IBM 750FX PowerPC], running OS4.1FE, using ac97 onboard sound.

"There are 10 types of people in the world: those who understand binary, and those who don't."

@Georg

But would it make enough difference presuming "MultiCoreSucks()" is relatively expensive call?

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

Amiga hardware is already multicore, in the sense that you can program the custom chips to perform asynchronous tasks. Without system support for CAS, TAS, and the like, it would be difficult to support multiple CPUs natively. An accelerator with local memory that virtualizes access to multiple CPUs while maintaining external timings might work, but the hardware would be cost prohibitive. You'd still have to obey hardware-access rules as well, so the accelerator would have to know how to serialize those tasks.

The Arexx comment seals it, though. With a cluster-aware task (threading) API, you could run tasks on an arbitrary number of Amigas, including MorphOS, AmigaOS 4, WinUAE, et al. (EDIT: If you're just passing data around, the target architecture doesn't really matter, and you could cluster portable processes on your architecture of choice.) You'd be limited by your external bus/interconnects, though.

Last edited by Trev on 09-Sep-2009 at 06:09 PM.
Last edited by Trev on 09-Sep-2009 at 06:07 PM.

_________________
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

@Daedalus

True, unless you run OS 4 on PPC expansion board, when 68k CPU is disabled

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

Multiple Core Support for what?

Better try faster clocks then try to change the OS totally and wait again years until multi cores are not longer `state od the art'.

_________________
I´m back in 2023 on Classic Amiga with my A1200/Blizzard1230IB@50Mhz, 32MB RAM, AmigaOS3.2 and ROMs, Indivision AGA MK3, Author of Amiga-Flipclock (OS4)

@fingus

Quote:

fingus wrote: Multiple Core Support for what? Better try faster clocks then try to change the OS totally and wait again years until multi cores are not longer `state od the art'.

_________________
No PowerPC, No Fun
Make Amiga Great Again

@Swoop

1.How did/does AmigaOs support multiple proccesors?

AmigaOS never did not support multiple CPU cores.
Phase5 solved this by running two operating system on same machine.
PowerUP was running the PowerPC native programs, and AmigaOS was running the 680x0 programs, when ever a PowerPC native program needed to run a 680x0 routine it flushed all CPU caches and stop until 680x0 CPU was done, then the 680x0 caches was flushed, and PowerPC was enabled again, continuing where it left off.

2.how is this different from supporting multiple cores?

AmigaOS was never able to load balance programs on the two processors, AmigaOS was unable to run 680x0 software on the PowerPC, and PowerPC programs where unable to run on 680x0 CPU, there where hardly any thing written for PowerPC and when program was unable to do thing whit out calling 680x0 routines.

Last edited by NutsAboutAmiga on 09-Sep-2009 at 08:33 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@fingus

Quote:

Better try faster clocks then try to change the OS totally and wait again years until multi cores are not longer `state od the art'.

Processors went multi-core because the manufacturers hit physical limitations. Those limitations are not going to go away. Don't expect to ever go back to single core computers.

The question in the future is how many cores / threads will there be and how they'll be connected.

Last edited by minator on 09-Sep-2009 at 09:12 PM.

_________________
Whyzzat?

You could do multi-core with clustering. It'd involve each core having it's own copy of the OS and memory dedicated to it. Communications between the cores however would be complex and you'd need a clearly defined communication method between OSs / cores.

It's certainly possible - this is how most supercomputers work.

_________________
Whyzzat?

@Georg @ Fransexy
Your, uh, "plans" don't explain how to work-around the problem that all AmigaOS info/objects are accessible to every task, even if they happen to be on different cores. Unless you can solve that, you haven't solved anything...

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

@fingus

A bit like now 'faster clocks' are no longer state of the art? There's a reason that the world had went multi core, and that is due to physic constrains.... reality sucks

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@ChrisH

That's a problem common to every multitasking operating system, albeit limited to specific domains in systems with memory protection. It's already a problem in Exec, which can preempt any task at any time, allowing race conditions, deadlocks, and all the other usual hazards.

In a "normal" multiprocessor system, implicit locks are taken along cache line boundaries, preventing simultaneous access to shared memory. The hardware itself doesn't know or care about synchronization issues peculiar to the threads currently executing. (I'm ignoring CPU pipeline issues, which while relevant to compilers, are normally transparent to application programmers.)

EDIT: I'll add that solving these problems in a generic way is a very active area of current research in computer science, and if the problems were solved on an Amiga-like platform first, good for us.

Last edited by Trev on 10-Sep-2009 at 02:05 AM.

_________________
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