Author Topic: SMP Update?  (Read 1068 times)

dizzy

  • Newbie
  • *
  • Posts: 20
  • Karma: +0/-0
    • View Profile
Re: SMP Update?
« Reply #45 on: January 10, 2019, 06:22:39 AM »
If one wants program to be multi-threaded then it needs to be coded such a way that the program spawns sub tasks and gives them tasks to do. Most of AROS drivers spawn a handler task so in essence they are multi-threaded...

Even though a thread and a Amiga like task aren't equivalent they serve the same purpose and that is they allow the CPU to execute code. AROS and Amiga program environment are different to those that utilize memory protection e.g. Linux/Windows and how they perceive a thread.

It's up to the Kernel/Exec to schedule tasks among different cores. If one spawns subtask then they may or may not run simultaneous on different cores, I think they might be some flags to instruct the task to run only on certain core etc.   

magorium

  • Junior Member
  • **
  • Posts: 63
  • Karma: +0/-0
    • View Profile
Re: SMP Update?
« Reply #46 on: January 10, 2019, 11:00:58 AM »
If one wants program to be multi-threaded then it needs to be coded such a way that the program spawns sub tasks and gives them tasks to do. Most of AROS drivers spawn a handler task so in essence they are multi-threaded...
Perhaps that is where the misconception from trekiej originates from ?

Let's say for (a simplified) example i'm developing an application that plays video files. My application uses system libraries to decode the frames for me. The system library my application uses to decode those frames exposes this functionality for my application and is implemented in such a way that it decodes the frames using multiple threads.

Does that mean my application is now a multithreaded appplication ? Does that mean my application was "automatically" transformed into a multithreaded application ?

I would personally answer no to both of these questions because it was not the application itself that was 'transformed' into a mutlithreaded one rather the library that does it that way for the application.

On the other hand if i would say yes to either question then my answer would be that it was me the programmer who decided to make use of the library for which i knew it was dividing the workload between multiple threads/cores, and not the operating system that did it automagically for me.

I wonder if it could happen during compilation.
Uhm, i would see no other way than during compilation. But even then it is the programmer who decides how and when to make use of it.

There are special programming languages that were invented for developing/running code in parralllel (for you) so in that regards it can be considered as being done "automatically". But in that case it is still the developer who decides to use that programming language in the first place :)

On a sidenote, perhaps you can take a look at this OpenMP wiki article. Have a good look at the examples and see that it is (again) the programmer who is responsible for instructing the compiler to turn the code into something that uses multiple threads. The syntactic sugar for the preprocessor does not change that fact.

Also note that an operating system (its task scheduler) can choose to run an application on another thread/core as it so wishes, but that is not turning an application into a multithreaded one, rather an application that runs on a specifc thread/core. That are two distinct situations.

It's up to the Kernel/Exec to schedule tasks among different cores. If one spawns subtask then they may or may not run simultaneous on different cores, I think they might be some flags to instruct the task to run only on certain core etc.   
It should be the scheduler taking care of things, and imho which should even be able to toss tasks/threads around in case things get heated up. But afaik that requires another implementation. It really is out of my comfort-zone, so feel free to correct me on that.

For Windows for example you can choose to run your app into a different thread/core by setting the affinity. afaik for AROS you have to manually choose at which core to run the code. I would expect (i might be wrong there) that eventually the scheduler in AROS is able to figure out how to spread tasks automatically (and evenly) between cores/threads.

I would settle for having the OS (AROS) run at the one thread/core and applications in another (or multiple others). But i have no idea how much overhead that would cause and as such if it would make any sense. I have not experimented with it myself.
« Last Edit: January 10, 2019, 11:22:05 AM by magorium »

cdimauro

  • Newbie
  • *
  • Posts: 17
  • Karma: +0/-0
    • View Profile
Re: SMP Update?
« Reply #47 on: January 10, 2019, 10:01:11 PM »
I wonder if it could happen during compilation.
Only if the programmer instructs the compiler on how to "treat" particular piece(s) of the source.
I heard that BeOS could make all its programs multi-threaded automatically.
At most it's an urban legend: only programMERs can write multi-threaded code, and... manually. An o.s. cannot certainly do it, even automatically.
Isn't Crysis a prime example of this?

Crysis was specifically coded by programmers to use more threads/cores.