@Jupp3

"the future is now" so to say

i am already using it on AROS 68k and the official "AROS version" (X86) is nearing completion. So for me "Wanderer" and its limitations is already past

newest screenshot (X86):
http://aros-exec.org/modules/newbb/viewtopic.php?start=40&topic_id=8377&viewmode=flat&order=ASC&type=&mode=0

Last edited by OlafS25 on 26-Aug-2013 at 02:21 PM.

@pavlor

i think its more about applications, os itself is not nor should be heavy duty, and even less dependant on smp actually.

@pavlor

Quote:

Back to topic. What OS components can benefit from SMP? Eg. I assume Gallium3D can use more cores?

I don't think Gallium3D (or any hw accelerated OpenGL implementation) itself would benefit much from multicore support... BUT!

Consider following pseudo code.

glDrawElements();
DoHeavyCalculations();
glDrawElements();
DoMoreHeavyCalculations();
glDrawElements();
DoEvenMoreHeavyCalculations();
MySwapBuffers();

Basically, with OpenGL, there's absolutely NO guarantee, when drawing operations will actually be done. Order is whatever user specified, and all will be done before f.ex. buffer swap (last call)

So with 2 cores, one core could be handling OpenGL drawing at its own pace (of course GPU does all the heavy lifting), while 2nd core runs the user program. It doesn't matter WHEN the drawing is actually done, as long as it's done before buffer swap (when it will be made visible for the user)

(technical note: Of course this is assuming user uses VBO, so that OpenGL implementation actually knows, when source data might be changing)

So this was for a program that's not optimized for multithreading at all. An optimized program could use several threads to run heavy calculations in parallel. But the point is, even unoptimized programs CAN benefit from multicore support. If you run 2 such programs at once, each might get their own core (and libraries they use, might also use different cores)

NOTE: Of course you can have several threads on single core systems aswell, they just won't run at once. Often it's desireable also for other reasons, such as making sure GUI updates even during heavy operations (that are done in a separate thread).

Of course in practice, there's absolutely no guarantee how many cores will be available & what they will end up doing. If you f.ex. had video encoding going in the background, that would likely use one core and leave another for the rest.

@wawa

Quote:

wawa wrote: @megol Quote: That's not possible. What naysayers claimed (at least those with a bit of clue) was that AmigaOS can be extended to SMP while staying compatible. That's true and this experiment can't change that. What this could prove is that pseduo-SMP is possible, pseduo as halting all processor except one in Forbid/Disable states means that it can't be proper SMP. the shape this experiment is going to take is what this experiment is all about. what you are writing about is just its current state.

No. I am writing about the fact that proper SMP can't be implemented for AmigaOS without sacrificing compatibility. This is a fact, not an opinion. This experiment can't change this fact.

Making an OS that looks like AmigaOS but is multiprocessor capable would be easy, heck ignoring existing drivers just a few changes in Exec is needed. But it wouldn't be compatible.

Quote:

Quote: I hope that the experiment works - if it does it would be possible to have high performance FPGA 68k multiprocessors. For doing it on x86 I personally don't see the point - a single core JiT emulator is plenty fast. one eye blind obviously. if it helps 68k (appropriate multicore hardware doenst even exists) why shouldnt this help on x86? except one only considers 68k as viable platform.

Why not? Simple: in a FPGA we can have dedicated hardware that makes a simple Forbid()/protected manipulation/Permit() take perhaps 10 clocks. That design would freeze all other processor cores or at least stall everything looking like interference with the protected processor. No extra cache trashing and/or costly mode changes.

For x86 it will take a lot longer to do the equivalent.

@thread

Why not just add a control mechanism : all current messages on default core1.
core2 activated on request with parallel messaging stream that identifies it as core2 only.

memory pointers can be manipulated with an extension to identify a new map per core.

We also need AMP for always /mostly on services eg Internet IP/JS/Java accelerated stream on a core.

Downloading at 10+MBs needs fast hardware and resources, maybe a full core. combine downloading in background with playing HD movie another core may be needed.

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@asymetrix

Quote:

We also need AMP for always /mostly on services eg Internet IP/JS/Java accelerated stream on a core.

AMP is like kissing your own sister. SMP is the only way to fly, just ask the other OSs.

_________________
Dammy

@damocles

+1000

_________________
Amiga 1200 desktop. Apollo 030/50 Mhz 8mb ram + ClassicWB + Wb 3.1
Amiga 500 + ACA500plus 8mb + 30gb CF
Raspberry Pi 3b+ and Amibian 1.4
Mac Mini G4 1GB Ram with the butterfly!!

AMP vs SMP vs BMP

I would prefer flexible multiprocessing. So that I can bind tasks to some exact core or just let them fool around.

But any possible way to use more than one core is nicer than to just use only one core.

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

@KimmoK

i think multiple core handling is up to the system and should be solved transparently for applications, worst case they cant get any advantage of it because single threaded. the only example for user to get involved with the subjects runtime i remember is threaded switch in rendering applications.

@wawa

Quote:

think multiple core handling is up to the system and should be solved transparently for applications, worst case they cant get any advantage of it because single threaded. the only example for user to get involved with the subjects runtime i remember is threaded switch in rendering applications.

Not having SMP will limit what "got to have" code that can be ported and or created. Single threaded app/games are so yesteryear for desktops and soon will be as well for portables.

The public will never accept any OS that isn't SMP on modern hardware.

_________________
Dammy

@damocles

Quote:

The public will never accept any OS that isn't SMP on modern hardware.

I doubt the public will never accept any Amiga operating system, anyway =P

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

@itix

People are not interested in what they use as long as it does what they expect

@damocles

Quote:

Not having SMP will limit what "got to have" code that can be ported and or created. Single threaded app/games are so yesteryear for desktops and soon will be as well for portables. The public will never accept any OS that isn't SMP on modern hardware.

multi threaded apps will usually run on a single cpu system, just not in parallel, right? which is a good enough reason to support smp, thats right, while not a reason to search for funny alternative solutions, that will work with some not (yet) existent applications exclusively. thats my whole point, got it? (im actually supporting you here)

Last edited by wawa on 21-Sep-2013 at 12:45 AM.

@wawa

I think we are in agreement and having communication issues. :) Yes, multi threaded code should run on a single CPU, it's just questionable that the end user experience will be a happy one.

_________________
Dammy

We run AmigaOS so we can use old amiga games and programs. Also the OS itself is a reason why we like Amiga or Amiga like OS. There is very little new programs to talk about. The reason is simple. AmigaOS is very outdated and miss so much that it will never be interesting in the real world. AROS is open source and anyone is free to fork it and start some kind of mothern OS based on AmigaOS. Will someone every do that ? Not very likely. The reasons would be many. First and foremost who would make any good software for that new platform. What would make that OS so special compared to other open source alternatives.

Don't take Amiga future to serious. Enjoy what it is and if that is not enough, move to something else. That is at least my opinion about that matter.

@nikosidis

I do not fully agree to that. If a developer supports a platform does not depend (mainly) on features like SMP but on the userbase he can support (and thus potential sales) and it depends how much time (and thus money) he must invest in it to support any of our platforms. But if he can use cross-platform tools like Amiga Monkey, Hollywood or Antiryad Gx and only needs to recompile it then the chance is much higher. That is not only true for games but also for applications. The chance of f.e. "Amiga only" games is low because of the limited number of users. The solution of this are cross-platform tools that make porting easy (and cheap).

And BTW there is a lot of activity. I have the 64bit SMP AROS version on my computer for testing purposes that is even supporting 128 GB RAM. Is it "full compatible"? Propably not but there is at least a chance to get something modern. ARM branch is moving now too. Will a modernized AROS mean suddenly lots of software from one day to another? Of course not but it can help to motivate developers again. The example was the developer of Antiryad Gx who got interested after I contacted him. Other developers were interested because of ARM (Raspberry). So I do not share your pessimism.

Last edited by OlafS25 on 21-Sep-2013 at 10:37 AM.

@damocles

Quote:

@wawa I think we are in agreement and having communication issues. :) Yes, multi threaded code should run on a single CPU, it's just questionable that the end user experience will be a happy one.

I quite happily used the pervasively multi-threaded BeOS on single-CPU systems for years.

@OlafS25

I only wish the best for AROS. Sure nice to have programs cross compiled to AROS, but at the same time why should you use that program on AROS instead of lets say Windows. It is a good chance it will run faster and be more compatible on Windows with same hardware. Software need lots of bug testing. On Windows there are hell of a lot people testing stuff on AROS there are almost none. That will also make software less good. We realy need people to test stuff for AROS.

@IntuitionAmiga

Quote:

I quite happily used the pervasively multi-threaded BeOS on single-CPU systems for years.

There is significant difference of software for BeOS of yesteryear and today's CPU intense multi-threaded games and applications on x86.

_________________
Dammy

@damocles


Quote:

There is significant difference of software for BeOS of yesteryear and today's CPU intense multi-threaded games and applications on x86.

The BeAPI was designed from the ground up to be multithreaded throughout. There is nothing even close to it still.

Boot Haiku on a multicore i7 beast and you can see for yourself how it scales up, then run it on a single core P4 and you'll see how it still runs so smoothly with hundreds of threads running at a time.

Now run Linux or Windows on the same two machines and note the difference.

If I had the brains I would port AROS-hosted to Haiku. Unfortunately I don't. :)