Welcome, Guest. Please login or register.

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

Description:

0 Members and 1 Guest are viewing this topic.

Offline kamelito

Re: AROS SMP Research: Technical Discussion
« Reply #14 on: August 23, 2013, 12:22:32 AM »
Might be interesting to ask Carl Sassenrath what he thinks about it.
Kamelito
 

Offline psxphill

Re: AROS SMP Research: Technical Discussion
« Reply #15 on: August 23, 2013, 12:24:31 AM »
Quote from: minator;745861
It might be possible to show a nice speedup on some long running highly parallelisable benchmark but that's it.

It doesn't have to be parallelisable, you could have two independent algorithms running on each cpu core.
 
If course it needs to be long running, because if it ran in a short amount of time then a 8mhz 68000 would be enough.
 
If you only have one task that is CPU bound then SMP can't help you, it doesn't matter what OS you use.
 
Quote from: minator;745861
In any real system apps will be constantly stalling the system and you don't need to be Gene Amdahl to know what the result will be.

If one of the tasks spends all it's time in a forbid then there will be no point in using SMP, but I don't believe this is a common case.
 
If it spends 1% of time in forbid then you will lose 1% of each cpu core, 20% of it's time in forbid and you will lose 20% of each cpu.
 
The forbid issue is not ideal, but I think you're overestimating the amount of time it will spend in forbid state.
 
 
Quote from: Ezrec;745870
I'm investigating a spinlock-style SignalSemaphore that has a lower latency for protecting frequently used internal data structures in Exec.

I'd get this working first, once you've got it working properly then you can see what effect the Forbid() has. Changing how the Exec structures are protected will mean changing applications too.
 
SMP 68000 is more likely to happen in an emulator than it is in hardware.
« Last Edit: August 23, 2013, 12:28:53 AM by psxphill »
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: AROS SMP Research: Technical Discussion
« Reply #16 on: August 23, 2013, 12:35:29 AM »
It would be a little bit weird and amazing to have Carl Sassenrath contribute to AROS :)

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: AROS SMP Research: Technical Discussion
« Reply #17 on: August 23, 2013, 02:09:49 AM »
Quote from: matthey;745867
@Ezrec
You have already proved some people wrong with your experiments.


How so?
MorphOS is Amiga done right! :)
 

Offline Terminills

  • Grand Conspirator
  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 588
  • Country: 00
  • Thanked: 2 times
    • Show only replies by Terminills
Re: AROS SMP Research: Technical Discussion
« Reply #18 on: August 23, 2013, 02:22:30 AM »
Quote from: takemehomegrandma;745909
How so?

Lets just wait and see what comes of it.
« Last Edit: August 23, 2013, 12:57:07 PM by Terminills »
Support AROS sponsor a developer.

edited by mod: this has been addressed
 

Offline psxphill

Re: AROS SMP Research: Technical Discussion
« Reply #19 on: August 23, 2013, 02:32:55 AM »
Quote from: matthey;745867
How are you handling the ENABLE/DISABLE FORBID/PERMIT macros (ables.i) that increment and decrement the ExecBase IDNestCnt and TDNestCnt?

That won't work anymore.
 
AFAICT that is from commodore's includes and isn't in AROS, so no software built for AROS should be legitimately manipulating that field in execbase already.
 
If someone creates a SMP 68k machine then they'll need to decide how to support binaries that do that. They could add hardware that checks for a write to that location and make it store the value in another register and cause an interrupt on the relevant cpu, in the interrupt handler it can check the value and call forbid or permit.
 
It's not a problem that needs solving yet anyway.
 

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: AROS SMP Research: Technical Discussion
« Reply #20 on: August 23, 2013, 02:46:35 AM »
Quote from: Terminills;745911


Lets just wait and see what comes of it.


What's that supposed to mean?

:confused:

I merely asked matthey to clarify his "You have already proved some people wrong with your experiments" statement.
MorphOS is Amiga done right! :)
 

Offline psxphill

Re: AROS SMP Research: Technical Discussion
« Reply #21 on: August 23, 2013, 02:57:54 AM »
Quote from: bloodline;745901
It would be a little bit weird and amazing to have Carl Sassenrath contribute to AROS :)

He's unlikely to have thought about exec in nearly 30 years. If he has any sense he's forgotten everything he knew about it.
 
There is unlikely to be any major design work left right now, although there might be some minor design work depending on what is found during coding/testing.
 
Coding, testing and fixing the current design and then testing the speed to see whether any changes are required is the current goal.
 
Even if it wastes 10% of each core then SMP could still have a big win.
 
However moving data between cpu cores might have an overhead, so sharing tasks across cpu's might not be the best strategy. It might make more sense to saturate a cpu and only spin up another cpu if there are still more tasks ready.
 
Only when the simple implementation is done can you get enough information to make those decisions. It's complex enough that guessing isn't easy.
 
Quote from: takemehomegrandma;745915
I merely asked matthey to clarify his "You have already proved some people wrong with your experiments" statement.

Some people said you couldn't do SMP with exec. Technically he hasn't proved them wrong as he's moved fields out of execbase, which was the only reason you can't do SMP with exec. His plan is to avoid the theoretical discussions of the implications of that and just try to code it, often this is the only way to solve an argument & it's actually how AROS came to exist.
 
Once you have an implementation then have a baseline. After evaluating it for any drawbacks you can try to address those and then when you test it you can know whether it's better or worse. The problem with arguing over technical concepts is that it is very difficult to judge their merit. Until you see the code running it's unlikely you'll have any idea what the cache implications are of using SMP etc.
« Last Edit: August 23, 2013, 03:08:19 AM by psxphill »
 

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: AROS SMP Research: Technical Discussion
« Reply #22 on: August 23, 2013, 04:32:21 AM »
Quote from: psxphill;745916
Some people said you couldn't do SMP with exec.


Wasn't the issue rather about SMP and full Amiga backward compatibility?

Either you have full compatibility, or software needs to be built for your particular system, right? If the latter, wouldn't it be better to take the opportunity to create a new multithreaded SMP environment/API once and for all (together with proper memory protection, 64-bit, etc while you're at it)? A "little" more work of course ;), but if you are making a "new" system anyway, why don't go all the way?

It's an interesting little AROS experiment though, and maybe something that's usable for real for AROS will come out of it eventually, who knows? :) I just wanted a clarification about the "proved people wrong" statement!

;)
MorphOS is Amiga done right! :)
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: AROS SMP Research: Technical Discussion
« Reply #23 on: August 23, 2013, 05:00:58 AM »
Quote from: matthey;745867
@Ezrec
You have already proved some people wrong with your experiments.

Quote from: takemehomegrandma;745909
How so?


Some people said you can't rocket to the moon and walk on it. They were proved wrong when it was accomplished by Neil Armstrong. Some people said that SMP couldn't be done with AmigaOS. Jason McMullan walked on the moon. It may be one small step but it's one giant leap for Amiga-kind ;).
 

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: AROS SMP Research: Technical Discussion
« Reply #24 on: August 23, 2013, 07:58:14 AM »
Quote from: matthey;745921
Some people said that SMP couldn't be done with AmigaOS.


I don't think anyone has claimed that SMP couldn't be done in a situation where the precondition is that SW base is being built explicitly for that system? Rather the opposite, actually; this is a given! What "people" said is that true SMP can't be done without breaking the Amiga compatibility, which I suppose is a more relevant issue on MorphOS/OS4 than on AROS anyway, since the latter has been CPU/ISA agnostic since pretty much the beginning hence most people are happy to either run AROS builds of whatever SW they use, or run it in an UAE environment.
MorphOS is Amiga done right! :)
 

Offline wawrzon

Re: AROS SMP Research: Technical Discussion
« Reply #25 on: August 23, 2013, 08:12:18 AM »
back to topic please. this is supposed to be technical discussion.
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: AROS SMP Research: Technical Discussion
« Reply #26 on: August 23, 2013, 08:25:56 AM »
Quote from: psxphill;745900

If it spends 1% of time in forbid then you will lose 1% of each cpu core, 20% of it's time in forbid and you will lose 20% of each cpu.


I think problem is not how much time is spent in Forbid() but overhead required to synchronize CPUs. In single core systems Forbid() is extremely light weight call. The same goes with Disable() which was implemented as simple assembler macro on old 68k days.

Now problem is that many many Exec calls are heavily depending on Disable()/Enable() to protect internal data structures. The message passing system in Exec is extremely light weight and used a lot in the system and in applications but in multicore systems it is far from ideal.

Having to stop other CPUs only to AddTail() new message is massive overhead.
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: AROS SMP Research: Technical Discussion
« Reply #27 on: August 23, 2013, 08:43:53 AM »
Quote from: psxphill;745900
If it spends 1% of time in forbid then you will lose 1% of each cpu core, 20% of it's time in forbid and you will lose 20% of each cpu.

Oh, btw... you have to consider that other CPUs can call forbid not just that first one. When adding more CPUs chances to be in forbid state increases.

Problem could be demonstrated using silly pingpong task sending message back and worth constantly. Because sending a message requires forbid that task that could easily render other cores useless. Even when running at low priority it would disrupt higher priority task on other cores, due to forbid/disable semantics.

The net effect is high priority tasks run slower on multicore system than they would run on single core system.
« Last Edit: August 23, 2013, 08:47:45 AM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline NorthWay

  • Full Member
  • ***
  • Join Date: Jun 2003
  • Posts: 209
    • Show only replies by NorthWay
Re: AROS SMP Research: Technical Discussion
« Reply #28 on: August 23, 2013, 09:40:35 AM »
This reminds me of the BSD(?) Big Lock(?) discussion. All SMP stuff passed through a single lock and they did a lot of work to split the different parts into having their own lock.

First port of call is of course to drop Forbid/Permit use and go to using semaphores where possible, and perhaps find a lockless design.

IIRC I optimized my Exec patch to make semaphores assume success on first try and so not call Forbid if the semaphore was not held by someone else.
 

Offline psxphill

Re: AROS SMP Research: Technical Discussion
« Reply #29 from previous page: August 23, 2013, 12:35:10 PM »
Quote from: itix;745940
Oh, btw... you have to consider that other CPUs can call forbid not just that first one. When adding more CPUs chances to be in forbid state increases.

Tell me how you will find out what the percentage of time various software will spend in forbid without trying it?
 
Quote from: itix;745940
Problem could be demonstrated using silly pingpong task sending message back and worth constantly. Because sending a message requires forbid that task that could easily render other cores useless. Even when running at low priority it would disrupt higher priority task on other cores, due to forbid/disable semantics.

You have always been able to write software for AmigaOS which disturbs high priority tasks. If it turns out that this is a problem that needs solving then you could try changing it so that cpu's will only ever be running a task that has the same priority. As high priority tasks are supposed to run for a short period of time then wasting the other cores during that time may not be a big deal. If you have a high priority task on AmigaOS that takes a long time then it becomes unusable (standard priority tasks like workbench won't be allowed to run at all). The priority in AmigaOS is quite fine grained (-128 to 127 IIRC) which means you could also derail this using as many as possible. But there is no reason why software that can take advantage of SMP shouldn't have limitations (like all Tasks that run at the same time have to run at the same priority).
 
I understand about the Forbid() overhead, if something spins in a Forbid()/Permit() call then it could cause problems. But is that something that any software should need/want to do? We pretty much have the source to all AROS software at this point & this isn't going to affect AROS 68k.
 
There is no reason why the number of cores in use at a time couldn't be dynamic & when you're only using 1 core then the Forbid()/Permit() overhead could be reduced to current levels. If it can detect situations where the SMP implementation will help and which will hurt then you could always end up benefiting.
 
Technologies like Intel Turboboost benefit from only using as many cores as necessary, i.e. when you're only using 1 core it can boost the clock speed but when you're saturating all cpu cores then it drops back to the default (some chips can sustain constant boosting, but in a laptop you'd want to minimize it for power usage).
« Last Edit: August 23, 2013, 12:44:21 PM by psxphill »