@billt

Quote:

Would something outside of a multicore CPU not be slower than something inside that multicore CPU?

GPUs are outside of CPUs. So you have a graphics card with 2GB RAM onboard. And let's say the only way to get data to that card is through a CPU and a high speed multibus (PCIe4 x16). As long as the CPU and the bus are faster then the GPU is displaying data the card RAM will always be full and signal the CPU when it needs more data. The same could be true for sound.

Of course the same CPUs could allow DMA through scheduling and let the peripherals use the bus to load or stream its own data instead of everything going through a single CPU.

What would be your idea for a multi processor system that is not SMP?

_________________
Tinkering with computers.

@billt

Quote:

Would something outside of a multicore CPU not be slower than something inside that multicore CPU?

Pure speed of computing power is independent from the place where it does sit in the system.

Modern GPUs are real processing monsters, that's the reason why some crypto-coin miners are using GPUs for their work. There are also some standardised interfaces like OpenCL for programming the GPUs of such powerful cards.

Wikipedia about OpenCL: https://en.wikipedia.org/wiki/OpenCL

OpenCL could do much more than the poor old copper did, but the usage of OpenCL is only useful when most of the calculation is done in the GFX card.

@Signal

Quote:

GPUs are outside of CPUs. So you have a graphics card with 2GB RAM onboard. And let's say the only way to get data to that card is through a CPU and a high speed multibus (PCIe4 x16).

GPU on the PCI (PCIe) bus acts as a bus master and initiates the transfers itself, without involving the main CPU. The same applies to SATA, sound, network and almost every single peripheral.

Yes, modern PCs are, from this point of view, just what classic amigas were - bunch of independent peripherals glued together through a DMA (PCIe) bus.

@Signal

Are those GPUs in charge of what is happening inside the CPU? Are the GPUs doing their own application scheduling?

Your description sounds like the OS on the CPU sent stuff to the GPU to do, and is waiting for the GPU to interrupt the CPU to handle results and perhaps provide more input or commands. That still sounds like stuff running in the CPU to he in charge of everything, be it the OS or a Cuda-alike framework (openCL or openMP?)...

The OS should know everything about the system, and thus the most beneficial resource to use for a thread or task. Maybe that is the GPU, maybe that is a DSP, maybe that is a CPU core, maybe it is something else. But the OS on the CPU is what I see as the controller of it all, not something outside.

In Classic Amigas, the programmer may have more direct dictatorship of what happens where, such as if he chooses to make the blitter do some blitting, or the copper do some coppering, or Paula to do some Paulaing, etc... That's not so system friendly, and there are APIs involved now to help decide, such as P96 or CGX, both mostly compatible with the other and things get to the GPU in a correct manner, regardless of the chip, and programmer doesn't know or care how to poke registers in the GPU itself.

But, as seems to have been indicated in original post, the host scheduler is not in the GPU or in Paula or n the bus adapter, it is first in the kernel, then perhaps in some addon library to enhance what is not in the kernel, but still software on the CPU is the controller of all...

_________________
All glory to the Hypnotoad!

Great video about new tech for spreading single core software across multicore CPU's. Very interesting. Huge speed increases without having to redesign for software for mulicore architectures.
https://www.youtube.com/watch?v=XW_h4KFr9js

@billt

Quote:

But the OS on the CPU is what I see as the controller of it all, not something outside.

Yes, but what if the OS CPU were outside of the multicore processor?
If the CPU could assign slices of the multicore to do various functions and reassign what each core would be doing depending on load or priority.

Perhaps each core could be loaded with portions of the OS and then be able to run that code and only have to deal with bus contention and directives from the outside CPU.(?)

@wiser3
Good find. Very interesting. Thanks.

_________________
Tinkering with computers.

@wiser3
It's funny reading some of the sources linked in the video description: Intel claiming we would have 70nm 10GHz processors in 2005 using EUV lithography, now 14 years later we have the first manufacturer starting to use EUV at a 7nm process in risk production - with real production starting in 2020 = 15 years later. :)

After watching the video (at 2x the speed - still far too slow) there is no mention of new technology that will automatically parallelize software? VISC claimed some nice things but didn't mention that increasing IPC at 500MHz is much easier than 4GHz and that 4GHz makes more things faster by avoiding the bottlenecks of a slower (in frequency) processor. The "AI" load balancer is just that and while it may improve performance it'll not allow a single thread to be run on multiple cores.

Not that have much to do with Amiga given that it doesn't even support basic multiprocessing and given that there are easier ways to get additional performance.

@megol: another click-bait...

@cdimauro

wonder when wee will see optical cpu's for regulere consumers

@retro: will come in some years. The Moore's law is at an end, and something else should be invented to grow performances...

@cdimauro

Threadlets (as defined in the Coreteks YouTube video linked) could be the something else. Unfortunately it's owned by Intel. the video mentions about 2 competitors which I looked up. Cambricorn is a Huaweii product and a licenseable extension to ARM. Graphcore is owned mostly by Microsoft and BMW.

Last edited by Samurai_Crow on 11-Apr-2019 at 05:52 AM.

Of course, the simplest and hackiest thing would be to enable some form of AMP to allow people who are running a single-core OS on multi-core hardware to try and get some parallelism from the untapped potential.

We all know it would be an inelegant implementation, and it is not something that can be built out toward a proper SMP solution. It would essentially be a dead end stop gap solution, but it's something that can be delivered in a relatively short time (heavy on the relatively), and would not break the all important sacrosanct compatibility with existing applications.

Implementing SMP without needing to recompile existing applications is technically possible. It is just not economically viable for such a small platform. Even a middle-of-the-road implementation, where the recompile is simplified through the one-click use of an advanced library is well outside of the ecosystem's capability to bring anything to the market in a meaningful timeframe.

And all those things are made extra difficult when different parts of the OS stack are owned by different parties.

The best option now is to emulate PPC and run the entire OS and all the existing applications inside a sandbox. Other's have suggested this approach. Then newly developed and redeveloped applications can live outside the sandbox inside the new world OS.

Again, southing that would take a very long time as a single party would rewrite many of the other 3rd party components to have better control of the OS.

So much of the system is for all intents and purposes abandonware. Why people are caring to preserve compatibility for a handful of existing applications is beyond me.

_________________
All the way, with 68k

@agami

Quote:

Of course, the simplest and hackiest thing would be to enable some form of AMP to allow people who are running a single-core OS on multi-core hardware to try and get some parallelism from the untapped potential. We all know it would be an inelegant implementation, and it is not something that can be built out toward a proper SMP solution. It would essentially be a dead end stop gap solution, but it's something that can be delivered in a relatively short time (heavy on the relatively), and would not break the all important sacrosanct compatibility with existing applications.

I agree. Something is better than nothing.

Quote:

So much of the system is for all intents and purposes abandonware. Why people are caring to preserve compatibility for a handful of existing applications is beyond me.

One way forward (if there is one) would be to reconceive AmigaOS as a modern OS and port this handful of apps to the new system. Of course it would be really hard to come to any kind of consensus on what that handful of apps are -- the tail on that list could be really long.

_________________
"Unix is supposed to fix that." -- Jay Miner

@cdimauro

I think this video, can be useful under this topic.

https://www.youtube.com/watch?v=5fD5q_LShdY

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

@Everybody

Ever have one of those "D'Oh!" moments? Great-Granny's maiden name was Simpson, so I'm allowed....)

When I recovered, I thought....

Why not just tell Exec--or whichever it is that handles multi-tasking--about the limitations of multiple cores and have it assign each task according to which task has the lowest load?

Just a thought--from one of the charter members of Thinkers Anonymous (You feel call your sponsor, and the two of you go out and get drunk....)

Last edited by pgf_666 on 11-Apr-2019 at 07:58 PM.

@cdimauro

Quote:

cdimauro wrote: @retro: will come in some years. The Moore's law is at an end, and something else should be invented to grow performances...

Geee I would think all of your tech knowledge should give you insight into what that is.

@Srtest

Knowledge doesn't grant precognition. Lack of knowledge however ...

@megol

I wonder what kind of recognition, rather than precognition is required to properly evalutate what the old Amiga was all about, which he also fails to do (which doesn't keep him from going on and on about it in his bureaucratic ways). Seems like you're talking about a very current and specifc knowledge which value doesn't translate to what this kind of tech knowledge is perceived to be. You can memorize entire manuals it still doesn't mean you can get any kind of a meaningful prodcut out there. Wasn't this guy's suggestion that the Amiga goes the route of the Amithlon? He was here for months and months trying to bury the A1-X1k which turned out to be a pretty good and cool A1-4.1 machine, which of course made him disappear until a downtime was upon us. This kind of "knowledge" doesn't impress me and I bet he can't even define what "grow performance" is.

Last edited by Srtest on 13-Apr-2019 at 06:14 PM.

@Srtest

Well I've pushed for Amiga to move to an Amithlon type design on standard x86 PCs, not because I love PCs but because that have been the smart move for a long time. When Hyperion talked how impossible it would be to support every PC configuration I (and others) talked how disingenuous that was when Hyperion didn't support every PPC configuration.

With that said I don't think Amithlon as is would have been a good base to build a NG Amiga, I saw it more as a working proof of concept. What killed it was legal shenanigans not anything technical.

However the post you replied to earlier talked about the future in computing in general with the ending of Moore's law and one can know much about computation in general while not knowing anything about the Amiga. Even with extreme skills and secret knowledge from the latest in leading edge research one have a hard time speculating about the future, refer to my earlier post about Intel predictions: being 15 years off in EUV deployment when speculating about the near term!

People! .... Multicore.

The latest, perhaps viable, line of thought was to make a multicore processor as a slave to a Amiga useable processor. To spread out the workload among one or several processors and let AmigaOS run single threaded as a type of controller that just bosses the system.

Please continue.

_________________
Tinkering with computers.