Welcome, Guest. Please login or register.

Author Topic: Arix  (Read 26289 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Arix
« on: November 18, 2013, 11:49:49 AM »
Quote from: wawrzon;752936
you can still have your aros hosted for free, whats your problem if someone proposes commercial fork?


As long as it mostly or entirely maintains application compatibility, I'm all for it. Though I hope these guys will keep contributing to the open source AROS too.

Consider what commercial Linux distributions have done for Linux. E.g. RedHat has made a huge amount of money on Linux, but they've also invested a lot of money in Linux by hiring core developers and releasing a lot of code back to the community (not that I expect ARIX to turn into a billion dollar company like Redhat did...).
 

Offline vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Arix
« Reply #1 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 vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Arix
« Reply #2 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 vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Arix
« Reply #3 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 vidarh

  • Sr. Member
  • ****
  • Join Date: Feb 2010
  • Posts: 409
    • Show all replies
Re: Arix
« Reply #4 on: November 22, 2013, 04:40:51 PM »
Quote from: takemehomegrandma;753272
@vidarh

Well then, this sounds like a plan! Go ahead! :)



Ironically, I'm busy fixing compatibility issues right now.  (Between AROS network includes and POSIX requirements...)