O: Vampire 500
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.
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.
Komentovat