ZORRAM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@ppcamiga1

Quote:

ppcamiga1 wrote: @Rose Quote: So is PPC. Of course not. There is big difference between something as fast and as comfortable as cheap pc from Windows 95 era like ppc and something that is not like 68k. The first is still nice retro while other should be in museum.

With such poor code density, PPC has a hard time keeping up. It needs 30% more cache than 68k to match performance per clock. I have a G4 based Mac Mini with MorphOS which is nice but it's not going to beat an equivalently clocked CISC machine.

@Samurai_Crow

https://www.youtube.com/watch?v=AADZo73yrq4

Well technically RISK can be clocked at higher clock frequency because they create less heat, INTEL have a problem, I’m sure AMD might have a few more years, buts it’s the end of moores law, the CISC architecture only really exists as backwards compatibility layer, on top of INEL micro opcodes, and the micro opcodes are RISK.

The PowerPC problem is mismanagement, too high price, its just as good as ARM, but the world was stuck on INTEL / little endian instructions, and does not really care about needs of Amiga users, or classic software.

Last edited by NutsAboutAmiga on 10-Jul-2020 at 04:51 PM.
Last edited by NutsAboutAmiga on 10-Jul-2020 at 04:50 PM.

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

@Samurai_Crow

I think maybe of benchmark using speedometer on MacOS7.6 might faulty, practically because the OS was mostly 68K, so it had to emulate it, giving big disfavors to any benchmark result most likely, the 680x0 was know CPU with lots of legacy, the 601 was new at the time, a lot of 680x0 software was hand optimized, I guess most of PPC software just written in C code.

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

Quote:

Well technically RISK can be clocked at higher clock frequency because they create less heat, INTEL have a problem, I’m sure AMD might have a few more years, buts it’s the end of moores law, the CISC architecture only really exists as backwards compatibility layer, on top of INEL micro opcodes, and the micro opcodes are RISK.

I take it that you are not familiar with Power9 thermal design guides?

Last edited by Rose on 10-Jul-2020 at 05:05 PM.
Last edited by Rose on 10-Jul-2020 at 05:02 PM.

@NutsAboutAmiga

Quote:

https://www.youtube.com/watch?v=AADZo73yrq4

Good video -- thanks for the link!

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

Quote:

Samurai_Crow wrote: With such poor code density, PPC has a hard time keeping up. It needs 30% more cache than 68k to match performance per clock. I have a G4 based Mac Mini with MorphOS which is nice but it's not going to beat an equivalently clocked CISC machine.

A 25%-30% reduction in code size improves ICache performance roughly as much as doubling the ICache size.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-63.pdf

I expect 68020 code is closer to 40% better code density than PPC code.

Quote:

NutsAboutAmiga wrote: https://www.youtube.com/watch?v=AADZo73yrq4 Well technically RISK can be clocked at higher clock frequency because they create less heat, INTEL have a problem, I’m sure AMD might have a few more years, buts it’s the end of moores law, the CISC architecture only really exists as backwards compatibility layer, on top of INEL micro opcodes, and the micro opcodes are RISK.

The video compares desktop x86_64 CPUs with high performance cores and crazy amounts of high performance caches to ARM SoCs designed for low power smart phones. The x86_64 CPUs do waste energy breaking down instructions to micro ops but so do high performance ARM cores since the Cortex-A76 including the Cortex-A78 shown in one of the last frames under "Future".

The DEC Alpha tried to take advantage of a simpler RISC ISA and pipeline to clock the CPU much faster than the competition. This was not a good design and was a big reason why DEC disappeared. Higher clock speeds produced elevated heat and the slimmed down cores were weakened. Processor speeds outpaced memory speeds so the core would only have an advantage when instructions and data was in caches. Caches need to be small to be fast. RISC usually needs to execute many more simple instructions than CISC and Alpha code has horrible code density creating a bottleneck in the ICache. Alpha eventually went to multi-level caches which helped but secondary caches are bigger (slower), further from the core (slower) and use more power.

Quote:

For the simpler processor cores in mobile devices in particular, delivering the instruction stream is often the single largest source of energy consumption. In the DEC StrongARM-110, for example, instruction address translation and cache access account for 36% of the chip’s power dissipation [10]. In a more recent study [5], instruction cache access alone dissipated 40% of the energy in a five-stage RISC pipeline. Main memory accesses and processor stalls incurred upon instruction cache misses consume more energy still.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-63.pdf

This is the same paper I linked for Samurai_Crow. It is the thesis of one of the RISC-V guys and the incentive to create the compressed RISC-V encodings. The 68020 ISA has something like 50% better code density than the Alpha meaning the 68060 8kiB ICache had the performance of a 32kiB ICache for the Alpha or the Alpha 8kiB ICache had the performance of a 2kiB ICache on the 68060. As bad as this sounds, the 68060 has an even bigger ICache advantage as it is 4 way while the Alpha used a direct mapped ICache which is faster to keep up with the core but suffers from conflict misses. Doubling the associativity, from direct mapped to two-way, or from two-way to four-way, has about the same effect on raising the hit rate as doubling the cache size. Now that first Alpha core ICache has the performance of a 0.5kiB Icache on a 68060. This doesn't consider the energy use which is significant as the Alpha is using memory which uses more energy than a cache access. While the Alpha is waiting on memory it can execute all those extra instructions needed by RISC too. It isn't just the 68060 which is more practical. The PPC 604e was a much better design than the Alpha. The large caches limited the clock speed but high clock speeds are useless without adequate caches. The 68060 had a deeper pipeline than the 604e and more efficiently used smaller caches likely making it a better candidate to clock up.

Quote:

The PowerPC problem is mismanagement, too high price, its just as good as ARM, but the world was stuck on INTEL / little endian instructions, and does not really care about needs of Amiga users, or classic software.

I think the ARM AArch64 ISA is better than the PPC ISA. Better code density, fewer instructions needed, better branch handling and conditional instructions, more powerful addressing modes including better PC relative support and longer branch displacements important for 64 bit addressing, more standard and more readable. It's not perfect by any means but looks to me like it is a move in the right direction for RISC toward a higher performance RISC CISC hybrid.

Last edited by matthey on 11-Jul-2020 at 05:27 PM.
Last edited by matthey on 11-Jul-2020 at 09:25 AM.
Last edited by matthey on 11-Jul-2020 at 09:22 AM.

@amigang

Quote:

amigang wrote: So Apple has gone and done it and is moving to arm cpu for its hardware within the next two years, not that surprise when I first saw the iPad/tablet based on mobile hardware / mobile iOS (don’t forget at the time a lot of people thought it would be macOS /x86 based) I thought they would make the move. What do Amiga’ns think?

Intel has supply issues. Removing Apple will reduce Intel's supply problems.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Samurai_Crow

Quote:

With such poor code density, PPC has a hard time keeping up. It needs 30% more cache than 68k to match performance per clock.

The some crap as in 2008 when gvb start natami.
tvelve years passed and 68k is still not as good as first pentium.

@ppcamiga1

Once Gunnar gets over his fetish for reconfigurable silicon and comes out with an ASIC it will clock much faster. The per-clock performance of the 68080 is equivalent to a Core2 Solo already.

@Samurai_Crow

Quote:

The per-clock performance of the 68080 is equivalent to a Core2 Solo already.

Benchmarks? 100 MHz "68080" would be then as fast as 68060 400+ MHz.

@Samurai_Crow

Quote:

The per-clock performance of the 68080 is equivalent to a Core2 Solo already.

This is yoke.
It is not even a close.

@Samurai_Crow

Quote:

Samurai_Crow wrote: @ppcamiga1 Once Gunnar gets over his fetish for reconfigurable silicon and comes out with an ASIC it will clock much faster. The per-clock performance of the 68080 is equivalent to a Core2 Solo already.

Based on what metric? What's your Quake benchmark?


Quake software render benchmark examples
https://thandor.net/benchmark/33


Quake II software render benchmark examples
https://thandor.net/benchmark/40

Last edited by Hammer on 11-Jul-2020 at 05:48 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@OneTimer1

Quote:

OneTimer1 wrote: @amigang If I want to make a strong desktop computer, I need a strong CPU. Intel or AMD have strong CPUs, but ARM is a complete platform change, it means incompatibilities, problems with older applications and losing customers to Windows/Linux because it ran better on the older desktops. Apple's users lacked a real desktop for nearly a year before they introduced the new cheese grater, maybe they will leaf the PC market. Edit: typos

For workloads like Blender 3D 2.83.xx, I wouldn't return to pure CPU render cycles. Hardware Accelerated Raytracing and Tensor cores (for raytracing denoise) are desirable for graphics productivity.

Adobe software on Windows supports Nvidia Optix RTX.

AMD has demonstrated Hardware Accelerated Raytracing with RDNA2 based game consoles.

Many new graphics productivity software has support for Hardware-Accelerated Raytracing (RTX) and the Apple platform is behind in this area.

Last edited by Hammer on 11-Jul-2020 at 06:02 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

I don't have a Vampire any more. Otherwise I'd take you up on the Quake software renderer. Quake 2 supports accelerated video which is down the road a ways for SAGA core. Do you compare CPU strength by seeing how fast the GPU is?

@Samurai_Crow

Your argument has departed from classic Amiga idealogy which is custom chips.

Blender 3d final render example for bmw27 demo file.
Core 9 9900K stock = 60 seconds
Ryzen 9 3900X stock = 50 seconds
RTX 2080 = 10 seconds (ASUS RTX 2080 Duel EVO)
RTX 2080 Ti = 8 seconds (MSI RTX 2080 Ti GX Trio),

https://www.slashgear.com/huaweis-arm-based-desktop-pc-could-leave-you-scratching-your-head-06627865/
ARM v8-based 7nm HiSilicon Kunpeng 920 renders the same bmw27 demo file for almost 12 minutes.

RTX Turing GPUs can do realtime raytracing in edit mode close to final render's quality.

I have been looking at Vampire v4 for retro.

Last edited by Hammer on 12-Jul-2020 at 01:32 AM.
Last edited by Hammer on 12-Jul-2020 at 01:27 AM.
Last edited by Hammer on 12-Jul-2020 at 01:25 AM.
Last edited by Hammer on 12-Jul-2020 at 01:21 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@amigang

This makes complete sense, after all Macs cost and ARM and a LEG.

_________________
Sent from my Quantum Computer.

@Samurai_Crow

There are Quake 2 versions with software renderer (Hyperion one I think). Quake (1) benchmarks of Vampire were not very promising as FPU was only rudimentary supported back then (2017: under 25 FPS in cca 320x240 8 bit). For comparison, uA1 scored cca 30 FPS in 800x600 back in 2005.

@pavlor

True about the FPU. As for the MicroA1, it has eight times the clock speed and a discrete GPU with 32 megs of dedicated video RAM. At 800 MHz the Vampire would still win.