Symmetric multiprocessing...

Nagging hardware related question? Post here!
User avatar
tofro
QL Wafer Drive
Posts: 1604
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Symmetric multiprocessing...

Postby tofro » Sun Jun 16, 2019 9:35 am

Dave,

one proposal: If you want to see some software developed for such a multi-CPU approach, I would refrain from anything that inhibits "standard" software to be run on the "new" CPUs.

  • Each CPU should be considered a "separate QL", running its own, dedicated OS (e.g. a modified Minerva)
  • The data exchange to the host QL should be done using a device driver working along the lines of the QLNET driver (just using a different physical connection through DPRAM, so much faster)

That is, once booted through the host, the QLs on the card should run their own copy of Minerva (possibly downsized by all the drivers not needed), be remote-controlled by the host just like you can remote control a networked QL with FSERVE.

That ensures "everyone" (at least people with more than one networked QL) could develop software for the card. With the real hardware, it would just be much faster.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Dave
SandySuperQDave
Posts: 2415
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Symmetric multiprocessing...

Postby Dave » Sun Jun 16, 2019 7:30 pm

That does seem to be the game plan.

I'm just unsure how the boot process continues when the 8302 is absent. It would be possible to press F1/F2, but a lot of the regular polling for IO is redundant.

But no, I wouldn't do anything that would be an obstacle to running an OS, any OS, on the extra cores.


Derek_Stewart
QL Wafer Drive
Posts: 1431
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Symmetric multiprocessing...

Postby Derek_Stewart » Sun Jun 16, 2019 9:55 pm

Hi Dave,

You talk about a modified Minerva, which is an excellent operating system.

Why not use SMSQ/E?


Regards,

Derek
User avatar
Dave
SandySuperQDave
Posts: 2415
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Symmetric multiprocessing...

Postby Dave » Mon Jun 17, 2019 12:51 am

Minerva, SMSQ/E, some open source OS that runs QL stuff.

I'm not doing the porting, though! :P


User avatar
Dave
SandySuperQDave
Posts: 2415
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Symmetric multiprocessing...

Postby Dave » Mon Jun 17, 2019 1:46 am

Now, to be fair, Nasta has poured scorn on my ideas, in private. While my proposal is simplistic, it is easy to implement, requires minimal development, and so actually has a chance of existing. I always try to remember that Nasta forgets between breakfast and lunch more than I'll ever know about the QL in two lifetimes.

That said, he does raise interesting questions...

How might an OS detect how many nodes are present, and their configuration and capabilities? How might an OS issue tasks to such a node? Is this the most efficient way? Is there a way to have a node write directly to the screen RAM?

He corrected me when I said "256K per CPU" when I should have said "128K shared to host and 128K shared to peer" - because between two peers there is not 512K of RAM, there is 384K of RAM. 128K is common to both CPUs. He also corrected my bad block diagram above with the following:

unnamed.jpg
Drawn by Nasta


User avatar
Peter
Aurora
Posts: 849
Joined: Sat Jan 22, 2011 8:47 am

Re: Symmetric multiprocessing...

Postby Peter » Tue Jun 18, 2019 10:21 am

tofro wrote:
  • Each CPU should be considered a "separate QL", running its own, dedicated OS (e.g. a modified Minerva)
  • The data exchange to the host QL should be done using a device driver working along the lines of the QLNET driver (just using a different physical connection through DPRAM, so much faster)

This is exactly how I would do it (still wondering why no attention seems to go toward FPGA for multiprocessing, where the CPU cores could be on a single chip and coupled very efficiently).

While technically interesting, I just doubt that multiprocessing would help the practical speed issues much. That's why I hesitate to go that road.
For example, more CPUs won't ease the pains of slow mass storage buffering nor overly memory-copying GUI...


User avatar
Dave
SandySuperQDave
Posts: 2415
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Symmetric multiprocessing...

Postby Dave » Tue Jun 18, 2019 1:51 pm

Peter wrote:This is exactly how I would do it (still wondering why no attention seems to go toward FPGA for multiprocessing, where the CPU cores could be on a single chip and coupled very efficiently).

I don't have your skills with FPGAs. Not even elementary skills. If I can get this functional with lean hardware, it would make sense later on to re-implement it in an FPGA. It would at least have driver software - the seemingly insurmountable hurdle.

Peter wrote:While technically interesting, I just doubt that multiprocessing would help the practical speed issues much. That's why I hesitate to go that road.

You're the only person who has released any work in "High Performance QLing" ;) soooOOooo :D

I think you have exposed a point in throughput where the fine balancing act of the OS finally tumbles. High speed IO is a problem, and going forward it will only get worse and show up in more places. In days of old we would unburden the system of these issues by using DMA, which removed the transfers as an OS-managed task and converted them to an OS triggered, hardware-managed task. However, because the only performance benefits DMA brought to the table were overcoming OS weaknesses, it became more economical to code around it and improve those areas of the OS.

So there's our challenge as a community: as developers are in such short supply, how do we resolve the same issue knowing what the entire industry has done since then? Do we find a way to fix the OS, or do we throw hardware at the problem to make it go away? Both require developers - but OS developers are a very rare breed.

It's probably the most serious bottleneck the QL community faces.

Peter wrote:For example, more CPUs won't ease the pains of slow mass storage buffering nor overly memory-copying GUI...


Ah, but we can do a lot to ameliorate the problems. I'm not predicting they'll go away, but there are solutions that work for some parts of the equation that might be surprisingly simple.


Derek_Stewart
QL Wafer Drive
Posts: 1431
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Symmetric multiprocessing...

Postby Derek_Stewart » Tue Jun 18, 2019 6:44 pm

Hi Dave,

It seems to me that some hardware can replaced by an FPGA, could the CPUs be replaced by a multicore FPGA?


Regards,

Derek
User avatar
Dave
SandySuperQDave
Posts: 2415
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Symmetric multiprocessing...

Postby Dave » Tue Jun 18, 2019 8:37 pm

Absolutely they could. A larger FPGA would really be ideal for this. Peter's IP for the rest of the QL in FPGA would make it a home run. The limitation to overcome is the amount of internal RAM that can be structured as dual port.

I'd propose throwing some discrete-made hardware out there first as proof of concept, then when the users show how they'd like to use it, and what driver support it gets, re-implement it in FPGA, scale up to more cores at higher speed than existing CPUs can go.... The 68SEC000 tops out conservatively at 40MHz. The thing is, I have a few trays of 68EC030FE40, and they would perform a lot better than the '000s and likely give an FPGA a run for its money.

I think it will come down to economics. FPGA prices climb exponentially after a certain number of CLBs. A point would be reached where the FPGA cost would rise above the cost of all that discrete DPRAM.

I suspect most people would be happy with two or four extra high speed virtual systems on a single real system.


Derek_Stewart
QL Wafer Drive
Posts: 1431
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Symmetric multiprocessing...

Postby Derek_Stewart » Tue Jun 18, 2019 8:52 pm

Hi Dave,

Sounds great, how about a expansion socket to plug a Raspberry PI in?


Regards,

Derek

Who is online

Users browsing this forum: No registered users and 3 guests