Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
The team will post updates and news here

APOLLO 68080 Now With HYPER-THREADINGpage  1 2 

Cyber Gorf
(Needs Verification)
Posts 39/ 1
24 Jun 2017 16:57


Well - I just like the idea of one "master-OS" and some "slave-OSes" taking advantage of other CPUs. AmigaOS has the advantage of being very small and lightweight - so it is not really a drawback to run a new instance of the OS for every (virtual) core.

This approach is gaining popularity anyways:

genode.org
rumpkernel.org
mirage.io
osv.io
unikernel.org


Gunnar von Boehn
(Apollo Team Member)
Posts 4543
24 Jun 2017 17:21


Guys please stay on topic.
Lets not phantasies but stay technical correct


Cyber Gorf
(Needs Verification)
Posts 39/ 1
24 Jun 2017 17:40


Gunnar von Boehn wrote:

Guys please stay on topic.
  Lets not phantasies but stay technical correct

O.K.

hope I did not state anything technical wrong - if so, please correct me.




Vojin Vidanovic

Posts 770
24 Jun 2017 17:54


It doesnt have to be dark fantasy.
  It might just require more powerful CPU and some sandboxing
  if possible on other thread.
 
  Question is simple: could HT be used so "second thread"
  could do minimal sandbox an OS in terms of only needed layers
  and an app.
 
  Example: - Running AROS m68k apps in AmigaOS 3.x as a sandboxed task
- Running AROS m68k or some advanced AmiKit and inside a sandbox running a Linux RedHat 5.1 m68k app or it as complete sandbox.
 
  This I suppose is possible, but would have any sense of usability only when we have Apollo core 200Mhz and beyond? Point is eliminating dual boot need and expanding OS abilities in strange and kinky ways (works for AEROS quite nicely on x86 scale)
 
  However, any use of second thread, including optimized AmigaOS 3.x/AROS m68k drivers, is great and a step forward.
 
  Also, an interesting choice since HT was quite abandoned to SMP, even being a major hype some time ago.
 
  Any advancement of Apollo Core is nice, congratulations.


Sirius Bläkk

Posts 1
24 Jun 2017 22:41


Loving it!
Great Lets keep it gettin weirder N Weird,

looking forward to next level weirdness  ; )


Gunnar von Boehn
(Apollo Team Member)
Posts 4543
25 Jun 2017 05:42


Vojin Vidanovic wrote:

Example: - Running AROS m68k apps in AmigaOS 3.x as a sandboxed task

Please lets NOT confuse people.
This is NOT What we talk about or plan.

What we talk about is very clear:
a) Using HYPER to run on AMIGA OS3 or on AROS some device drivers in HYPER mode - this is will lower latency and improve snappiness of the OS.
This goal is very clear and very easy to reach.



Wawa T

Posts 695
25 Jun 2017 06:24


Gunnar von Boehn wrote:
This goal is very clear and very easy to reach.

i guess so. even though im not sure if this is my preferred solution, one could simply take warpos approach, which is working both on genuine amiga os as well as aros68k.



Gunnar von Boehn
(Apollo Team Member)
Posts 4543
25 Jun 2017 07:06


wawa t wrote:

Gunnar von Boehn wrote:
This goal is very clear and very easy to reach.

   
i guess so. even though im not sure if this is my preferred solution, one could simply take warpos approach, which is working both on genuine amiga os as well as aros68k.

 
Hi Wawa,

I'm sure you meant it in a positive way
and different than WarpOS in the end.
We should maybe make clear that we do not repeat the errors of WarpOS.
 

"WarpOS" was a not good setup.
2 CPUs which are binary incompatible.
And therefore 2 CPUs for which code needs to be developed twice!
2 CPUs which are not coherent to each other. (this can cause lots of problems)
2 CPUs which need to be synced in complex / slow fashion.
 
 
WarpOS is a design which
- increases development effort
- increases problem areas (sync issues)
- has performance issues
 
 
 
What we talk about here - has all this problems NOT.
 
We have here all the time the 68k architecture.
This means we do not need to develop anything new.
 
- We have no new software development effort.
- We have cache coherence by design in APOLLO 68080
  This means no crash problems
- We have no performance problems like WarpOS but instead increased performance.
 
 
Using HYPER mode is from software side super easy.
We can take one existing driver - literally add one/two ASM instructions and run it in LOW LATENCY HYPER mode.
 
This is all what is needed.
And BINGO the user gets a performance / snappiness benefit. :-)
 
What we do is so much easier to use then going the (wrong) WarpOS approach.


Wawa T

Posts 695
25 Jun 2017 07:37


all good points about warpos handicaps, but then binaries need still to be particularly compiled, or rather say assembled, to run on the second pipeline, right? would they then run at all on a regilar 68k? i guess thed throw an error of an illegal instruction or something like that. might be acceptable at device/library level, but not recomendable for whole apps, in my book.


Gunnar von Boehn
(Apollo Team Member)
Posts 4543
25 Jun 2017 07:42


wawa t wrote:

  but then binaries need still to be particularly compiled, or rather say assembled, to run on the
  second pipeline, right?
 

No, of course not.
 
 
wawa t wrote:

  would they then run at all on a regilar 68k?
 

Yes, of course.

I think we need to qualify about what we both talk.

A) If you want to increase the system snappiness and run some driver parallel using Hyper.
B) Or do you think about developing SMP for AMIGA OS?

While we technically now enable the development of Option B,
our own goal is easy and humble - we only want to give the people a more snappy system.

Saying this AMIGA OS with APOLLO is already very snappy - more snappy than MORPHOS on my Pegasos for example.
If I play MP3 and move a Window on my Pegaoss around I get audio glitches and disortions. The AMIGA OS and APOLLO can do such workloads without glitching.




Wawa T

Posts 695
25 Jun 2017 08:18


i am talking about option A, as i still do not really believe option B is feasible, even involving AROS.

so, you say we will be able to compile binaries that take advantage of the second pipe and still remain legacy 68k compatible. good. the question is if this is intended as a stop gap solution, at least as i sense you think, then the usage of this feature should be thought of and restricted to os level components rather than spread out to regular binaries, because it might become obsolete or modified at some point.


Gunnar von Boehn
(Apollo Team Member)
Posts 4543
25 Jun 2017 08:40


wawa t wrote:

  the question is if this is intended as a stop gap solution, at least as i sense you think,
 

 
Maybe I'm wrong, but I have the feeling some misunderstand often what we do. What we do is no black magic.
 
All what we do is bringing to the 68k
those technical inventions which are profen to be very good
and which are STATE OF THE ART in the industry today.
 
Being them
  - Better Branch prediction
  - Memory streaming
  - SIMD
  - Hyperthreading
  - Out of Order execution
  - ...
 
All these things are proven to be good and useful.
 
I can of course understand that some AMIGA coders used to live in a time bubble for the last 20 years.
These timebubble coder might not know these new technologies,
and some of them might have natural fear against "new stuff" especially if "evil INTEL" and other use it.
 
I can also see that some "68K fans" have no real experience in coding on other modern systems like INTEL or POWER.
They only have all their believed "wisdom" from reading some online ars-technica articles.
 
I can see that some of these "arm-chair CPU architects" have a very disordered world view of how CPUs work internally - and misread or misunderstand what we do.
Some even believe we do stuff worse and different than IBM or INTEL - just simply because they do not know what we do internally and how INTEL and IBM do it.
 

The truth is very simple:
- We give 68K the modern "state of the art" CPU features.
- We improved AGA and added to it what Commodore more or less always wanted.
This together allows to create new, more modern AMIGAs




Wawa T

Posts 695
25 Jun 2017 10:16


i wasnt questioning hardware decisions. i simply try to imagine the most flexible strategy this feature might be taken advantage of by software.


Wawa T

Posts 695
25 Jun 2017 10:24


certainly adopting aros smp might be worth experimenting with even for the sake of it. aros is a research system after all. this if kalamatee considers it interesting. but:
  1, it would be still quite a bit of work, most smp changes are exclusive to x64 arch and would first have to be implemented in 68k target guarded by "#ifdef AROS_SMP", i guess.
  2, we would have to be prepared to test a lot even if it doesnt blow up everything just to start with, because we already had an issue that slipped through (some semaphore padding) and caused a significant number of genuine amiga software fail, but not all.


Cyber Gorf
(Needs Verification)
Posts 39/ 1
25 Jun 2017 10:44


Gunnar von Boehn wrote:
 
Maybe I'm wrong, but I have the feeling some misunderstand often what we do. What we do is no black magic.

 
Well, it seems like a misunderstanding to me:
Everyone in this thread (or even the whole forum) is pleased with the new hyper-threading feature. Why would one not? It is a cool thing!
 
 

  Being them
    - Better Branch prediction
    - Memory streaming
    - SIMD
    - Hyperthreading
    - Out of Order execution
 

 
looking forward to OoO execution!
 
 
 

  The truth is very simple:
  - We give 68K the modern "state of the art" CPU features.
  - We improved AGA and added to it what Commodore more or less always wanted.
  This together allows to create new, more modern AMIGAs
 

 
And we love it.
The only thing that was discussed here in this thread, is in what ways these new features can be supported by the OS or applications. And there are some different approaches, as you said yourself.
I agree the most simple/direct way is probably the best way to go - at least for now.
 
 

  Using HYPER mode is from software side super easy.
  We can take one existing driver - literally add one/two ASM instructions and run it in LOW LATENCY HYPER mode.

I admit I am still a little bit confused, how this will look in actual code and how scheduling will work...
 
 

  Lets not phantasies...

 
Unwritten code is always phantasy - until it is written.


Keith Matthews

Posts 39
25 Jun 2017 12:05


Kalamatee (AROS) wrote:

 
  Like using setpatch..
 
 

I was kinda talking a little tongue in cheek, being as how the poor OS is locked up in proprietary squabbles, but yeah.

I was imaging the Kickstart could be patched to hand off certain tasks to the other thread, like I/O etc like a co-processor of sorts. Would still need control somehow. Hmmm I'd better shuttup now and return to my corner cos I'm talking about stuff I clearly don't understand 8-)

Hehehehe

Anyway..... Great Job Guy's.....

Really looking FWD to GOLD3 to move the Vampire over to my A1000. 8-)
IC Sockets Risers are ordered and on the way! 8-)


Niclas A
(Apollo Team Member)
Posts 208
19 Aug 2017 10:12


Any news on this?
Will it be included in GOLD3 ?


Mallagan Bellator

Posts 380
19 Aug 2017 19:53


Gunnar von Boehn wrote:

Obetto Sannala wrote:

  @ Gunnar
   
  This sound awesome! Thank you very much.
   
  Can you explain a bit more, how this works on the software side? Libraries used?
 

 
  Hyperthreading can be used in many ways.
 
  a) Hyperthreading can be exposed to the OS as 2 CPUS.
  This is the "typical" usage in the modern x86 world.
  Having two virtual CPUs allows you increase the total system performance, as the full power the CPU can better be used.
 
  APOLLO does support fully-fine-grained Hyperthreading.
  This means Apollo supports Threat-switch on clock cycle granularity. Fine-grained Hyperthreading allows to use otherwise wasted wait times efficiently.
 
  Using 2 CPUs in SMP mode, requires the support of the OS.
  AMIGA OS does as of today not support this.
  AROS could offer support for this.
 
 
 
 
 
 
  b) Hyperthreading can be used to greatly lower latency and avoid IRQ overhead.
  The feature we are using on the Vampire product already today in our Dev-team.
 
  Our team has several drivers and libraries in development.
  Drivers like NETWORK, WIFI, SDCard, IDE, RTG Graphics....
 
  These drivers which we develop can utilize and benefit from Hyper-threading already today - even without OS support for SMP.
 
  Using Hyperthreading on such drivers lowers latency, improves thoughput (faster IDE/ faster Internet), and improves the snappiness  of the whole system.
 
 
 
 
  c) The third big benefit of Hyperthreading is that by running 2 threats in parallel the CPU core can avoid instruction dependencies.
 
  As you know APOLLO does support Super Scalar execution which means executing several instructions per cycle.
 
  Program which are written mostly sequentially are very difficult to run in Super-Scalar. Such programs do not benefit from Super Scalar.
  A well know example is AMIGA SYSINFO.
  AMIGA SYSINFO is written fully sequential and does not benefit from Super-Scalar.
  SYSINFO shows around 110 MIPS on the VAMPIRE.
  If SYSINFO would not be written sequentially the score would be over 200 MIPS.
  In other words the way SYSINFO was coded makes it run at halve speed only.
  This means halve of APOLLO speed is not used when running SYSINFO.
 
  A CPU can try to "fix" this with using a technique called OUT OF ORDER execution.
  But Out Of Order can only fix a certain "window" of instructions and if this Window does not provide enough independent code - then the sequentially can not be cured.
 
  Hyperthreading is a trick to fix this.
  If you would run 2 programs their instructions flow are by design independant - this means the indiepandcy level doubled automatically.
  This improves the possibility to use MultiScalar execution by 100%.
 
  In other words if you would run 2 instances  of SYSINFO in parallel on APOLLO  then each of them could run roughly at their current speed.
 
  While there is great potential to exploit this in the future.
  For this to be exploited development on the OS needs to be done.
  Maybe this will come with using AROS.
 
 
 
  d) A forth potential benefit is using the higher degree of instruction independence in the pipeline design of the CPU.
  Some CPU designs from IBM or INTEL do this.
  Using this does allow to increase the clockrate of the chip.
 
  We do not use this today - but we like to enable this as option for us.

I'm thinking about how Amiga OS uses the copper in the Agnus, as well as FPU's on turbo cards


posts 38page  1 2