@matthey

Quote:

matthey wrote: Hammer Quote: That's a flawed comparison when ODROID H4 has more ports, 64-bit DDR5 4800 up to 48 GB SODIMM and a sizeable integrated GPU i.e. ... For modern DX12-class Vulkan games, the Intel solution crushed them all. I said the ODROID-H4 performance was roughly like a 10 year old desktop system, which is good, and it uses much less power, which is better yet. I expect passively cooling is not practical and there is additional expense for a power supply and case with airflow. The RPi 5 SBC may be more like a 20 year old desktop but it may be possible to use passive cooling in some environments and it can be powered from a 27W USB-C power supply which is cheaper than a 60W or greater dedicated power supply. The total system price is cheaper for the RPi 5 which also includes the memory. An under $100 USD lower memory RPi 5 system is possible while the cheapest ODROID-H4 system is going to be more like $150 USD. ODROID-H4 SBC $99 8GiB memory $40 active cooler $10 60W power supply $20? --- $169 for 8GiB system ($149 for 4GiB system, $139 for 2GiB system) RPi 5 SBC $40 (base price but no zero memory option) 8GiB memory $40 ($5/GiB) active cooler $10 (passive cooler $5) 45W USB-C power supply $17 --- $107 for 8GiB system ($87 for 4GiB system, $77 for 2GiB system) The ODROID-H4 may offer more value if using x86-64 software but it is more expensive for a system and uses more power. RPis may offer more value for some uses like embedded use and retro emulation. They may be adequate for low end productivity software requirements much like the 68k Amiga for many years with less than the original $35 RPi specs and closer to the $5 RPi Zero or RPi Pico 2 specs (68060&AA+ use fewer transistors than the ARM SoCs of these SBCs). The 68k Amiga did not continue to be integrated or enhanced resulting in the high prices today.

There are too many variables, mixed together, which make such comparisons useless.

What should be the target market? Low-power? Low-price? Something in-between (and with which thresholds)?
Which base features should be exposed? Video out (HMI, VGA)? In case, with a simple or more complex GPU? How much memory?
GPIOs? How many? Embedded? FPGA? How many LEs?
etc. etc.

@matthey

Quote:

matthey wrote: Hombre/PA-RISC was separate from the 68k Amiga and may have ended up being shorter lived than the 68k Amiga. Integer fixed point 3D viability did not last long. Integer fixed point 3D only lasted from about 1995 to 2000 and if late in Commodore fashion, it may not have been successful. PA-RISC implements integer SIMD in the integer unit where adding floating point SIMD would reduce integer performance (the Apollo Core does the same as it is cheap).

SIMD on GP/Integer registers is a very poor decision, which cripples future extensions (e.g. wider units for processing more elements).

Well, PA-RISC itself was a very bad ISA, which very poor code density, with required TONs of caches to get decent performance (exactly the same mistake that HP will do with Intel for Itanium) --> super-expensive.
Only an incompetent can sustain its usage with small caches for a console.
Quote:

When a floating point capable SIMD unit was wanted, it may have been easier to return to the 68k and add it. PA-RISC, 88k and AC are the only ISAs I can think of that added SIMD into the integer unit and none of them added floating point SIMD

FP was already quite expensive at the time, so having it on SIMD was overkill.

However, using GP registers was a very bad decision by itself, as I've said before. Unless you end up with a solution like virtual vector registers, that Mitch has invented for his My 66000.
Quote:

even though it is more important than integer SIMD today.

Absolutely.

@minator

Quote:

minator wrote: @Hammer Quote: GeekBench compared Intel Processor N97 vs Broadcom BCM2712 Intel Processor N97 (quad-core Intel Gracemont CPU): Geekbench 6 single core: 1,031 Geekbench 6 multi-core: 3,068 Broadcom BCM2712 (quad-core ARM Cortex A76 CPU): Geekbench 6 single core: 748 Geekbench 6 multi-core: 1,507 Those RPi numbers look pretty old. The SoC in the RPi is run very conservatively, but over time they tweak the settings and it gets faster. You can also tweak the setting yourself and get considerably better numbers - it is very overclockable. Some people have got it well over 3GHz with crazy cooling setups. I modified the memory timing on mine and changed the PCIe setting for the SSD. These were my results from a few months ago: This was at 2.4GHz with memory tweak: Geekbench 6 / Linux: Single core 890 Multi core 2108 - About the same as a 10 year old Mac mini (Core i5 2.6GHz) Overclocked to 2.8GHz with memory tweak: Geekbench 6 / Linux: Single core 1018 Multi core 2283 - About the same as an 8 year old MacBook Pro (Core i7 2.6GHz)

Geekbench is pure crap: avoid it.

@matthey

Quote:

matthey wrote: The cost of ARM64/AArch64 is 45% more memory is needed! With ARM 32-bit ISAs disappearing from application processors, that means 256MiB, 512MiB and 1GiB SBCs are no longer practical with 64-bit Linux. The RPi 4 already comes with 2GiB minimum leaving the 64-bit RPi 3 with 1GiB and the RPi Zero 2 W with 512MiB but most embedded customers likely use 32-bit support, dedicated embedded applications can get away with using less memory than a general purpose OS and RTOS options exist that use less memory than Linux. The deprecated ARM 32-bit support is forcing new RPi SBCs to scale up and compete with 64-bit x86-64 SBCs which have better performance and a large x86-64 software library. SBC | memory | storage RPi5 2GiB microSD (cheap option but 32-bit OS and apps may be better with slow drive swap) RPi5 2GiB NVMe (not much sense as adding more memory is cheaper than adding a NVMe drive) RPi5 4GiB microSD (faster 64-bit OS and apps with reduced swap but 64-bit addressing not used) RPi5 4GiB NVMe (faster but added NVMe drive cost now competes with x86-64 SBCs) RPi5 8GiB microSD (borderline worthwhile competing against x86-64 SBCs) RPi5 8GiB NVMe (better off with x86-64 SBCs due to price & spec opening up x86-64 software library) RPi5 16GiB microSD (does not compete against x86-64 SBCs) RPi5 16GiB NVMe (does not compete against x86-64 SBCs)

Which is good for competitors with better 64-bit ISAs.
Quote:

RPi can continue to use older cores and chip fab processes but that may become difficult. The other option is to scale up 32-bit Cortex-M cores for embedded application like uses which may be what they are doing with their fabless semiconductor development.

Since there's basically no 32-bit development anymore, what they can do is just use new fab processes for the legacy 32-bit cores.

Which is a very good thing, anyway: they aren't cheaper (since new processes are much more expensive), but they can produce much small chips and which consume way less power and/or increase the operating frequencies.
Quote:

ARM has created an opportunity for a 32-bit CPU ISA with good code density to fill the void they have created by removing 32-bit compatibility to better compete against 64-bit x86-64.

Indeed, but there are good chances with 64-bit architecture with better code density as well.
Quote:

ARM likely assume that no 32-bit architecture with Thumb-2 like code density could have good performance

Hum. Right for the code density, but it might not be the case for performance.
Quote:

and that no new 64-bit ISA competition would have better code density and performance than AArch64 but I believe neither of these assumptions are true.

Correct.

@minator

Quote:

minator wrote: Lunar lake is on 3nm, X-Elite is a first implementation on 4nm. Lunar lake is close to the X-Elite but doesn't even touch the M4.

Yes, at least for SPECInt: https://blog.hjc.im/spec-cpu-2017
But I bet that SPECFp isn't far from this.

Intel definitely lost the performance crown, long ago (the picture in the blog reports several results, with many processor cores, of different brands).

@cdimauro

Quote:

Intel definitely lost the performance crown, long ago (the picture in the blog reports several results, with many processor cores, of different brands).

https://videocardz.com/newz/asus-rog-xbox-ally-handhelds-announced-featuring-amd-ryzen-z2-series
This Windows 11 build for ASUS ROG Xbox Ally has reduced idle power consumption by two-thirds.

Windows is part of the power consumption problem.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer: I've clearly talked about performance, and not power consumption, on this specific part.