Welcome, Guest. Please login or register.

Author Topic: Arix  (Read 26292 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: Arix
« Reply #89 on: November 20, 2013, 05:52:54 PM »
Quote from: OlafS3;753156
that depends on the definition of "SMP design".


The definition of SMP is actually a quite clear. ;)

Quote
It already uses more than one core on system level and they are obviously evaluating ways to use it in other cases.


AMP/ASMP is not SMP though...

Quote
SMP for applications is still in testing/development ("silly SMP") and I think Jason mentioned that it would need 6 months to implement. But it will come do not worry :-)


"Silly-SMP" is just what the name suggest: Silly! It's may be a fun/interesting test or experiment, but even if it will be finished I doubt it will ever be used for real, it simply makes no sense. SMP breaks Amiga, it simply can not exist in an Amiga context without breaking the compatibility. And if you will break the compatibility you would be much better off implementing a *proper* SMP instead. So putting effort into this is indeed silly. ;)
MorphOS is Amiga done right! :)
 

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: Arix
« Reply #90 on: November 20, 2013, 06:01:53 PM »
Quote from: Iggy;753170
So folk, our first support for multiple cores.


PowerUP was "our" first support for multiple cores (more than one and a half decade ago)! ;)

Quote
And if you expect more than ASMP out of Amiga OS 4.2 you might be too optimistic.


Actually, I think you might be too optimistic if you expect OS 4.2 at all (;)), but given what has been said about "Kernel X" or whatever they call it, it actually aims for SMP.
MorphOS is Amiga done right! :)
 

Offline OlafS3

Re: Arix
« Reply #91 on: November 20, 2013, 06:03:36 PM »
Perhaps they are better than the Aros devs, who knows...
 

Offline nicholas

Re: Arix
« Reply #92 on: November 20, 2013, 06:28:10 PM »
Quote from: OlafS3;753176
Perhaps they are better than the Aros devs, who knows...

Stop it you're killing me! :roflmao:
“Een rezhim-i eshghalgar-i Quds bayad az sahneh-i ruzgar mahv shaved.” - Imam Ayatollah Sayyed  Ruhollah Khomeini
 

Offline Iggy

  • Hero Member
  • *****
  • Join Date: Aug 2009
  • Posts: 5348
    • Show only replies by Iggy
Re: Arix
« Reply #93 on: November 21, 2013, 12:15:22 AM »
Quote from: takemehomegrandma;753175
PowerUP was "our" first support for multiple cores (more than one and a half decade ago)! ;)

Not really, those boards don't work that well when using both processor concurrently.

And if we really want to go out there, then all systems with intelligent support chips are multi-processor system.
So does that make an Atari 8biy system with an Antic chip multi-processor?
"Not making any hard and fast rules means that the moderators can use their good judgment in moderation, and we think the results speak for themselves." - Amiga.org, terms of service

"You, got to stem the evil tide, and keep it on the the inside" - Rogers Waters

"God was never on your side" - Lemmy

Amiga! "Our appeal has become more selective"
 

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: Arix
« Reply #94 on: November 21, 2013, 09:57:33 AM »
@OlafS3

Quote from: OlafS3;753176
Perhaps they are better than the Aros devs, who knows...

Who knows, but it doesn't matter; anyone with enough low-level knowledge to make an Operating System from scratch in the first place, can probably create a proper SMP scheduler with the required API to make a proper, multithreaded SMP OS. Much research has been done in this area and much theory and many models about this exist, so evaluate them, choose one, and implement it to the best of your ability. But that was obviously not my point. I never commented on neither the AROS nor the OS4 developers ability to create a SMP OS.

The point is that you could have one of two ambitions/objectives with your "Amiga" OS:
  • Retain the Amiga compatibility (SMP *impossible*, 31-bit memory space, etc)
  • Break the Amiga compatibility (SMP possible, 64-bit, along with a lot of other stuff)

ARIX seems to be about the first option (quotes from the AW.net thread):
  • "It's not an SMP design, rather similar to AMP"
  • "the API is AROS [Read: Amiga]. You can in principle run all AROS software on ARIX"
  • "Yes, without recompiling"
[/I]
Hyperion's "X Kernel" on the other hand is definitely Option 2, thus "inverting" the three bullet points above; "It's a SMP design, the API won't be (legacy)Amiga, you can't run all OS4/Amiga software on 'X Kernel', not without recompiling, including 'fixing' any legacy dependencies and modifying to become as multithreaded/parallel as possible". (BTW, the OS4 "team lead", ssolie, has said he wants to merge the "Exec SG" with "X Kernel" down the line, which of course was a rather amusing thing to say by someone in his position! :lol:)

Your comment...

   "SMP for applications is still in testing/development ("silly SMP") and I think Jason mentioned that it would need 6 months to implement. But it will come do not worry :-)"

...would mean a change in ambition/objective in ARIX from option 1 to option 2. There is no option "1.5", no sliding scale. Legacy compatibility will be lost, and programs will have to be recompiled (etc). It's just that "Silly-SMP" never had the ambition of being the very best (or even a good one at all for that matter) SMP implementation; it's entire point seems to have been an experiment to prove those wrong who claimed that "SMP can't be done in Exec", and it does contains a lot of trade-offs to make it possible; "utilizing the extra cores to *some* degree, is better than nothing, even if being far from optimal or what's actually possible in other models". It may indeed prove those people wrong (we'll see if it gets that far), but "Silly-SMP" does *not* however prove those wrong who claims that "SMP can't be done in an Amiga legacy compatible environment" (and it can't!), so if the ARIX people would indeed change their mind, and opt for Option 2 instead later on, it would be quite silly to use "Silly-SMP" instead of a better, established and tried model.

That was my point.

:)
MorphOS is Amiga done right! :)
 

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show only replies by vidarh
Re: Arix
« Reply #95 on: November 21, 2013, 01:07:53 PM »
Quote from: takemehomegrandma;753205

...would mean a change in ambition/objective in ARIX from option 1 to option 2. There is no option "1.5", no sliding scale. Legacy compatibility will be lost, and programs will have to be recompiled (etc). It's just that "Silly-SMP" never had the ambition of being the very best (or even a good one at all for that matter) SMP implementation; it's entire point seems to have been an experiment to prove those wrong who claimed that "SMP can't be done in Exec", and it does contains a lot of trade-offs to make it possible; "utilizing the extra cores to *some* degree, is better than nothing, even if being far from optimal or what's actually possible in other models". It may indeed prove those people wrong (we'll see if it gets that far), but "Silly-SMP" does *not* however prove those wrong who claims that "SMP can't be done in an Amiga legacy compatible environment" (and it can't!), so if the ARIX people would indeed change their mind, and opt for Option 2 instead later on, it would be quite silly to use "Silly-SMP" instead of a better, established and tried model.


I seel "Silly-SMP" as an exercise in 1) seeing how far you can get *while* retaining compatibility, and 2) exposing what code actually needs to be fixed.

A lot of the "SMP is impossible" whining in these discussions is based on a "worst case" scenario where Amiga applications runs rampant all over memory and uses every dirty trick in the book all the time *and can't be fixed*.

But here's the thing:

We have a very limited software catalogue. Even on classic. *Most* of those applications are going to interact with the OS in ways that breaks simple approaches to SMP in very limited ways, that can either be worked around, or patched.

Some are going to be very problematic, and you then have a few alternatives: Fix them, especially if you have the source; add hacks to work around them (up to and including "blacklisting" these applications and cause the OS to do nasty hacks when they run, up to and including sandboxing them in some way or another); or accept that they never will work outside of emulation or with SMP turned off.

But the thing is: We don't really *know*. We do know that cache coherency will be an issue for anything that tries to meddle with system structures. We do know that frequent Forbid()/Permit() would be a problem, especially if we're forced to forbid across all cores and flush caches. But we don't have accurate measures of how much software is affected how badly.

It is possible the best approach is to sandbox all old apps in an emulator and let them continue running on a single CPU, and bridge various things to the host OS. Or it is possible the problem is limited enough to work around and/or patch the offending applications for a new OS version.

The only way of really finding that out is to experiment.
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: Arix
« Reply #96 on: November 21, 2013, 01:38:05 PM »
Quote from: vidarh;753210

The only way of really finding that out is to experiment.


Which is what AROS and silly SMP is all about... The nature of the projects allows all option to be tried and then the optimal (I.E. Least worst) option chosen.

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show only replies by vidarh
Re: Arix
« Reply #97 on: November 21, 2013, 03:50:32 PM »
Quote from: bloodline;753212
Which is what AROS and silly SMP is all about... The nature of the projects allows all option to be tried and then the optimal (I.E. Least worst) option chosen.


Exactly. I was very happy to see that experimentation finally start - I've long been firmly of the opinion that it's not going to be nearly as bad as some think, exactly because our software base is as small as it is, and the base of software that people actually expect to be able to use on the next-gen systems on modern hardware outside of emulation sandboxes like UAE is much smaller still. But these experiments finally gives us a chance to find out who is right :D
 

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: Arix
« Reply #98 on: November 21, 2013, 04:24:28 PM »
Quote from: vidarh;753210
I seel "Silly-SMP" as an exercise in 1) seeing how far you can get *while* retaining compatibility

No exercise needed to see that it won't be neither binary compatible (had it been running on AROS 68k on non-existent dual CPU 68k HW), and it won't be source code compatible to anything and everything written for AmigaOS3.x either. You would be required to not only recompile the applications, but also adapt the sources (more or less, depending on the app in question).

Have a look at this post in particular, and threads like this and this in general, and you will see that:
1) Full Amiga legacy compatibility is *impossible* to begin with  
2) and *on top of that* there are lots of hurdles to overcome and performance penalties to pay, if you *persist* in going this way despite the fact that you have already broken compatibility and a rebuild of the SW base will be required anyway (hence an opportunity to introduce a SMP model that is more *real world tried* and less "silly").

Quote
2) exposing what code actually needs to be fixed.

What you can "fix" is to overcome as many of the hurdles as possible and trying to make performance as good as possible. This is what real life testing/developing of this concept can provide. But per concept (visible in the first link above), no "code fixes" can make this fully Amiga compatible.

Quote
A lot of the "SMP is impossible" whining in these discussions

Oh please, this is not "whining". Amiga can't be SMP, per design, per concept.

Quote
is based on a "worst case" scenario where Amiga applications runs rampant all over memory and uses every dirty trick in the book all the time *and can't be fixed*.

But here's the thing:

We have a very limited software catalogue. Even on classic. *Most* of those applications are going to interact with the OS in ways that breaks simple approaches to SMP in very limited ways, that can either be worked around, or patched.

Some are going to be very problematic, and you then have a few alternatives: Fix them, especially if you have the source; add hacks to work around them (up to and including "blacklisting" these applications and cause the OS to do nasty hacks when they run, up to and including sandboxing them in some way or another); or accept that they never will work outside of emulation or with SMP turned off.

But the thing is: We don't really *know*. We do know that cache coherency will be an issue for anything that tries to meddle with system structures. We do know that frequent Forbid()/Permit() would be a problem, especially if we're forced to forbid across all cores and flush caches. But we don't have accurate measures of how much software is affected how badly.

No, no, no, either it's 100% compatible, or it's NOT! There is *nothing* in between! It's purely digital, either 1 or 0, it's either fully black or fully white. Purposely building an OS that sits in the grey scale between black and white will mean that its applications will be running in a mine field; Some may perhaps run, some longer than others, but there are no guarantees whatsoever. This is simply not serious, it would be a joke, and any OS developer who thinks that "less than 100% compatibility/stability" is OK and actually something to *aim for*, shouldn't be taken seriously as well!

That doesn't mean that "Silly-SMP" isn't a cool thing or an interesting experiment. Which is its purpose AFAIK - being a research experiment. But it will never be a realistic or good way of bringing SMP to AROS/ARIX.

Quote
It is possible the best approach is to sandbox all old apps in an emulator and let them continue running on a single CPU, and bridge various things to the host OS.

It will be the *only* way to run legacy Amiga/AROS apps in a new, SMP enabled system. Like AROS already does with UAE. Old Amiga 68k binaries can run there, and existing/old AROS/Amiga sources can be compiled for it unchanged. The same will be for Hyperion's "X Kernel", or when MorphOS goes "4.0". When the "NG OS's" goes "NG 2" and introduces things like SMP, 64-bit, etc, this is simply the way it has to be.

But this is slightly off topic in this thread anyway, since apparently, ARIX will not be SMP!
MorphOS is Amiga done right! :)
 

Offline bloodline

  • Master Sock Abuser
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 12113
    • Show only replies by bloodline
    • http://www.troubled-mind.com
Re: Arix
« Reply #99 on: November 21, 2013, 05:18:17 PM »
Quote
But this is slightly off topic in this thread anyway, since apparently, ARIX will not be SMP!


ARIX isn't SMP at a user level, that's is not to say it can't be in future.

SMP certainly isn't impossible in the AmigaOS design, the problem is that is SMP will almost certainly be slower than just using a single processor due to the original design decisions :)

Offline takemehomegrandma

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2990
    • Show only replies by takemehomegrandma
Re: Arix
« Reply #100 on: November 21, 2013, 05:58:53 PM »
Quote from: bloodline;753234
ARIX isn't SMP at a user level, that's is not to say it can't be in future.

And just like it will be for MorphOS and OS4 if/when they make this "NG 2" transition, it will mark a clear line between "before" and "after". It's nothing you sneak in in an afternoon and nobody will notice. The existing SW base will either have to be adapted and rebuilt for the "NG 2" with SMP, 64-bit, etc, or run in a sandbox (like UAE for example).

Maybe this isn't as dramatic for AROS/ARIX as it will be for OS4 and MorphOS, since the latter two have always had a fundamental focus on Amiga compatibility, not only source level compatibility, but also binary compatibility (which has been a central part). AROS on the other hand has always had a different view on compatibility issues (since it has mainly lived on other archs than 68k and never had a native 68k binary translator), where Amiga apps have always had to be either recompiled, or run in an emulator.

Quote
SMP certainly isn't impossible in the AmigaOS design

It certainly IS impossible if compatibility is a requirement.

If not, then sure...

:)
« Last Edit: November 21, 2013, 06:46:28 PM by takemehomegrandma »
MorphOS is Amiga done right! :)
 

Offline slaapliedje

  • Lifetime Member
  • Hero Member
  • *****
  • Join Date: Oct 2010
  • Posts: 843
  • Country: 00
  • Thanked: 1 times
    • Show only replies by slaapliedje
Re: Arix
« Reply #101 on: November 22, 2013, 03:40:19 AM »
I'll admit, I'm not a low level OS designer, but I recall the times when Linux was first adding SMP support, and a lot of the discussions on that.

But what truly is standing in the way of AmigaOS to using SMP?  The OS level scheduler should be able to determine if an application is multi-threaded and should use the cpus concurrently, or if it's just a single core application and run it that way.  

I recall even Quake (2?) had initial multi-core support that you could enable with a configuration change, but it wasn't really optimized and indeed ran slower.

A good example under Linux is where older versions of Asterisks are single threaded (not too sure if they changed that in newer releases) and will only ever utilize one core.  But software like apache will certainly take advantage of a multicore system.  

I always thought it'd be kind of cool to be able to right-click an icon and select "use all cores"  :D  You could even do some mad multitasking if you had a dual-core Amiga and just had the OS use one CPU and all applications use the second.

But as I said, I don't know what the technical barriers of AmigaOS and SMP there are, and why it is impossible.  I wouldn't even think that most applications would realize there were a second core to use, and it'd just work on the one.  

Now if it's due to the memory protection bits, then I could see multi-core processors being an issue, but a dual-processor setup could work, with different memory blocks available.

slaapliedje
A4000D: Mediator 4000Di; Voodoo 3, ZorRAM 128MB, 10/100mb Ethernet, Spider 2. Cyberstorm PPC 060/50 604e/420.
 

Offline haywirepc

  • Hero Member
  • *****
  • Join Date: Sep 2009
  • Posts: 1331
    • Show only replies by haywirepc
Re: Arix
« Reply #102 on: November 22, 2013, 04:49:06 AM »
I recall the smp debates on linux also...

Some people may be right in that 68k and NG1 apps must be sandboxed going forward...

I don't really know, but I agree that the software base for NG1 apps is not so huge... so recompile them with a few changes to work, or sandbox them if necessary. 68k apps already run in emulator on aros so why not progress to NG2?

8 core machines are becoming more common. 12 and 16 core machines will be common soon enough. We can all sit with our heads in the sand and ignore all that power, or we can learn to use it...

I'd go for using it...
 

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show only replies by vidarh
Re: Arix
« Reply #103 on: November 22, 2013, 10:25:05 AM »
Quote from: takemehomegrandma;753224

Have a look at this post in particular, and threads like this and this in general, and you will see that:
1) Full Amiga legacy compatibility is *impossible* to begin with  
2) and *on top of that* there are lots of hurdles to overcome and performance penalties to pay, if you *persist* in going this way despite the fact that you have already broken compatibility and a rebuild of the SW base will be required anyway (hence an opportunity to introduce a SMP model that is more *real world tried* and less "silly").


I *have* followed Jason's work, and you are massively overdramatising this.

It is fully possible to make AmigaOS SMP with *no* source changes. This is not the problem. The problem is making AmigaOS SMP in a way that scales efficiently to many cores. The "trivial" way of making AmigaOS fully SMP is to memory protect all shared structures, make Forbid() etc. work across all cores, and brutally enforce cache coherency - do that and you can create a system that is *provably* equivalent to a multi-tasking single-CPU system, in that you can in fact guarantee no *observable* differences to processes.

(In fact, you can further relax the above by using well researched approaches from database theory: By using the MMU to trigger page faults and pause processes that try to touch the same pages as the process that called Forbid(), you can create the *effect* of a system wide Forbid() while allowing processes that don't touch the "wrong" parts of the system to keep running)

The question then is what tradeoffs you need to make to get decent scalability across cores, and SillySMP has started to determine that.

For AROS this issue is massively simplified in that:

1) AFAIK there are nobody crazy enough to plan to try to build an m68k SMP machine to run AROS. As such "our" m68k apps are limited to running in UAE, possibly in coherence mode, which means that while the applications themselves may be "badly behaved" they have no direct access to AROS system structures - all access is mediated.

2) All other applications are compiled for AROS anyway.

"Amiga legacy" compatibility is thus "easy" for AROS: Make the UAE process handle SMP, for values of "handle SMP" that can worst case involve making the UAE processes only run on a single CPU and aggressively apply locking (though there is little reason why this needs to be the case).

A substantial percentage of applications compiled for AROS will require no source changes: Many of them never touch system structures in a way that will prove problematic even in an "optimal" SMP implementation. Many more can handle things fine with the approach that SillySMP takes.

For the ones that *do* need changes, most or all of those changes can be made in a way that is backwards compatible to plain AmigaOS (that is, we can write SMP safe applications in a way that we can ensure will continue to work if recompiled for non-SMP AmigaOS): We simply need more fine-grained locking, which can be provided in a way that'll either work on AmigaOS (but that would require you only run well behaved apps) or fall back on Forbid() on AmigaOS.

And in fact, as Jason pointed out in a couple of comments on the threads you pointed to, some of the "problematic" behaviour is *broken* on AmigaOS anyway, and just happens to "mostly work" by sheer luck. In fact, this may prove to be the biggest challenge.

Quote

No, no, no, either it's 100% compatible, or it's NOT! There is *nothing* in between! It's purely digital, either 1 or 0, it's either fully black or fully white.


I nominate this as the most ridiculous statement of the decade. Did you ever have a kickstart 1.2 machine and upgrade to 1.3? 2.0? 3.1? Each of those were an example of a "not 100% compatible" upgrade. Yet I'd expect few people here would argue they were not mostly compatible.

Quote

Purposely building an OS that sits in the grey scale between black and white will mean that its applications will be running in a mine field; Some may perhaps run, some longer than others, but there are no guarantees whatsoever. This is simply not serious, it would be a joke, and any OS developer who thinks that "less than 100% compatibility/stability" is OK and actually something to *aim for*, shouldn't be taken seriously as well!


You completely miss the point. The point is not that it is acceptable to run applications that randomly break, but that it is completely acceptable to say "ok, this will work fine for about 90% of applications, the rest *either must be sandboxed, must be fixed, or you can't run them*". The idea of 100% compatibility is a unicorn - it's a fantasy. And it's better to give up on the idea, and be pragmatic about it:

Our application base is small enough that for many types of changes, it is less effort to *test and verify* and *fix* or accept that some apps will not be usable outside of UAE than it is to obsess over a 100% compatibility that will forever hamper us. AROS is not identical to AmigaOS anyway: We *need* to test and verify every application on a regular basis to ensure that changes does not break apps that works fine on AmigaOS. And the same will be true for ARIX.

Every iteration of the actual AmigaOS left applications behind that were broken, and/or forced people to upgrade their applications for them to keep working too - this is nothing new. What is new is that for the NG OS's we have sandboxing as an "easy" alternative to keep those applications running if the effort to fix them is too great.
 

Offline nicholas

Re: Arix
« Reply #104 from previous page: November 22, 2013, 11:08:41 AM »
Quote
any OS developer who thinks that "less than 100% compatibility/stability" is OK and actually something to *aim for*, shouldn't be taken seriously as well!

You might want to rethink that statement as MorphOS isn't 100% compatible with Amiga software. ;)
“Een rezhim-i eshghalgar-i Quds bayad az sahneh-i ruzgar mahv shaved.” - Imam Ayatollah Sayyed  Ruhollah Khomeini