AROS SMP Research: Technical Discussion

[vidarh]

I don't think this should even be considered unless as an absolute last resort. Making that compromise without knowing what the benefits are would be a mistake.

It's not a compromise. It is the clean alternative.

Forbid()/Disable() is the hacky comprise.  In a single CPU system, when done in cases where you're "only" swapping a pointer or two, it can be forgiveable. In pretty much all other instances, it is a big, giant, lazy cop-out that made coding it a tiny bit easier back in the day compared to using semaphores and mutexes to protect the *specific* structures that an application needs to access safely.

Now, I agree that it's not necessary to jump straight into tearing out every Forbid()/Disable() you can find. But we can categorically state that having them there is bad. It's just that for the most part it won't be bad enough to prevent us from seeing some benefit from SMP, and so removing them can wait until there's some SMP support working.

It certainly makes sense to prioritise *where* to clean up Forbid()/Disable() calls first based on profiling which ones actually hurt the most.

[matthey]

I seem to remember some _old_tool that counted OS calls of your choice.
(When I say old I am thinking Fred Fish age.)

wait a minute. couldnt you come up with what it was? there is tremendous overhead on some aros68k operations as i see on a slow system and it would be great to identify most frequently called functions while it happens without doing profiling job, which im not able to.

LibraryTimer perhaps?

http://aminet.net/search?query=LibraryTimer

[psxphill]

It certainly makes sense to prioritise *where* to clean up Forbid()/Disable() calls first based on profiling which ones actually hurt the most.

Removing Forbid calls is a compromise because it will break software in ways that is difficult to detect, but if the speed up is huge and can't be done in any better way then there may be some justification.
 
If you're allowed to break software then it becomes a whole lot easier.
 
 

You missed one very important difference. My example would run just fine on any traditional non-SMP Amiga OS system. Your example wouldnt.
 
Change Forbid() to SetTaskPri(task, 127) and you would have an example where SMP is superior to non-SMP system.

Your software doesn't do anything useful and neither does mine, I don't see a difference. However when Windows started supporting multiple cpu cores there was software that ran worse on SMP systems than on single cpu systems. Until we can benchmark it then you can't tell if it's worth worrying about.

[itix]

AROS is in the process of breaking all binary compatibility with past AROS versions anyway, so it's perfect timing for the SMP work as all apps will need to be recompiled, but frankly I just don't believe that it's worth being all that concerned about breaking compatibility over this - the systems where we may want to care about compatibility are the classics, and it's not like they are SMP systems anyway...

This is not just a user application problem. Also the OS internals depend on Forbid/Enable and replacing Forbid/Enable in one OS call can cause serious implications to other parts in the OS.

[matthey]

However when Windows started supporting multiple cpu cores there was software that ran worse on SMP systems than on single cpu systems. Until we can benchmark it then you can't tell if it's worth worrying about.

For completely linear processing, a single core scalar processor is most efficient. Single core processors are generally more powerful than a single core in a processors with SMP that has the same resources. Likewise, a a scalar processor is generally going to be faster than a superscalar or OoO processor with all dependent code and the same resources. There is hardware overhead in parallel processing and that's not even counting the software overhead.

[psxphill]

There is hardware overhead in parallel processing and that's not even counting the software overhead.

My point is that there is always a software overhead. Saying forbid will have to go because of an unmeasured software overhead is putting the cart before the horse.
 
It's not like an abi change where just a recompile is needed, it would require code audits and potentially redesigns. So changing from Forbid to a semaphore should be avoided until it's known what the advantage is (and if there is indeed a visible advantage).

[Karlos]

This is not just a user application problem. Also the OS internals depend on Forbid/Enable and replacing Forbid/Enable in one OS call can cause serious implications to other parts in the OS.

Of course. That said, since it's the OS you'd be working on, one would hope these are the ones that are easiest to find and engineer replacements for

[wawrzon]

LibraryTimer perhaps?

http://aminet.net/search?query=LibraryTimer

thanks, matt, great proggy! exactly what i was looking for.

[minator]

For completely linear processing, a single core scalar processor is most efficient. Single core processors are generally more powerful than a single core in a processors with SMP that has the same resources.

Likewise, a a scalar processor is generally going to be faster than a superscalar or OoO processor with all dependent code and the same resources.

For that to be true every single instruction would have to depend on the previous instruction.
This is pretty much never the case so the OoO processor will win.

There is hardware overhead in parallel processing and that's not even counting the software overhead.

Yes.

[Blizz1220]

I remember that when AMD went dual core it made a press release saying that they are working on single core simulator/emulator in hardware to fight the lack of software that only used single core ...

What happened to that project ?

[psxphill]

Of course. That said, since it's the OS you'd be working on, one would hope these are the ones that are easiest to find and engineer replacements for

Changing the OS will break the user programs too.
 

I remember that when AMD went dual core it made a press release saying that they are working on single core simulator/emulator in hardware to fight the lack of software that only used single core ...
 
What happened to that project ?

Wasn't that a joke/fake? http://www.theinquirer.net/inquirer/news/1009078/reverse-hyperthreading-exist
http://forums.anandtech.com/archive/index.php/t-2198930.html