AROS World Exec
Development => Development (General) => Topic started by: trekiej on December 13, 2018, 01:08:12 AM
-
Hello, is there anything new in the AROS SMP area?
Looking to for some direction for 2019.
-
so far, no.
-
I think I would be happy to have a Raspberry Pi 3b+ with smp and all drivers.
-
Vampire will be out with SMP at some point. But they don't know if there will be an OS to use it.
I hope SMP AROS is out within a few months.
-
I think I would be happy to have a Raspberry Pi 3b+ with smp and all drivers.
That would be a brilliant little machine - fingers crossed this actually comes to pass in the new year.
Cheers,
Nigel.
-
@thread
Me too, come on 2019.
-
Could SMP 68K from AROS be patched in to proper Workbench / Kickstart?
That way Apollo could release an SMP Vampire, which they can do now but wont because Workbench / AROS do not support it.
-
@PurpleMelbourne
The current Kickstart replacement ROM images are large. It requires an extended ROM in addition to the basic Kickstart image.
Workbench is the AmigaOS trademark so ours is called Workbook. It also needs work. Wanderer is such a large Workbench replacement that it doesn't fit into the ROM which is why Workbook was written.
-
Can it all fit into a 4MB ROM?
Can you mix and match AROS files into the Official Kickstart and Workbench files?
I suppose the thing I'm most interested is getting past the existing hard limits imposed. So if we can have multi processing, weather it be SMP or asymmetrical MP, there are bonuses in different ways for each system. But no bonus while we are stuck with only one CPU which is not quite fast enough.
-
aros smp is is not compatible with m68k, it is ifdeffed since some structures had to be extended as such, if it was enabled for m68k it would reneder existing software unusable. we already had a subtle incompatibility because of missing (forgotten) padding when smp was first introduced. it didnt affect all of the m68k binaries, so it was not really easy to find.
what concerns aros kickstart form m68k it is currently 1mb and its not really clear to me if it can be reduced. we (toni) are currently working on it trying to enable debugging it with winuae. other than that it already works (or should work) on most amiga hardware. unfortunatelly it doesnt boot through with the vampire. i am testing it on a lent machine right now.
-
Are you worried about the size of Kickstart going beyond 1MB? With the right EPROM (23C4096??) you can have a bigger Kickstart of 2 or maybe 4MB split over two chips in A1200, A3000 and A4000. I'm not sure about the other ones. Maybe with a bigger eeprom you can also give them a bigger kickstart.
What is the chance of NON-SMP asymetrical multi processing? LIke using extra 68k cores as co-processors or something? It would be great if you could have a Vampire with a separate core for ShapeShifter for example. So even if most (all?) Amiga software is not multi-threaded to span multiple cores, at least there would be tricks to push different tasks to different cores?
And future software such as Firefox on Amiga could be multithreaded enough to be able to run if one CPU is not fast enough.
-
Once the RPi port can be used, it would be good to see AROS make better use of that hardware, the latest model is quad core. While I like my A3000 and want to run AROS on it, I think the RPi and other small ARM based boards can be a more interesting future. Not that I would object if anyone would make proper 68k based CPUs and machines again, not at all.
-
The irony of wanting to UPGRADE to a Raspberry Pi level CPU!
The ARM SPC's do look pretty good. I've been paying attention to the Rockchip RK3399 based versions.
With Apollo bringing out out the new 68080 on FPGA, there is a chance for enhanced hardware to host OS enhancements. If AROS simultaneously begins establishing itself as a significant choice on the Raspberry Pi as the enhancements upon expanded Commodore Amiga's coalesce then the foundation that is known as Amiga can be moving forward nicely.
Raspberry Pi AROS could be an important bridging platform for the Amiga as the Operating System moves onto ARM cores. Fingers crossed for the future :-)
-
From what I understood the Vampire is a FPGA board where one CPU must do everything. No custom shipsets like Amiga had.
In that scence the Pi is more Amiga like. So much is done with the GPU these days. Video, 3D, 2D.
SMP is very difficult without breaking everything. It is still possibly a good idea to fork AROS and have a version people can play with on top of the classic version. It is what Mschulz is doing. I'm quite sure he got it right. I'm more unsure about where a forked AROS version is going. Just look at Haiku and how many years that OS been in development without any success. Where does a new OS fit inn and how long are people going to wait for it to be usable.
AROS just recently, with the right hardware became a stable, good OS.
Personaly and at least for now I like the x86 series. Still with single core that CPU is very powerfull. write or port some drivers for some powerfull GPU and we would have a system that would fly. I'm even happy with my Latitude D520. With 2 GHz Core2Duo CPU and at least good 2D accelleration I enjoy it. 3D chip is quite weak but still good to play some of the older 3D games like Quake III in lower resolutions.
There are no arm CPU today that could touch even a Core2Duo CPU running single core, maybe in the future. The GPU in Pi is way more powerfull than the IntelGMA GPU in my laptop. Let's see if there ever will be a native drivers for Pi GPU running AROS. Problem might be with next Pi new GPU would need new drivers.
Look at Amiga, MorphOS and AROS. How many drivers do we got for different hardware. Not may. It is no easy task. The introduction of Nouveau, MESA solved lot's of that, at least for GPUs but not been updated in long time. It's been so long time that there are no Laptop made last 10 - 12 years that would work with it.
-
we (toni) are currently working on it trying to enable debugging it with winuae. other than that it already works (or should work) on most amiga hardware. unfortunatelly it doesnt boot through with the vampire. i am testing it on a lent machine right now.
I saw your (Tonis) commits on the AROS-mirror from ezrec today. Thank you both very much! Keep up the good work!
-
From what I understood the Vampire is a FPGA board where one CPU must do everything. No custom shipsets like Amiga had.
In that scence the Pi is more Amiga like. So much is done with the GPU these days. Video, 3D, 2D.
SMP is very difficult without breaking everything. It is still possibly a good idea to fork AROS and have a version people can play with on top of the classic version. It is what Mschulz is doing. I'm quite sure he got it right. I'm more unsure about where a forked AROS version is going. Just look at Haiku and how many years that OS been in development without any success. Where does a new OS fit inn and how long are people going to wait for it to be usable.
AROS just recently, with the right hardware became a stable, good OS.
...
The copper, audio and bitplane DMA are still there in the Vampire. The blitter needs software emulation but that's mainly because the timing needs to go slow to run most old software. When it's running full speed on the second CPU thread it's roughly 200 times the speed of the original blitter. Also, Gunnar has said he's going to add 3D support to the v4 Vampire cards.
As for ARIX, its goal is to run AROS software on Linux drivers. It's a good fork for modern equipment. Once the modern hardware is running ARIX, AROS will be free to relapse into retrocomputing on the Amiga hardware.
Even so, it will be nice having both for their respective platforms.
-
From what I understood the Vampire is a FPGA board where one CPU must do everything. No custom shipsets like Amiga had.
In that scence the Pi is more Amiga like. So much is done with the GPU these days. Video, 3D, 2D.
SMP is very difficult without breaking everything. It is still possibly a good idea to fork AROS and have a version people can play with on top of the classic version. It is what Mschulz is doing. I'm quite sure he got it right. I'm more unsure about where a forked AROS version is going. Just look at Haiku and how many years that OS been in development without any success. Where does a new OS fit inn and how long are people going to wait for it to be usable.
AROS just recently, with the right hardware became a stable, good OS.
...
The copper, audio and bitplane DMA are still there in the Vampire. The blitter needs software emulation but that's mainly because the timing needs to go slow to run most old software. When it's running full speed on the second CPU thread it's roughly 200 times the speed of the original blitter. Also, Gunnar has said he's going to add 3D support to the v4 Vampire cards.
As for ARIX, its goal is to run AROS software on Linux drivers. It's a good fork for modern equipment. Once the modern hardware is running ARIX, AROS will be free to relapse into retrocomputing on the Amiga hardware.
Even so, it will be nice having both for their respective platforms.
For ARIX you are wrong. The original idea was that but that is not what Mschulz is doing now. AROS software will not run on it.
How is Gunnar going to add 3D support? Is there expansion slot for GPU or is he doing some fpga 3D on other core?
Audio today is almost no task for main CPU. It is the GPU that is important.
-
The "Polly" core is the polygon plotter on the bigger v4 Vampire. It still runs on the FPGA.
-
If I understood correctly, Arix allows Linux to be programmed in an Amiga or Aros way.
Could someone tell me how many different programming languages are there for Aros SMP or is Pascal available for SMP?
-
Could someone tell me how many different programming languages are there for Aros SMP or is Pascal available for SMP?
SMP is something that the kernel/scheduler has to support. In that regards it has nothing to do with the programming language (whatever programming language that would be).
As long as the API exposes things like creating threads/task then it can be used by any programming language.
Depending on the SMP implementation that is not even necessary in case the scheduler takes care of things automatically (e.g. new threads/task are distributed (evenly) automatically).
Creating multithreading applications with Pascal even when thread support was not implemented was already possible because the Amiga/AROS API exposes functionality for that. At this day the Pascal threading model is supported for Amiga/AROS so that you would not have to deal with those API calls yourself.
Free Pascal is available for 64-bit AROS and afaik that also means for SMP enabled version of AROS. Make sure to verify with ALB42 in case you need to be sure.
But, in all fairness. All talk about using multiple threads is wonderful but in practise it is much harder to actually make use of it (correctly). I dare to say that almost (or even more of) 90% of end-user applications have no use for running on multiple cores/threads whatsoever.
In relation to your interrest with regards to rendering: yes, for such (specific) tasks it matters if you are able to utilize all processors/cores :)
-
So, when does a program get turned into threads?
I would like to see Povray 3.7 ported to Aros SMP.
It is multi-threaded.
-
So, when does a program get turned into threads?
Well, that was kind of the point i was trying to make :)
A program doesn't "get turned into threads" automatically. Instead the developer has to design the application (upfront) in such a way that it is able to utilize threads (efficiently).
And in some programs that can be or are programmed in a linear fashion, it makes no sense whatsoever to make use of threads. Sure such programs can still make use of threads but it sometimes simply doesn't make any sense (other then being a lazy programmer/developer).
Consider the following simple example (bear with me as the example itself make no sense whatsoever):
x = 0
for n = 1 to 100
x = x + 1
next n
Simple enough: a variable x get increased by one on every iteration of the for next loop. For example sake let say that every loop iteration (and corresponding addition of 1 to the variable x) costs 1 second of time.
That will amount for this program to take at least 100 seconds to finish.
Using threads is about running things in parrallel so that multiple threads/cores can be used to process the code. That way (in theory) you should be able to rewrite the exampe to use (again for argument sake let ay you have that many) 100 threads/cores at the same time. That way it should take 1 second for 100 iterations as all 100 are executed at exactly the same time (and processed by the CPU).
oversimplified example:
// thread code:
x = 0
for n = 1 to 100
StartThread(AddOne)
next
AddOne:
x = x + 1
return
Taking into account that a (single global) variable can not be acccessed by all 100 threads/cores at the same time (that is a design principle of using multiple threads) and that you have to create a 100 different threads, this will add so much overhead that in the end your program will not end up finishing in 1 second, rather in 200 seconds (because of the extra overhead of creation and destruction of the threads).
So, programs like povray are designed in such a way that they (efficiently) make use of threads. It is a bit out of scope to get into detail what exact portions/calculations are eligable to turn into threads but i hope the gist of it is a bit more clear for you now.
Furthermore (in case you wondered), there are different kernels that implement their own threading model, each with their own set of API calls. AROS/Amiga is not 100% compatible to support all thread API used by povray (or any program written for another platform and that makes use of threads for that matter), so that sometimes poses a problem for (easily) making a port for Amiga/AROS.
For instance the initial threading implementation used by Free Pascal was based on the version implemented by Delphi. But alas, Free Pascal supports more platforms than Windows (and Linux) so the threading implementation had to obey certain basic rules that apply for all platforms that supports threads. Therefor a lot of bad design stuff (like stopping and resuming threads) is highly discouraged and isn't officially supported anymore.
And that is ok, because you can always use your platform specific API calls in case you do wish to support functionality that's missing from Free Pascal's native threading implementation/solution (in case you really can't live without)
-
I heard that BeOS could make all its programs multi-threaded automatically.
But.
A cube, for example, has 8 vertex that need to be calculated when Rotate, Scale, and Translation is performed.
Delta Radian, Delta Size, Delta Position is placed on it.
I hear that a Ray Tracer is not hard to program. Configuring the block size before the Enter button is pressed would necessary.
-
I heard that BeOS could make all its programs multi-threaded automatically.
No idea but sounds like a fairy-tale to me. BeOS is even more dead than AROS and its sources are closed so i am unable to verify. If you are able then please provide a link so i'm able to educate myself.
I hear that a Ray Tracer is not hard to program. Configuring the block size before the Enter button is pressed would necessary.
Oh, i would have no idea (https://blog.alb42.de/2017/03/08/more-3d-stuff), but perhaps ALB does (https://blog.alb42.de/2017/03/07/raytracing-again) ;) Also nice is physics (https://blog.alb42.de/2017/06/22/kraft-physics-engine).
Free Pascal for AROS is ready..... even for SMP .... so ... what was it that is keeping you from writing software ? :)
-
I have 3 books that I have been studying. One is Pascal for Basic programmers, the second is Introduction to Computing with Pascal, and the third Data Structures with Pascal.
I bought Turbo Pascal(?) for Ms-dos from a community college a long time ago. It has books with it.
-
This (https://www.amazon.com/Pascal-Basic-Programmers-Charles-Seiter/dp/0317054023), this (https://www.amazon.com/Introduction-Computing-Pascal-Science-Publications/dp/0198537565) and this (https://www.amazon.com/Introduction-Data-Structures-Pascal-Thomas/dp/0314932070) books ?
Do note that judging by their age their are mostly (if not all) oriented at using Turbo Pascal (not even Borland Pascal) or using iso Pascal. These are dialects that can be compiled with Free Pascal however the world has moved on since then.
Some of the books you mentioned are pretty good at introducing you to the use of data structures and some elementary basics (for any programming language usage) but we have entered the world of OOP (Object Oriented Programming) ages ago. OOP is a bit more difficult topic to learn but makes life much easier (and more understandable even).
See also this online book for a quick introduction to modern Pascal (https://castle-engine.io/modern_pascal_introduction.html).
Advanced Records, Objects, Classes, Custom Operators, Helpers, Enumerators, Generics, etc. are things that are more used in this day and age and you won't be able to read about in forementioned books.
Do note that having a understanding of the basics like written in the books you mentioned is a very good place to start. If there are any example code listed with those books then just play with those in case you get bored with the explanations. By doing things most people tend to have a better idea on what is actually going on, the absolute worse that can happen is that you crash your OS (but (Free)Pascal is a language that is pretty good at attempting to prevent you from doing so but be warned for this to happen when working with pointers.... most programmers have brought down their OS with those :D )
Ah well, if you have questions then you know where to ask ;)
-
Correct except for the third one. The author is Horowitz and Sahni.
I have had an introduction to C and C++. Also I have had an introduction to COBOL and Assembly Language.
Edit:
I have worked with pointers some in C.
-
Correct except for the third one. The author is Horowitz and Sahni.
Ah, ok. i seem to remember having read that book back in the day (one of the earlier editions though). Thanks for the correction.
I have had an introduction to C and C++. Also I have had an introduction to COBOL and Assembly Language.
Edit:
I have worked with pointers some in C.
Ok, that is good to know. I initially thought you had no experience at all other then some tinkering with your Amiga/AROS box (scripting and such).
COBOL ? Then you either are much older then i gave you credit for (in which case respect) , have a very boring job or have a prety peculiar hobby :)
I'm biased when it comes to advocating Pascal but the step from COBOL to Pascal shouldn't be too awkward even though COBOL has a completely other purpose for its existance.
C can be much more cryptic in that regards even though the same can be said about Pascal if you put some effort into it. Personally i generally just dislike the output that c compilers produce (and with that i meant the error reporting as that seems to require a study on its own in order to be able to interpret correctly).
Having some knowledge on Assembly is always a good thing as that really throws you back to bare basic instructions. Also allows you to appreciate programming languages better (at least some of them :D ) If you have more affinity with assembly then c might perhaps be more interresting for you.
But.. we're getting waaay off-topic here. Feel free to start another thread in case you wish to have some chit-chat about your endeavours and in case i don't bore you to death with my ramblings :)
-
I heard that BeOS could make all its programs multi-threaded automatically.
I don't think that is correct.
Haiku is the BeOS equivalent of AROS. The original BeOS went to Palm (as in PalmPilot) then to HP, then to LG and now it is on LG televisions as WebOS. So its still around, but as a smart TV control system. But Haiku is still on the Desktop and looks good.
What I've seen of comments is talking about a good Be style program as having lots of threads. They weren't put there automatically. Good programmers following the guidelines make them very multi-threaded so that OS can split them efficiently over the CPU cores. But its not automatic.
BTW I think that everything good about Haiku could be added into Amiga too :)
-
Unfortunately, I have never been a Pro. Programmer.
Cobol was done in clas back in Fall 2004, Assembly as well.
C was in 2002.
I need to start a blog for this.
I do have a blog, it is about my A1000 ROM switcher board.
Thanks again, I hope to hit the books more soon. I have two classes coming up this Spring.
After that back to math classes and teacher cert. classes.
-
I still have the Be Book, maybe I read it in there.
It could have been from some web site.
I do have R3 and R5 Pro. Sad, I got rid of two Macs that could have had BeOS installed on them.
-
A bit off topic, but...
If you are into assembly language, then C is a good choice once you get a hang of it. C is essentially a processor independent assembler. Meaning, you will have a good grasp of what your "high level" code actually means in assembly instructions, but you do not need to bother about keeping track of registers as the C compiler does it for you.
If you study the code generated without optimizations enabled, you should get a good grasp of what is going on. If you then let a good optimizer do its work, you will probably have a harder time understanding how it can change it so much, and you will probably appreciate the work it does.
If you want to take the C route, "Expert C programming - Deep C secrets" is a good second book. It is written by a compiler engineer at Sun.
Pascal is a language in the same family, essentially the same thing with a bit different syntax (ducking).
-
;D
8)
-
Thumbs up for your take on c/assembly
...
Pascal is a language in the same family, essentially the same thing with a bit different syntax (ducking).
Can't have that ill comparison ... better start fleeing instead of ducking :P
But yes, essentially there is no difference. Ugly c can litterally be ported to even so ugly Pascal code (and vice verse)
C is close to assembly and that is a pro when you are into that. The pro of Pascal is that it can be much easier to read and is more oriented at preventing you from making mistakes (although modern c compiler settings can be very strict as well). It is a bit difficult to advocate Pascal as AROS itself is written in C (so if AROS system development is your goal then certainly choose c) but if you are new or only hobby programmer making small tools and/or end-user applications then i find Pascal much more friendly (the faster compile time is a pro for newbies).
-
Unfortunately, I have never been a Pro. Programmer.
It actually doesn't really matter. In case you are really struggling then perhaps an scripting language like hollywood might be the better choice (also much more users available).
Cobol was done in clas back in Fall 2004, Assembly as well.
I'm not very experienced with COBOL (and it was ages ago), but i've read that there is Objects in newer COBOL dialects. Have you perhaps got experience with that as well ?
I need to start a blog for this.
For sure it can help put your thoughts in order and at the same time allows for some feedback (in case someone is following your blog). As an alternative feel free to start your own dedicated thread on any of the boards (preferably here of course :) ) and share your experiences with others.
After that back to math classes and teacher cert. classes.
You are getting your certificates to become a teacher ? nice ! i wish you luck with that.
-
I still have the Be Book, maybe I read it in there.
It could have been from some web site.
I do have R3 and R5 Pro. Sad, I got rid of two Macs that could have had BeOS installed on them.
I just bought a cheesegrater PowerMac G5 dual 1.8 for $75 (about US$60). Its currently performing great service as a coffee table. But at some time in the future I plan to try AROS etc on it. You could probably get a second hand one too for putting BeOS or Haiku onto. I don't know if there is a PPC version of Haiku being maintained up to date. I think it might only be x86
-
I need to start a blog for this.
I do have a blog, it is about my A1000 ROM switcher board.
Cool :)
I just pulled an A1000 out of the barn (I literally stored it there like 10 years ago!) and plan to put a Vampire in it to make it better than my A4000 ;D
So if you talk about tinkering on the A1000 I for one would love to hear about it.
What I'd REALLY love to see is AROS on the Vampire making full use of the new Hyper-threading feature. If they can make that work, then perhaps they will upgrade the Vampire to have multi CPU cores like a BeOS machine.
Apparently there are problems at the moment. But if the Raspberry Pi multi core version works out, and the ARIX experiment works out... then perhaps we could have multi core ARIX on Amiga working with new software and an AROS VM "container" to run the software which wont like the changes (apparently 90% of existing software will break!). That would allow the Amiga to go multi-core in a way that Gunnar from Apollo explains is not currently viable for the Amiga due to breaking almost all software.
The Amiga is coming back. And the AROS team deserve a big thank you for all of us!
-
PurpleMelbourne: The Macs were 8500's, and one had a G3 cpu card. :(
I gave away a bunch of computers over the years.
Magorium: I am working to be a high school math teacher.
I also need to work with Mathematica, eventually. :(
Os work is out of the question. I guess I am looking to use programming to do simulation.
I would love to bring CUDA/Tesla to Aros.
I do not know how to make libraries yet.
-
Aros: I am looking for Aros 64 SMP on Raspberry Pi or some other low cost board with all the bells and whistles.
I hope to see it on AMD_64 too.
Amiga OS4.1: I hope to play games on it with the pass-through option that qemu will some day have. That is good for Aros too.
I think I can play games on it now. It is compositing that hinders for now, I think.
-
Magorium: I am working to be a high school math teacher.
Cool.
I also need to work with Mathematica, eventually. :(
The software from wolfram you meant ?
In that case you might find things like MUIPlot (https://blog.alb42.de/2018/11/13/muiplot-a-simple-function-plotter/) interresting as well (no comparison to Mathemetica of course, but still a nice program for Amiga/Aros users).
... and to get back on topic SMP stands for Symbolic Manipulation Program (computer algebra) so what were we talking about in this thread again ? :)
-
Lol, yes by Wolfram.
Going off to start a new thread.
-
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.
-
I wonder if it could happen during compilation.
-
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?
-
I don't know. scratching my head.
-
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.
-
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 (https://en.wikipedia.org/wiki/OpenMP). 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.
-
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.
-
Bump.
-
What is the issue here? Is there a question?
Making parallel programs usually takes programmer actions. There are 2-3 reasons for this. First you often need some kind of synchronization mechanism between the tasks, to synchronize/lock access to shared resources or communicate when something interesting (to other tasks) has occurred. This typically needs to be done manually by the programmer. The second reason is that the compiler or language is often not smart enough to figure out how to distribute parallel work as it does not understand the algorithm or "shape" of the problem. It usually takes a human to figure out where to apply parallelism, sometimes by gut feeling or by trial and measuring typical scenarios. This can be because there may be an initial start cost, and doing it many times when there are much fewer execution units will introduce unnecessary overhead. A third reason is that sometimes even in a parallel capable language, the program may need to be expressed in way that makes it possible to parallelize.
Locking and synchronization is typically done in imperative (and object oriented) programming. It is very error prone. If you say it is simple, you either have a very simple problem or do not know what you are talking about. As an example, I read about a couple of experts on this topic that wrote a program and they really knew their stuff. Still, they created a very hard to find problem that took a couple of years before it showed up (unfortunately I forgot where I read about it). At the time I was doing this kind of programming myself, and thought that I can do it. Perhaps I could because I did not find any problems, or maybe I did not stress it long enough. However, coming back to that code a year or two later and I could not wrap my head around it anymore. That has happened to me twice...
This is one reason why functional programming is gaining today, it makes it easier to utilize parallelism (and multi-core) in a safer way.
There are languages that are naturally parallel as well, they typically may have a model that can be translated to multi-process evaluation by its run-time. Still, the programmer may need to express the program in a way that works for it.
I remember trying this in a language called Parlog (which is a parallel variant of Prolog, a logic programming language). I had a lab problem that was tricky, figured out a way to solve it, only to be told that well it solved the problem, but it was not done in a parallel way. Back to drawing board...
Parallelism also comes up in operating systems, like AmigaOS and can be seen as a way to make it responsive and give a good flow. It allows for many things to happen at the "same" time.
When having few cores, a proper multi-tasking system and occasional use of in-application (programmer written) parallelism to improve responsiveness is often the best you can hope for. To gain performance on real parallelism you need many cores to make it really worthwhile.
To summarize, typically, it does not happen by itself in applications, the programmer often need to think about it and do things.
But I still do not know what we are looking for here..?
-
Thanks for sharing.
-
There are no arm CPU today that could touch even a Core2Duo CPU running single core, maybe in the future. The GPU in Pi is way more powerfull than the IntelGMA GPU in my laptop. Let's see if there ever will be a native drivers for Pi GPU running AROS. Problem might be with next Pi new GPU would need new drivers.
The best consumer ARM cores (like the Apple A12) are well into laptop CPU territory. The A12 is about on a par for single core performance with the last couple of generations of low voltage i3 and i5 and probably Haswell generation desktop i3 parts. Some of the server kit is even quicker. The picture is complicated a bit on Android/Linux because of Linus's resistance to non-x86 CPUs. But ARM designs have advanced hugely performance wise since around the time of the A15, and whatever they are like as a company, Apple's CPUs are just phenomenal.
As to the GPU getting a native driver. I wouldn't rule it out, the Pi foundation have been awesome at persuading Broadcom to publish open source documentation and dev resources for the Video Core IV in the first three generations, but I'm not sure that the same has been done for the latest model.