Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: AROS SMP Research: Technical Discussion  (Read 7410 times)

0 Members and 1 Guest are viewing this topic.

Offline matthey

Re: AROS SMP Research: Technical Discussion
« Reply #45 on: August 24, 2013, 01:26:36 AM »
Quote from: NorthWay;745955
I seem to remember some _old_tool that counted OS calls of your choice.
(When I say old I am thinking Fred Fish age.)


Quote from: wawrzon;745965
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
 

Offline psxphill

Re: AROS SMP Research: Technical Discussion
« Reply #46 on: August 24, 2013, 01:43:17 AM »
Quote from: vidarh;746023
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.
 
 
Quote from: itix;746016
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.
« Last Edit: August 24, 2013, 01:58:18 AM by psxphill »
 

Offline itix

Re: AROS SMP Research: Technical Discussion
« Reply #47 on: August 24, 2013, 02:12:56 AM »
Quote from: vidarh;746022
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.
My Amigas: A500, Mac Mini and PowerBook
 

Offline matthey

Re: AROS SMP Research: Technical Discussion
« Reply #48 on: August 24, 2013, 02:43:15 AM »
Quote from: psxphill;746034
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.
« Last Edit: August 24, 2013, 04:16:19 AM by matthey »
 

Offline psxphill

Re: AROS SMP Research: Technical Discussion
« Reply #49 on: August 24, 2013, 09:12:14 AM »
Quote from: matthey;746038
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).
« Last Edit: August 24, 2013, 09:16:32 AM by psxphill »
 

Offline Karlos

Re: AROS SMP Research: Technical Discussion
« Reply #50 on: August 24, 2013, 01:32:18 PM »
Quote from: itix;746036
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 ;)
int p; // A
 

Offline wawrzon

Re: AROS SMP Research: Technical Discussion
« Reply #51 on: August 24, 2013, 01:37:46 PM »
Quote from: matthey;746033
LibraryTimer perhaps?

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


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

Offline minator

Re: AROS SMP Research: Technical Discussion
« Reply #52 on: August 24, 2013, 02:02:56 PM »
Quote from: matthey;746038
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.


Quote
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.

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


Yes.
 

Offline Blizz1220

Re: AROS SMP Research: Technical Discussion
« Reply #53 on: August 24, 2013, 03:39:40 PM »
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 ?
 

Offline psxphill

Re: AROS SMP Research: Technical Discussion
« Reply #54 on: August 24, 2013, 06:25:04 PM »
Quote from: Karlos;746058
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.
 
Quote from: Blizz1220;746075
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
« Last Edit: August 24, 2013, 06:28:41 PM by psxphill »