Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
The team will post updates and news about our project here

APOLLO 68080 Now With HYPER-THREADINGpage  1 2 

Gunnar von Boehn
(Apollo Team Member)
Posts 6207
22 Jun 2017 16:32


APOLLO 68080 is now HYPER-THREADING enabled

This is a major technological improvement for the 68K community.
Software taking benefit from this is developed at the time being.


Mr Niding

Posts 459
22 Jun 2017 16:44


Gunnar von Boehn wrote:

APOLLO 68080 is now HYPER-THREADING enabled
 
  This is a major technological improvement for the 68K community.
  Software taking benefit from this is developed at the time being.

As someone without knowledge to appriciate the technical accomplishments, I still want to say a BIG THANK YOU for you hard work!

Anyone more in the knowhow; any details as to how significant hyperthreading is? I could spend a few minutes searching for info, but sitting in cinema about to watch Wonder Woman ;)


Thomas Blatt

Posts 200
22 Jun 2017 17:02


Great news


Cyber Gorf
(Needs Verification)
Posts 39/ 1
22 Jun 2017 17:31


Gunnar von Boehn wrote:

  Software taking benefit from this is developed at the time being.

Wow.
How? or in what way?
Like the AROS SMP feature?
Or with a special thread.library?

Hope to hear more about it soon!


Steve Ferrell

Posts 424
22 Jun 2017 17:34


Gunnar von Boehn wrote:

APOLLO 68080 is now HYPER-THREADING enabled
 
  This is a major technological improvement for the 68K community.
  Software taking benefit from this is developed at the time being.

 
I think you just put the final nail in OS4's coffin.


Szyk Cech

Posts 191
22 Jun 2017 19:15


Gunnar von Boehn wrote:

  APOLLO 68080 is now HYPER-THREADING enabled
  Software taking benefit from this is developed at the time being.
 

Congratulations!!! Great job!!!
  As Amiga OS is SMP disabled I assume that only new, special software can benefit from this. Is that right?
  Another question:
  Is that mean new thread library?!?
  How many instructions per clock can be executed in peak in each thread?


Gregthe Canuck

Posts 274
22 Jun 2017 20:43



Wow this is completely unexpected.

Nice work!


Salteadorneo Salteador

Posts 20
22 Jun 2017 22:13


Simply magnificent.


Dusko Kovacic

Posts 21
23 Jun 2017 00:04


Steve Ferrell wrote:

 
  I think you just put the final nail in OS4's coffin.

This here is a magnificent news. huge warp into future.
bravo Gunnar!

as for os4, they did a spectacular slow motion suicide by
not developing anything worthily for the last decade.

 


John William

Posts 563
23 Jun 2017 05:28


Dusko Kovacic wrote:

Steve Ferrell wrote:

 
   
  I think you just put the final nail in OS4's coffin.
 

 
 
  This here is a magnificent news. huge warp into future.
  bravo Gunnar!
 
  as for os4, they did a spectacular slow motion suicide by
  not developing anything worthily for the last decade.
 
 

Wait....wait...wait...wait...are you saying for os4 they did a spectacular slow motion suicide by not developing anything worthily for the last decade?
 


Obetto Sannala

Posts 61
23 Jun 2017 06:55


@ Gunnar

This sound awesome! Thank you very much.

Can you explain a bit more, how this works on the software side? Libraries used?


Carlos Peris

Posts 11
23 Jun 2017 07:46


Hyper-threading sounds like a great addition, congrats!!

I hope OS can make use of it soon :)


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
23 Jun 2017 08:27


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.


Martin Soerensen

Posts 232
23 Jun 2017 12:10


I looked at the calendar to see if it said April 1st..


Wawa T

Posts 695
23 Jun 2017 13:36


Gunnar von Boehn wrote:

  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.
   
 

  i think kalamatee has made it clear that if achievable it would mean losing backwards compatibility with the existing amiga applications. in accordance with a popular opinion btw. kalamatee is one of two or three people who programmed smp into aros, however only into x64 arch and otherwise guarded by huge ifdefs in exec. we already had to deal with some side effects of smp introduction to the m68k platform, which made some, just some, legacy binaries fail. it was rather pita to find out the couse, even if its been eventually fixed.
   
 
 

  These drivers which we develop can utilize and benefit from Hyper-threading already today - even without OS support for SMP.
 

  threading within a task/application is certainly possible. its been handled linearly on one cpu on amiga systems so far. however i dont understand how it is handled without os support when distributerd to parallell pipelines. multitasking needs to be switched off for the duration of this, for it to be safe, i suppose? 



Keith Matthews

Posts 39
23 Jun 2017 13:56


Gunnar von Boehn wrote:

APOLLO 68080 is now HYPER-THREADING enabled
 
  This is a major technological improvement for the 68K community.
  Software taking benefit from this is developed at the time being.

Brilliant, Well done Guy's.

Now if someone could just binary patch the OS 8-)


Thierry Atheist

Posts 644
24 Jun 2017 11:53


Keith Matthews wrote:
Gunnar von Boehn wrote:

APOLLO 68080 is now HYPER-THREADING enabled

This is a major technological improvement for the 68K community.
Software taking benefit from this is developed at the time being.

Brilliant, Well done Guy's.

Now if someone could just binary patch the OS 8-)

Hmmm, "binary patch the OS"?

I read something about the AMIGA back in 1990 or so that has haunted me for DECADES!

Can anyone shed some light on this?
Introduction to the C= Commodore AMIGA 2000 (book) wrote:
page 1-10 Introduction

Microprocessor Add-ons

The Amiga 2000 has an internal CPU slot, which can be used to add system extensions such as an accelerator board, containing a Motorola 68020 running at 14 MHz and a math co-processor. An accelerator board, inserted into the expansion slot, could replace the standard 68000 CPU, or work in parallel with it.

Source: https://archive.org/stream/1987-introduction-to-the-amiga-2000#page/n17/mode/2up

"....or work in parallel with it."....

Just what is AOS capable of regarding the above statement, and how is this different from SMP?


Kalamatee (AROS)

Posts 15
24 Jun 2017 12:03


Thierry Atheist wrote:

Keith Matthews wrote:
Gunnar von Boehn wrote:

  APOLLO 68080 is now HYPER-THREADING enabled
 
  This is a major technological improvement for the 68K community.
  Software taking benefit from this is developed at the time being.

 
  Brilliant, Well done Guy's.
 
  Now if someone could just binary patch the OS 8-)

 
  Hmmm, "binary patch the OS"?
 

Like using setpatch..


  I read something about the AMIGA back in 1990 or so that has haunted me for DECADES!
 
  Can anyone shed some light on this?
 
Introduction to the C= Commodore AMIGA 2000 (book) wrote:
page 1-10 Introduction
 
  Microprocessor Add-ons
 
  The Amiga 2000 has an internal CPU slot, which can be used to add system extensions such as an accelerator board, containing a Motorola 68020 running at 14 MHz and a math co-processor. An accelerator board, inserted into the expansion slot, could replace the standard 68000 CPU, or work in parallel with it.

 
  Source: https://archive.org/stream/1987-introduction-to-the-amiga-2000#page/n17/mode/2up
 
  "....or work in parallel with it."....
 
  Just what is AOS capable of regarding the above statement, and how is this different from SMP?

TBH, im not sure how realistic or practical this would be - Im not knowledgable about the hardware at that level, but dont believe there are any mechanisms in place to arbitrate which cpu is reading memory (I could be wrong) for starters, let alone identifying "which" of the cpu's your code is running on.  It would literaly mean the same code is running at the same time on both cpu's, unless someone had some means to provide the previously mentioned arbitration, etc.



Cyber Gorf
(Needs Verification)
Posts 39/ 1
24 Jun 2017 12:13


Kalamatee (AROS) wrote:

Thierry Atheist wrote:

  "....or work in parallel with it."....
 
  Just what is AOS capable of regarding the above statement, and how is this different from SMP?
 

 
  TBH, im not sure how realistic or practical this would be - Im not knowledgable about the hardware at that level, but dont believe there are any mechanisms in place to arbitrate which cpu is reading memory (I could be wrong) for starters, let alone identifying "which" of the cpu's your code is running on.  It would literaly mean the same code is running at the same time on both cpu's, unless someone had some means to provide the previously mentioned arbitration, etc.
 

Well, a second CPU with its own memory could execute a new instance of the OS and run very different code. (E.g. like the Sonnet-PPC-board)
A region of shared memory could be defined for communication.




Samuel Crow

Posts 424
24 Jun 2017 16:43


Cyber Gorf wrote:

Kalamatee (AROS) wrote:

 
Thierry Atheist wrote:

    "....or work in parallel with it."....
   
    Just what is AOS capable of regarding the above statement, and how is this different from SMP?
 

 
  TBH, im not sure how realistic or practical this would be - Im not knowledgable about the hardware at that level, but dont believe there are any mechanisms in place to arbitrate which cpu is reading memory (I could be wrong) for starters, let alone identifying "which" of the cpu's your code is running on.  It would literaly mean the same code is running at the same time on both cpu's, unless someone had some means to provide the previously mentioned arbitration, etc.
 

 
  Well, a second CPU with its own memory could execute a new instance of the OS and run very different code. (E.g. like the Sonnet-PPC-board)
  A region of shared memory could be defined for communication.
 
 

This works for the classical blitter but with a full CPU instruction set, more could be done in parallel.  Maybe audio mixing and other low level drivers can be hard-coded to run on the slave thread.

The idea is that asymmetric processing is more Amiga compatible since the program still runs on one thread.

posts 38page  1 2