@BSzili

Quote:

Therefore, the scheduling of Exec tasks and processes will remain something a single CPU will do for itself, even in multi-core. This will ensure a reasonable time is spent on this task.

Maybe I misinterpret this lines, there is only one CPU in X1000, that has two cores, so I assumed it was one task that was going to deal with it.

Or it can be read as.

CPU should have been a CORE, and there for "itself" means etch core.

CPU and CORE is not the same thing, maybe just small typo.

Last edited by NutsAboutAmiga on 26-Feb-2015 at 03:34 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@BSzili

Quote:

What are the things that are done now, but they weren't in 2013? It took 2 years to replace Forbid/Permit with locks running on a single core?

And they have rewritten the task scheduler into C and reshaped Exec Base.

In 2 years basically, while working on FireFox, LibreOffice, and Warp3D

And they did the extended memory object thing.

http://blog.hyperion-entertainment.biz/?p=1131

Last edited by NutsAboutAmiga on 26-Feb-2015 at 03:49 PM.
Last edited by NutsAboutAmiga on 26-Feb-2015 at 03:47 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

you mean the famous bounty with the excellent bug-free firefox port, the "never-seen-by-anyone" Warp3D driver and the "almost complete" LibreOffice port? Wow

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @BSzili Quote: What are the things that are done now, but they weren't in 2013? It took 2 years to replace Forbid/Permit with locks running on a single core? And they have rewritten the task scheduler into C and reshaped Exec Base. In 2 years basically, while working on FireFox, LibreOffice, and Warp3D

That must have been so much easier after doing it the first time round:

Quote:

Posted by Steven Solie on October 24, 2013 X-Kernel Update: Task scheduler rewritten in C Removed reliance on data structures (e.g. ExecBase task lists and ThisTask pointer) Moving scheduler to run on auxiliary cores All cores schedule tasks independently Load balancing between cores

(In fact some of the items listed above appear now, 1.5 years later, to not be implemented yet according to the latest blog update.)

Quote:

Posted by Thomas Frieden on February 25, 2015: The development of SMP support has been separated into several distinctive steps. The first step was to rewrite the scheduler in C for easier accessibility. [...] The second, more fundamental step was to decouple the scheduler from its current data structures. [...] This has now been achieved. [...] The next step is to have each core in the development system (currently, the X1000) to run the scheduler.

http://blog.hyperion-entertainment.biz/

Quote:

And they did the extended memory object thing. http://blog.hyperion-entertainment.biz/?p=1131

They did, and that deserves acknowledgement.

Last edited by Boot_WB on 26-Feb-2015 at 05:55 PM.

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

@Boot_WB

They barely have proper usb2 support and regular drivers for the alien hardware and you guys really believe in SMP on amigoid os? *Face Palm*

@realize

Yes, it is just a question of time, but if they keep on working on everything else, they will not finish anything, this is the main problem, as I see it.

USB2 support work pretty well on X1000 and Sam hardware, older and more buggy hardware is a different story. I do not think the Frieden brothers worked on USB2. That was someone else I believe.

Last edited by NutsAboutAmiga on 26-Feb-2015 at 07:30 PM.
Last edited by NutsAboutAmiga on 26-Feb-2015 at 06:53 PM.
Last edited by NutsAboutAmiga on 26-Feb-2015 at 06:50 PM.
Last edited by NutsAboutAmiga on 26-Feb-2015 at 06:49 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Buddy some of the top amiga programmers of all time (mostly morphos guys) say that SMP wont happen as it will break everything. Which defeats the whole point of AmigaNG.

@realize

Quote:

mostly morphos guys

This is AmigaOS, not MorphOS.

@realize

A World said man will never fly, 2 men proved them wrong...

_________________
Hate tends to make you look stupid...

"Buddy some of the top amiga programmers of all time (mostly morphos guys) say that SMP wont happen as it will break everything. Which defeats the whole point of AmigaNG."

That actually makes it much more an achievement if they make it :)

_________________

José

@sundown
How about actually referring to real world stuff and not modern myths? That would make it more relevant.

@realize

IMHO one can't keep full compatibility with old (Amiga) software when going SMP and even going SMP requires some hardware support.
But the reality is that PPC amigoid systems already are incompatible to a certain degree.
What is listed in the blog post are mostly obvious things but the important parts aren't described at all:
Exactly HOW is the forbid() execution detected? Programs can directly manipulate a specific memory address with inline code. Sure detection of a write to the zero page can be done but is that efficient enough?
How is the case where two separate tasks use a shared resource multiplexed solely by the scheduler handled? Even using something like executive can break valid programs and moving to parallel execution will break even more.

Technical: the Hyperion blog are not describing an SMP system. SMP means _symmetrical_ multi-processing where processors are equal peers in the system - and doing some work on one processor alone means it is an AMP or asymmetrical multiprocessor.
That in itself doesn't mean much in reality but still we aren't talking about an SMP system.

@QuikSanz

1%? ... and the rest.

Just emptying out a message port before closing pretty much requires it.

I reckon it is more like 90-95%. Either way, it looks like the Friedens are on the verge of confirming they have something to make it work, so that's great.

Thankyou Hyperion for the update +1

Very nice to read about SMP status.

Progress has been made it seems, some of the faced obstacles have been overcome and at the same time no-one knows all the obstacles ahead. Hopefully one day....

Also nice to see they keep their eye on e6500 solutions. Hopefully they manage test SMP AOS also on Qoriq T4 system to make it more futureproof.

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

@realize

"Buddy some of the top amiga programmers of all time (mostly morphos guys) say that SMP wont happen as it will break everything."

Even if it would break everything, it must be done, also for MorphOS.

"Which defeats the whole point of AmigaNG."

That is full off bull*.

Amiga is more than legacy compatibility. Legacy compatibility is nice but not mandatory.

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

@megol

Indeed. See

Here is some interesting points from AROS SMP presentation.

Quote:

* Several user visible APIs require Forbid()/Disable() filesystem.resource, GfxBase->DefaultFont, etc * Many programs use Forbid(), not SignalSemaphore * Assumptions about AddTask() priority and blocking Disable() is bad in user space: * Causes all interrupts to stop * No task switching may occur * MUST stop all work on all other CPUs * Expected to be a fast operation - but is not in SMP! Forbid() is bad in user space: * No task switching may occur * MUST stop all work on all other CPUs * May be broken by a number of OS calls * Must be restored when control returns! Forbid/Disable ruins performance on SMP * Both go from ‘cheap’ to ‘expensive’ in SMP! We need to eliminate Disable/Forbid in exec.library * Over 60 functions use it in exec.library! Can’t replace them with SignalSemaphores * SignalSemaphore relies on Signal() and Wait().. * * Which rely on Disable!

There is of course now Forbid() free SignalSemaphore and many more changes.

Last edited by itix on 27-Feb-2015 at 09:18 AM.
Last edited by itix on 27-Feb-2015 at 09:13 AM.

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

@itix
The costs of executing Forbid()/Disable() are the "big" problem for multiprocessing. It would be manageable (but still very expensive) if all uses would be through the Exec code - but detecting those uses that are implemented via macros are harder to make efficient.

That's the reason I've suggested a lightweight hardware support mechanism that essentially detects and stalls all execution except for the task invoking Forbid(). That would mean that each processor can stop and resume execution within a few cycles. That doesn't solve all problems of course.

Alas to even try such a design requires FPGA processors and the likelihood that a sMP FPGA design being faster than a single core PPC is low... And if it's not why even bother? :)

way is smp soo importent ???
i dont say multiprocessing is not needet becuse it is.. but way is AMP not cool anuf ?

@retro

AMP is basically some programs run on one core, some run on different core, its dumb way to support multi-processor, because there is no load balancing between the cores.

AMP could be a good start, but it's not as flexible as SMP.

If you think back to PowerUP / WarpOS, most programs where running on 680x0 CPU (as that's was the only place 68k where able to run), and where few program supported the PowerPC. So in most cases there were no benefit to having an extra CPU.

Now we have Two or more CPU cores, but just one is in use, that’s not good because we are not using the CPU too its fullest, and believe me we need all CPU power we can get for emulators and video playback and games and programs.

We do not wont one core to sit there ideal most of the time, while other core is having a hard time, we want the work load to be shared between the two cores, so that do not happen.

Due to L1 cache programs should not be moved between core unless absolutely necessary, because other wince the L1 cache will need to be flushed to often that just going to slow down the cores.

So in AMP you make like special program that run on the other core.
On SMP all programs are supposed to behave the same, so this is challenge to allow programs to run unmodified on all cores and allow what they have always done.

The AROS developers has come to conclusion that this is possible but its slow. Now the AmigaOS4 developers will just have to prove AROS developers wrong.

Last edited by NutsAboutAmiga on 27-Feb-2015 at 08:53 PM.
Last edited by NutsAboutAmiga on 27-Feb-2015 at 05:03 PM.
Last edited by NutsAboutAmiga on 27-Feb-2015 at 05:01 PM.
Last edited by NutsAboutAmiga on 27-Feb-2015 at 04:02 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS