Welcome, Guest. Please login or register.

Author Topic: AROS SMP Research: Technical Discussion  (Read 10714 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show only replies by vidarh
Re: AROS SMP Research: Technical Discussion
« Reply #44 from previous page: August 23, 2013, 11:53:13 PM »
Quote from: psxphill;745962
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.
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by 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

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by 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

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by 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

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16867
  • Country: gb
  • Thanked: 4 times
    • Show only replies by 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

  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 592
    • Show only replies by minator
    • http://www.blachford.info
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

  • Full Member
  • ***
  • Join Date: Jan 2013
  • Posts: 189
    • Show only replies by 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 »