@pavlor

Most definitely, since I'm basing my claim on what was written in the blog posts. If it's open to interpretation, then anyone can come up with their own version of what has been done.

_________________
This is just like television, only you can see much further.

@All

In SMP the cpu cache plays a very important role for performances.

How about the cache specs for the X1000 cpu?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@NutsAboutAmiga

Quote:

The AROS developers has come to conclusion that this is possible but its slow.

First I've heard of this. Which AROS developers said that? :P

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@retro

by retro on 28-Feb-2015 5:30:19

"am i a racist if i say my general perception of french pepole is that there are arrogant ???
bon appetite
https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcT0y_SzWYC07nOiv1hfxbWC14Vw7-bQH1CmOACjdW_tcXvNaXqX"

First, WTF ? Why complains about french in this thread ?
Some frenchs were arrogants with you ? Only one french, Kamelito joined this thread, and he even don't reply/speak to you. But you are right. For example, speaking in general, a lot of Amigans peoples are arrogants, french or others (only them have the holly truth, not a joke) but it's not a french problem, it's a os4/mos problem, therefore why target us, french people ?

Excuse me Retro, but where do you come from, your profile is laking country ?

Unlike you, I don't want to insult a whole country only for an single person... You see, i'm french and not arrogant (I think), i'm quiet, you judge people certainly based of few posts from french people here. Where ? (Sources) Who (links) ?
And honestly, according to your dirty looking frogs BBQ picture, it doesn't look like french peoples eating frogs, yes, we eats frogs and snails (very good, i could damn myself for good ones) but your froggyed picture certainly come not from France (Asia ?)


To conclude, 3 questions :
1) why do you target french peoples ?
2) where do you come from (i certainly have generality about your country) ? Generality are assholes reflexions, as you know...
3) what about the current SMP thread ?

And don't worry, if you were in you biological lessons. (frogs pictures), you will have learn that we are all part of the same race... We are all human, without subdivisions (no MOS, OS4, AROS subdivisions ). Therfore, you are not racist, you are just an xxx

I expect no reply from you, Retro...It was just to don't keep this strange unexpected xenophob thread seek on the internet limb...

If it was a try to be funny, many many and more many sorry... I understood nothing...

Guillaume 'zzd10h', a french arrogant OS4 user, eater of frogs and snails (snails with garlic are better than an AmiUpdate).


For exzmple, me, I don't judge swedish people because one of them, MOS user, IxxX is very arrogant ? No I judge Swedisch for a more important character, their beers are only 3° (at least at Stockholm) an international shame, :) (swedisch amigans, i'm jocking of course)

Last edited by zzd10h on 28-Feb-2015 at 05:42 PM.
Last edited by zzd10h on 28-Feb-2015 at 05:29 PM.

_________________
http://apps.amistore.net/zTools

@zzd10h

I think, from the context and quote in his post, he thinks 'realize' is French, which might explain his iritation, but not excuse his generalisation about French people, who on the whole I found to be very welcoming on my tours in France.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@terminills

http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=39959&forum=14&start=40&viewmode=flat&order=0#753079

Itix quote

Last edited by NutsAboutAmiga on 28-Feb-2015 at 05:56 PM.
Last edited by NutsAboutAmiga on 28-Feb-2015 at 05:55 PM.

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

@broadblues
Thank you,
Yes, i think that you are right, and that retro misthought that "nyc" means France instead of New York... Yes,... Strange nevertheless.

[OT SMP thread]
But i'm happy that.you have a good feeling of France even if I remember (according to FB) that you prefered the south the last summer ;) no dates near Paris or center of France.

[/OT SMP thread]

Last edited by zzd10h on 01-Mar-2015 at 02:12 AM.

_________________
http://apps.amistore.net/zTools

@zzd10h

Quote:

zzd10h wrote: No I judge Swedisch for a more important character, their beers are only 3° (at least at Stockholm) an international shame, :)

When I happen to visit in Sweden, I usually buy cheap 5-8% beers from Systembolaget :)

Last edited by jPV on 28-Feb-2015 at 08:52 PM.

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO

@jPV

Thank you for the advice, i didn't know.
Don't forget in the quote, "(swedisch amigans, i'm jocking of course)"

_________________
http://apps.amistore.net/zTools

@retro

It is not nice to read these things, better to edit the post because, you know ... in Internet bad figures remains ...

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@All

Which are the cache specifications for the X1000 cpu?

L1, L2, ... ?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

See here :

http://apps.amistore.net/zTools/images/03_zTools_SysMon.JPG

L1 L2 L3 = 64 / 2048 / 0

_________________
http://apps.amistore.net/zTools

Is it just me, or does this blog entry miss the point by a country mile? I mean, yeah, it's great to think about how/where to run the scheduler, and what language it will be (re)written in, but.... that's details one should worry about after one solves the rather more fundamental problems.

Dealing with explicit "Forbid()" instances is but one tiny part of the fundamental problem. Translating each Forbid() into a mutex acquisition solves merely the most trivial of issues.

AmigaOS (and in particular, its scheduler) has, until now, always made a number of implicit guarantees. A few that come to mind:

1) No task will run when a higher priority task is runnable. This means that of two tasks sharing access to a common, critical piece of data, only the lower priority one need ever issue a Forbid(); The higher priority one does not need to do so, because it simply cannot be interrupted by the lower priority one halfway through the access.

2) Interrupt handlers are atomic with respect to non-interrupt code and lower-priority interrupt handlers. Thus, any interrupt handler that wants to do multi-step changes to shared state can do so at will, without ever issuing any kind of locking. (In a related issue, non-interrupt code that wants to access such data needs to Disable() rather than Forbid(); No mention was made in the blog of how to deal with Disable()).

3) Nothing happens between the start of an instruction and the end of it. This means that no task will ever see the memory state created by another task with a half-executed instruction.

4) Instructions are executed in order, as far as the observable state is concerned. At no point, ever, will one task see a state created by another task which includes the effect of one instruction, but excludes that of another, earlier instruction.


The issues with (1) and (2) should be obvious --- converting the explicit Forbid()/Disable() into locks will do absolutely nothing about implicit exclusivity of access. I.e. for (1), if the lower priority task, running on core A, does a Forbid() (and thus acquires the mutex), that does absolutely nothing to stop the higher priority task, running on core B, from accessing the shared data at the same time.

(3) is interesting because even on a load-store architecture like the PPC, memory accesses are not necessarily atomic. OS4 shares the same data structures as OS3, and from experience, I can say that in typical use, around 20% of all 32 bit accesses on OS3 are *not* 32 bit aligned. Given a cache line size of 32 bytes, that means that very roughly 2.5% of 32 bit accesses would be crossing cache line boundaries. Those accesses get internally translated into two separate reads or writes. That's fine if only one core ever accesses memory (because, somewhat simplified, that core's memory controller does one access after the other, so it won't start reading memory until a cache-boundary-crossing write has completed both its parts). But when two cores concurrently access memory, things can (and do) go awry.

(4) is even more interesting --- because unlike the x86/x64, which (mostly) guarantees that things happen (or rather, are observed to happen) in order, the PowerPC has an extremely relaxed memory model. Each core can (and does) re-order its (externally visible) memory accesses pretty much at will. So if core A executes the code "a=1; b=1; ....stuff...; a=2; b=2;" and core B executes "if (b>a) then die(HORRIBLE_DEATH);", that condition on core B may very well trigger, because the "b=2" becomes externally visible before the "a=2" does. The only way to prevent that is by putting in explicit memory barriers or fences. This can lead to all sorts of trouble when using data structures that have separately updated payload and status fields --- with the guarantees AmigaOS has always made, updating the payload before setting the status to "up-to-date" ensured that any entry observed as "up-to-date" by another task would indeed hold valid payload data. Not so anymore when the other task runs on a different PPC core.



I find it somewhat scary that the blog post does not even hint at any of these issues. Given that they are all issues that would cause rare and subtle race conditions, not dealing with them might even result in something that works. Most of the time, kinda, but has a tendency to fail/misbehave subtly (and possibly unnoticeably) under actual load. And those kinds of failures are hard to reproduce, and even harder to debug (as I am sure the sillySMP developers would agree...).


(Incidentally, the whole "68k read-modify-write instructions have always been atomic in AmigaOS, but in OS4's emulation architecture, are not" causes a similar, apparently completely ignored issue for 68k legacy code).

Quote:

umisef wrote: (4) is even more interesting --- because unlike the x86/x64, which (mostly) guarantees that things happen (or rather, are observed to happen) in order, the PowerPC has an extremely relaxed memory model. Each core can (and does) re-order its (externally visible) memory accesses pretty much at will. So if core A executes the code "a=1; b=1; ....stuff...; a=2; b=2;" and core B executes "if (b>a) then die(HORRIBLE_DEATH);", that condition on core B may very well trigger, because the "b=2" becomes externally visible before the "a=2" does. The only way to prevent that is by putting in explicit memory barriers or fences. This can lead to all sorts of trouble when using data structures that have separately updated payload and status fields --- with the guarantees AmigaOS has always made, updating the payload before setting the status to "up-to-date" ensured that any entry observed as "up-to-date" by another task would indeed hold valid payload data. Not so anymore when the other task runs on a different PPC core.

Does the PPC MMU not support a "precise" mode of memory operation which avoids write re-ordering, write combining and possibly even a write buffer all together? If super sloppy memory accesses are the only option, how can the PPC deal with hardware registers?

Quote:

(Incidentally, the whole "68k read-modify-write instructions have always been atomic in AmigaOS, but in OS4's emulation architecture, are not" causes a similar, apparently completely ignored issue for 68k legacy code).

You are talking here about 68k instructions which commonly perform a CISC style read-modify-write memory access like:

[code]
addq.l #1,(a0)
[/code]

and *not* the read-modify-write instructions like TAS, CAS, and CAS2 which are incompatible with the Amiga custom chips?

It's not uncommon to find 68k instructions using normal CISC atomic read-modify-write accesses in interrupt handlers. This normal 68k behavior would be tricky to handle correctly although not handlng it would work most of the time (until all 68k code has been banished?). I wouldn't go into too much controversial talk and details on multi-processing in a blog meant to show development continues after a certain bankruptsy either. The blog is very easy to understand and interesting. I believe it has succeded in deflecting talk away from the bankruptsy.

Last edited by matthey on 01-Mar-2015 at 12:11 PM.

@umisef

this is very interesting and all, but i think these are issues to be discussed if something was being seriously developed in the first place. i wonder how one can oversee that 70% of this article is again a generic introduction into multiprocessing concepts laid out (in contrary to your post) in very popular way. it seems as if the article was directed at someone who knows nothing about the subject or purposely reiterates what the reader likes and excepts to read. then there is a section about how forbid /permit can be worked around (roughly), which we have also heard for years and if i remember correctly the ideas were actually first mentioned while discussion of forums and mailing lists like this, before being practically tested and demonstrated in aros silly smp. and then there are two short sections. one about "where are we now", which also contains information known since two years except for its second half, four last sentences that actually state what next step will be and that something "will" happen:

Quote:

The next step is to have each core in the development system (currently, the X1000) to run the scheduler. Test code will then start tasks on the different cores and see how they behave. We have already experimented with this and the results look promising. The tests basically showed that the lockout mechanism for Forbid works as planned. As a final step, the balancing will be introduced, which then finalizes the first implementation of SMP support in AmigaOS.

curiously, after these future tense declarations another short section is dedicated to "future plans" and reads in context of a platform that lacks basic hardware acceleration or other contemporary technologies like complete science fiction, starting with currently implemented classic round-robin scheduler and arriving a few sentences later at intelligent scheduler learning and applying the user profile.

seriously, the article reminds me of a quick last minute home work written on a knee in a streetcar on a way to school. some general knowledge. some stuff written off from the neighbor. vague hints at own research one could have done if not playing fps all night. and a fantastic conclusion that seem to reward the random and boring rest. two requested pages filled, the teach may not be amused but he will let it though.

@umisef

OT: Only the first is a real problem for a 68k FPGA softcore though. And even that can be managed - e.g. one could tag programs that doesn't depend on this as "pure" and run other software in single processor mode.

@umisef

1) That became void with 3rd-party schedulers such as Executive. Very few programs had a problem with the way Executive constantly kept changing priorities.

A system friendly program doesn't do active polling while relying on task priorities for data protection since priorities can be changed by the user (or a different scheduler).

2) I agree this could be an issue, especially with drivers running on a different core than the app using the device run by that driver. I suppose Disable() would have to be implemented similar to Forbid(), simply stopping the other cores whereever they are executing. Still, apps should not poke/poll into driver data and vice versa. Using system calls to talk to drivers (DOS devices?) this is no issue.

3) That became void with PPC and Petinua JIT. Noone writes in assembly anymore so noone cares. 68k instructions aren't atomic anymore with Petunia anyway except for the one single instruction that has to be: TAS. Still everything works except hacky games and demos which have other requirements anyway.

4) Why would that happen now, and how is that different from normal multitasking where a task can be "invisibly" interrupted at any point. Wouldn't this be a problem for any code/OS running on PPC? Setting payload+status, then signal another task (on a different core), that core reading the new value of status but the old value of payload? How is this a specific problem for AmigaOS?

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@zzd10h

Thanks.

I guess L1 is 64 KB for instructions and 64 KB for data ... correct?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

http://www.hotchips.org/wp-content/uploads/hc_archives/hc18/2_Mon/HC18.S2/HC18.S2T1.pdf

You can see the architecture on page 10, so, yes, L1 64k instr + l1 64k data .
And 2Mb L2 is shared with the two cores.

On page12 you see the bandwidths/speed of the caches.
etc...

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

@KimmoK

Allright, thanks.

Very useful indeed, I now see L1 for each cpu core and L2 shared ...

Last edited by Massi on 01-Mar-2015 at 02:32 PM.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1