@matthey

Quote:

SIMD programming then did not work well with compilers and there was a shortage of PPC assembly programmers so why beef up a SIMD unit that is rarely used?

SIMD / AltiVec is well supported by GCC. Compilers use like 99%, sure there is VBCC, but no one uses that.. is not that that is so hard, its just that if you look at the userbase, what percentage of users has it.

GCC does not like linking different CPU ISA’s objects, so if you build a AltiVec version, it will not work on none AltiVec computer. Only the G4 and PA6T has AltiVec.

the other SMD instruction set SPE only the A1222 has, it not supported in newer GCC’s, and it’s absolute necessary due to the lack of a standard FPU.

We see the same issue on 680x0 many developers avoid having float, because many 680x0 CPU’s does not have a FPU.

I think what was great about PS3, was that there was only one CPU, and there was only one platform, developers wont need to worry about people who did not have a PPE or SPE.

Quote:

SIMD units did make higher clock speeds more important to boost SIMD throughput but that was not a good thing for PPC shallow pipeline limited OoO designs.

its just that if you do 64bit reads and write in a unrolled loop, you retch the max memory speed, without AltiVec. DDR2 memory is not that fast,

All the other nonsense you write about is not the issue, if you look at P5020 without AltiVec for example, it has DDR3 memory with slightly higher clock speed, can easily beat the PA6T with AltiVec in memory copy speed.

Last edited by NutsAboutAmiga on 16-Mar-2025 at 04:22 PM.
Last edited by NutsAboutAmiga on 16-Mar-2025 at 04:20 PM.
Last edited by NutsAboutAmiga on 16-Mar-2025 at 04:14 PM.

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

NutsAboutAmiga Quote:

SIMD / AltiVec is well supported by GCC. Compilers use like 99%, sure there is VBCC, but no one uses that.. is not that that is so hard, its just that if you look at the userbase, what percentage of users has it. GCC does not like linking different CPU ISA’s objects, so if you build a AltiVec version, it will not work on none AltiVec computer. Only the G4 and PA6T has AltiVec.

GCC supports Altivec/VMX "but no one uses that" on the desktop since the bounties to add SIMD support to PPC programs a decade ago. Also, PPC Alitvec/VMX direct assembly programming which has the most performance potential has always been rare unlike easier x86-64 SIMD unit assembly programming. That leaves auto vectorization which allows compiled programs to gain some SIMD support without dead platform specific optimizations.

https://en.wikipedia.org/wiki/Automatic_vectorization

Auto vectorization allows some level of cross platform SIMD support although code has to be written in a way to support it and the SIMD hardware has to support it. The idea is that FP operations can be performed in either the FPU or with more parallelism in the SIMD unit if supported. If the SIMD unit flushes all denormals/subnormals to zero then it is not IEEE compliant and auto vectorization can not occur by default. The GCC -ffast-math or apply named -funsafe-math-optimizations are required to allow auto vectorization but they allow other unsafe optimizations that may have consequences. If the Cell hardware flushes all FP denormals/subnormals to zero, then like the ARM Neon SIMD unit before AArch64, auto vectorization can not occur by default.

An option to flush denormal/subnormal numbers to zero is good as it improves performance for some algorithms but it will cause other algorithms to fail which is why it is required by the IEEE FP standard. Known working FP code may fail with auto vectorization as FPU intermediate results may use a wider exponent than for SIMD. Single Precision FP numbers are converted to double precision for the PPC FPU and single and double precision numbers are converted to extended precision for the 68k FPU. Not only do the higher precision intermediate results improve accuracy, but the wider exponent reduces the underflow/overflow denormal/subnormal results which reduce performance. SIMD units performing calculations with the precision of the datatype can not mitigate this more common for SIMD unit performance hit without flush to zero. Algorithms require more instructions without increased intermediate result precision which further offsets the performance advantage of SIMD units and SIMD unit FPUs.

Floating Point - Past, present and Future
https://youtu.be/LuKBvsvkzEs?list=PLISEtDmihMo1-ADUicHo5hl7RJRQ5ilJT&t=4736
William Kahan Quote:

And the idea is to compute these expressions in those (extended precision) registers so that when you compute the whole thing you get something that will be good pretty much to the last of the double precision digits that matter to you and it takes about 3 instructions or maybe 10 instructions if you want to be fussy. But if your language doesn't allow you to utter these things (extended precision registers) then what you've got to do is use double precision variables which have less precision and write a complicated program with 70 instructions in order to get the extra few bits of accuracy here which you need only in extravagant cases but you don't know in advance if your case will be extravagant or not so you program it up always. And therefor you have to do with only double precision variables in a long program what is done in a handful of instructions with these (extended precision) registers. However, failing to appreciate this subtlety, the folks at Sun would lose on benchmarks.

So instead of an extended precision FPU with 10 instructions and fewer underflows/overflows, a SIMD unit requires 70 instructions and underflows/overflows can be a performance problem. GCC FP support already takes the hit of SIMD style support so they see the intermediate precision as "evil" choosing to support the push for auto vectorization performance. If you watch all of William Kahan's speech above, he not only talks about intermediate precision but is asked about flush to zero at the end with questions. When removing the intermediate precision like GCC does, more problems are created as the following paper describes with easy to understand examples.

The pitfalls of verifying floating-point computations
https://hal.science/hal-00128124

The problem is not the extra precision but the GCC lack of proper support for extended precision. William Kahan, "the father of FP" actually thought the 68k architecture and FPU was better than the x86 architecture and x87 FPU which he helped design.

NutsAboutAmiga Quote:

the other SMD instruction set SPE only the A1222 has, it not supported in newer GCC’s, and it’s absolute necessary due to the lack of a standard FPU.

There is always soft float for those non-IEEE compliant FPUs. It may not be much slower either with the integer registers being used for FP values.

NutsAboutAmiga Quote:

We see the same issue on 680x0 many developers avoid having float, because many 680x0 CPU’s does not have a FPU. I think what was great about PS3, was that there was only one CPU, and there was only one platform, developers wont need to worry about people who did not have a PPE or SPE.

If you only talk about one hardware, we could talk about 68k hardware with a FPU too. The Cell design was meant to be the first in a series of Cell processors and it was the last too.

NutsAboutAmiga Quote:

its just that if you do 64bit reads and write in a unrolled loop, you retch the max memory speed, without AltiVec. DDR2 memory is not that fast, All the other nonsense you write about is not the issue, if you look at P5020 without AltiVec for example, it has DDR3 memory with slightly higher clock speed, can easily beat the PA6T with AltiVec in memory copy speed.

The Cell CPU has 25.6 GB/s of memory bandwidth compared to 8 GB/s for the PPC G5. It also has 256kiB of SRAM for the SPEs in addition to the CPU 32kiB I+D L1 and 512MiB L2 caches. The CPU is still crap for general purpose workloads as my examples show.

Last edited by matthey on 16-Mar-2025 at 08:13 PM.

@matthey

Quote:

GCC supports Altivec/VMX "but no one uses that" on the desktop since the bounties to add SIMD support to PPC programs a decade ago. Also, PPC Alitvec/VMX direct assembly programming which has the most performance potential has always been rare unlike easier x86-64 SIMD unit assembly programming. That leaves auto vectorization which allows compiled programs to gain some SIMD support without dead platform specific optimizations.

Altivec/VMX is not standard on A-EON's PPCs e.g. PPC e5500 core doesn't have Altivec extensions.

_________________
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

@matthey

Quote:

The Nintendo PPC CPU cores are 4-stage limited OoO desktop PPC G3 cores with an enhanced SIMD unit.

Nintendo PPC CPU's short pipeline has an advantage in branch misprediction. The 64-bit SIMD unit is custom.

Longer pipelines need good branch prediction.

Part of AMD Jaguar's 14 pipeline stage includes 3 latencies fetch from L1 cache. Decode to Dispatch takes 7 stages.

AMD Jaguar's
ALU pipelines have 14 stage,
AGU pipelines have 17 stage,
SIMD pipelines have 16 stage.

ARM Cortex A53 pipeline stage count can range from 8, 10, and 13 deep (ref 1). The decoder stage is simpler on ARM.

ARM Cortex A57's pipeline stages are even longer (ref 1).

Microarchitecture designs are about compromises and transistor budgets.

Reference
1. https://www.anandtech.com/show/6420/arms-cortex-a57-and-cortex-a53-the-first-64bit-armv8-cpu-cores

_________________
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

@matthey

Quote:

The Cell CPU core is superscalar and multithreading which is more advanced than the superscalar 68060 other than the lack of units.

CELL PPE's integer (scalar ALU) pipeline is not superscalar since there's only one of them. IBM designed PPE to be biased towards FPU, SIMD and very high clock speed at profitable yield rates.

7Zip wouldn't be using FPU and SIMD hardware.

Quote:

The Cell core fetches 32B/cycle from the L2 cache for predecoding to the L1 and fetches 16B/cycle from L1 for execution yet the 4B/cycle instruction fetch 68060 at half the clock speed would destroy it for general purpose use of programs with a quick compile. It is not how big your hardware is but how you use it.

CELL has asymmetric processing cores due to PPE and up to 8 SPEs.

CELL is specifically designed for 3D games at a low budget price. The original PS3 has two CELL chips instead of CELL + RSX combo. Dual CELL setup wasn't efficient for raster 3D graphics.

Adding physics processing changes the situations e.g. six core Jaguar @ 1.6GHz almost rivals CELL's PPE + 5 SPE @ 3.2. Ghz

https://media.redgamingtech.com/rgt-website/2014/10/playstation-4-vs-xbox-one-vs-xbox-360-vs-ps3-cpu-and-gpu.jpg
Ubisoft's cloth physics benchmark
Xbox 360 CPU (3 PPEs @ 3.2 Ghz, L2 cache @ 1.6Ghz) = 34,
PS3 CELL (PPE + 5 SPE @ 3.2 Ghz) = 105,
PS4 CPU (six Jaguar @ 1.6Ghz) = 98,
Xbox One CPU (six Jaguar @ 1.75Ghz) = 113,

Scaling Xbox One's PPE to 6 cores would result in a 68 score.

This cloth physics is also executed on AMD GCN 2.x GPUs.
PS4 GPU = 1600, up to 8 ACE front end units and 18 CU execution clusters.
Xbox One GPU = 830, up to 2 ACE units front end units and 12 CU execution clusters.
Each CU (Compute Unit) has 64 stream cores.
ACE = Async Compute engine front end for async compute shader workloads context tracker.

PS3 CELL has 7 active SPEs, games have 6 SPEs available and 1 SPE for OS reserve.
PS4 CPU has 8 active CPU cores, games have 7 CPUs available and 1 CPU for OS reserve.

Quote:

Sure but general purpose use is about integer and FPU performance which is easily accessible with a compile. The 68k Amiga virtual machines are 32-bit only, single core only and do not use SIMD units forever.

So, you shifted your argument from embedded to Amiga market?

Quote:

A reborn 68060 could add 64-bit, a SIMD/vector unit, SMP support and a GPU which would be enough for affordable semi-modern 3D gaming that is competitive with RPi and RISC-V hardware. The 68k Amiga needs practical and easy to use hardware more like the WiiU hardware than the PS3 hardware.

Adding SIMD/vector unit to a reborn 68060 opens the argument to other evolved CPU competition.

Cortex A53 has two FPU/SIMD pipelines while 68060 only has a single non-pipeline FPU.

_________________
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

@matthey

Quote:

The Cell PPC CPU SIMD hardware has been stripped down too!

FYI, PS3 CELL's SPUs don't have FP64 support. This is different from PowerXCell 8i in servers.

From https://image.slideserve.com/750207/gpu-floating-point-features-n.jpg

CELL SPE (PS3)
Precision: IEEE 754
Rounding modes for FADD and FMUL: Round to zero/truncate
Denormal handling: Flush to zero
NAN support: missing
Overflow and Infinity support: only infinity
Square root: software only
Division: software only
Reciprocal estimate accuracy: 12 bit
Reciprocal sqrt estimate accuracy: 12 bit


IBM Altivec
Precision: IEEE 754
Rounding modes for FADD and FMUL: Round to nearest only
Denormal handling: Supported,
NAN support: Yes
Overflow and Infinity support: Yes
Square root: software only
Division: software only
Reciprocal estimate accuracy: 12 bit
Reciprocal sqrt estimate accuracy: 12 bit


Intel SSE
Precision: IEEE 754
Rounding modes for FADD and FMUL: All four IEEE, round to nearest, zero, inf, - inf
Denormal handling: Supported,
NAN support: Yes
Overflow and Infinity support: Yes
Square root: Hardware
Division: Hardware
Reciprocal estimate accuracy: 12 bit
Reciprocal sqrt estimate accuracy: 12 bit


NVIDIA G80
Precision: IEEE 754
Rounding modes for FADD and FMUL: Round to nearest and round to zero
Denormal handling: Flush to zero
NAN support: Yes
Overflow and Infinity support: Yes, only clamps to max norm
Square root: Software only
Division: Software only
Reciprocal estimate accuracy: 24 bit
Reciprocal sqrt estimate accuracy: 23 bit

------------------------

Intel SSE2 FP64 is designed to displace x87 FP64. X86-64 keeps X87 for FP80 use cases.


AMD GCN
https://www.techpowerup.com/forums/attachments/amd-gcn-ieee-754-2008-full-support-jpg.150733/
Precision: IEEE 754
Rounding modes for FADD and FMUL: All four IEEE, round to nearest, zero, inf, - inf
Denormal handling: Supported,


In the past, 3D game workloads were less strict on IEEE-754 compliance. There was a marketplace for "big iron" RISC CPUs' IEEE-754 FP32/FP64 compliant FPU.

PC GpGPU's IEEE-754 improves over time.

IBM Power9 has hardware quadruple-precision floating-point (FP128) format support, hence Power9 has a market niche.

Quote:

A quirk of Neon in Armv7 devices is that it flushes all subnormal numbers to zero, and as a result the GCC compiler will not use it unless -funsafe-math-optimizations, which allows losing denormals, is turned on. "Enhanced" Neon defined since Armv8 does not have this quirk, but as of GCC 8.2 the same flag is still required to enable Neon instructions. On the other hand, GCC does consider Neon safe on AArch64 for Armv8.

ARMv8's NEON is IEEE 754 compliant.

ARMv7 is obsolete.

Last edited by Hammer on 17-Mar-2025 at 01:13 AM.
Last edited by Hammer on 16-Mar-2025 at 11:25 PM.
Last edited by Hammer on 16-Mar-2025 at 11:21 PM.
Last edited by Hammer on 16-Mar-2025 at 11:20 PM.

_________________
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

@Lou

Quote:

Lou wrote: Wii U's IOS is pretty well documented and that's why it has a huge homebrew community. Who got sued over Moana? This community needs to be like NIKE and just do it! The Wii U is 3x more powerful than a SAM460 if all 3 cores are used and uses 800Mhz DDR3 ram (vs 533mhz DDR2) which again is faster than the SAM460. Also has more cpu cache. Double, I believe...if not more overall. At worst, it's a PPC 750 single core running as fast as a SAM460 (vs 440 core) with much faster RAM and much more cpu cache. Diety_of_choice forbid that good cheap PPC hardware actually exists!

Hey, I get it.
As a person who once used Original Xbox consoles from Ebay as a cheap source of integrated boards for a Linux-based on-premise network and systems monitoring appliance, believe me when I say that I hate to see perfectly usable hardware going to waste.

The problem is that you keep using the term "community" when referring to the patchwork of developers in the contemporary Amiga-sphere. My MO leans toward "ask for forgiveness instead of permission", but there is no one around to "Just Do It" with AROS PPC, let alone MorphOS or AmigaOS.

In case you haven't noticed, when it comes to Amiga, PPC is dead. Hyperion are trying to make money from OS 3.x for 68k, MorphOS are moving to another ISA, there's more AROS 68k action than AROS x86, Apollo have an FPGA-based 68080 and their own AROS 68k spin, and AmigaKit are riding the emulation on ARM wave with their A600GS and the soon to be released A1200NG with 68k and ARM binaries in their Amibench OS.

Maybe if this Wii U opportunity availed itself in 2018, things would be different. But in the here and now of 2025, outside of a hundred or so die-hards, no one cares about PPC. The Wii Us could literally be FREE and it wouldn't move the needle forward for anything Amiga on PPC.

The availability of cheap and usable hardware around the 1GHz to 1.4GHz mark is not the problem. The lack of developers is the problem.
So, for what remains of us Amiga nostalgianerds, it is just as challenging to get anything Amiga ported to the Wii U, as it would be to port to a Raspberry Pi or AMD APU.
When there are no developers willing to port, then all ports are equally unachievable.

_________________
All the way, with 68k

@Kronos

Quote:

Kronos wrote: @Lou So I'd need my WiiU jail broken, break out the soldering iron to get some storage in only to have something that (if supported) does the same resolution as MacMini while being lower or the same on single core performance? So yeah, I'll just buy a Mini if I ever wanted to back such levels of HW. Point is not that a WiiU port is a bad idea, it is just that MacMini port would yield the same results at the same or lower efforts needed. Even if you you'd had to start from scratch that is.

That's the usual non-sense which Lou spreads when talking about technical "solutions": people should iron soldering their stuff to only slightly overcame the intrinsic limits of a platform...


@Hammer

Quote:

Hammer wrote: Y-cruncher test floating point with vector math support e.g. AVX-512. Y-cruncher also open source like 7ZIP.

Y-cruncher is pure crap as benchmark.


As well as Cell and XBox360's CPU were pure crap as CPUs.

@cdimauro

Quote:

people should iron soldering their stuff to only slightly overcame the intrinsic limits of a platform

As we have also needed to do with our real Amiga systems.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

As well as Cell and XBox360's CPU were pure crap as CPUs.

PPE is more less a normal CPU core, SPE was a streaming core, not to be consumed with the other SPE SIMD in AmigaONE-X1222, oh.. I hate when they use the shoring.

SPE (Synergistic Processing Element) vs SPE (Signal Processing Engine)
KVM (Kernel virtual Machine) or (Kyeboard, Video, Moue)
UML (User Mode Linux) or UML (Unified Modeling Language)

Completely different things..

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

@kolla

Quote:

kolla wrote: @cdimauro Quote: people should iron soldering their stuff to only slightly overcame the intrinsic limits of a platform As we have also needed to do with our real Amiga systems.

Sure. All 6 million customers which had an Amiga were forced to fix them with iron soldering before using their new toys...


@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: As well as Cell and XBox360's CPU were pure crap as CPUs. PPE is more less a normal CPU core, SPE was a streaming core, not to be consumed with the other SPE SIMD in AmigaONE-X1222, oh.. I hate when they use the shoring. SPE (Synergistic Processing Element) vs SPE (Signal Processing Engine) KVM (Kernel virtual Machine) or (Kyeboard, Video, Moue) UML (User Mode Linux) or UML (Unified Modeling Language) Completely different things..

Yes, but I was just referring to the CPU cores. So, certainly the PPE on Cell, but also its SPE cores.

@cdimauro

Quote:

All 6 million customers which had an Amiga were forced to fix them with iron soldering before using their new toys.

That wasn’t the premise here. The context was «to only slightly overcame the intrinsic limits» in order to achieve something the platform perhaps wasn’t built for. But _real_ Amiga? From modding cables for A1000, chipram and other fixes on A500/A2000, interrupt line fix on A3000, not to mention all the fixes potentially needed on A1200 for timing, pcmcia, clockports…

Last edited by kolla on 24-Mar-2025 at 01:23 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @cdimauro Quote: All 6 million customers which had an Amiga were forced to fix them with iron soldering before using their new toys. That wasn’t the premise here. The context was «to only slightly overcame the intrinsic limits» in order to achieve something the platform perhaps wasn’t built for. But _resl_ Amiga? From modding cables for A1000, chipram and other fixes on A500/A2000, interrupt line fix on A3000, not to mention all the fixes potentially needed on A1200 for timing, pcmcia, clockports…

I've no problem to accept that SOME users tinkered with their toys and iron soldered them to fix issues and/or enable new features. The world never stopped to have geeks/nerds doing such things.

However, those are niche of the overall market: normally customers use / have used their new toys out of the box, WITHOUT requiring any iron soldering.

@cdimauro

Quote:

However, those are niche of the overall market: normally customers use / have used their new toys out of the box, WITHOUT requiring any iron soldering

Do you find adding a CPU board with onboard I/O - such as a CyberStorm with onboard SCSI controller - a "niche" product for A3000 owners? Normally you're only happy to jump on the old Amiga engineers for anything, yet here you are defending their flaws and mistakes as "niche" cases?! This is rather funny.

Anyways, the context in which this whole "soldering" thing came up, is specifically _not_ the so called "normal out of the box users".

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @cdimauro Quote: However, those are niche of the overall market: normally customers use / have used their new toys out of the box, WITHOUT requiring any iron soldering Do you find adding a CPU board with onboard I/O - such as a CyberStorm with onboard SCSI controller - a "niche" product for A3000 owners?

A3000 is already a niche product, so yes.
Quote:

Normally you're only happy to jump on the old Amiga engineers for anything,

No, I report FACTS. Something that you continuously forget.
Quote:

yet here you are defending their flaws and mistakes as "niche" cases?! This is rather funny.

It's funny because it's NOT true. That's YOUR INVENTION.
Quote:

Anyways, the context in which this whole "soldering" thing came up, is specifically _not_ the so called "normal out of the box users".

Good. At least this was clarified, and that's exactly the reason why previously I've written this:

"All 6 million customers which had an Amiga were forced to fix them with iron soldering before using their new toys."

@cdimauro

Quote:

Y-cruncher is pure crap as benchmark.

Cinebench 2024 doesn't properly benchmark vector 256bit AVX.

Quote:

As well as Cell and XBox360's CPU were pure crap as CPUs.

IBM PPEs are low price CPUs with SIMD VMX128(128 registers variant) bias.

After the original Xbox and without Bill Gates intervention, Intel didn't have a design win for the game console market.

IBM PPE has a single integer pipeline which is reminiscent of yet another poor man's 68040 class CPU, but with very high speed and attached 128-bit SIMD hardware.

It's an easy win for AMD's Jaguar when it competed against IBM PowerPC A2, ARM Cortex A15 and Intel Atom Saltwell (dual-issue superscalar but with in-order execution).

Intel lost Sony's PS6 contract due to the pricing issue. LOL
https://www.reuters.com/technology/how-intel-lost-sony-playstation-business-2024-09-16/

The good old price dispute.

Last edited by Hammer on 25-Mar-2025 at 05:15 AM.
Last edited by Hammer on 25-Mar-2025 at 01:43 AM.
Last edited by Hammer on 25-Mar-2025 at 01:40 AM.

_________________
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

@thread

Speaking of Windows NT4 and its usefulness, I'm reminded of a simple registry hack that a developer released at the time, which presented the OS as a Windows Server.

Microsoft, then an now, are the reigning kings of OS SKU's and editions. Though Windows NT Server 4 was built from the same code base as the workstation OS, they wanted to charge those who ran servers more for essentially the same OS. Want to run an Exchange server? You need to pay for the server OS license + seats, and then the MS Exchange server license + seats.

With the useful registry hack, one could run MS Exchange server on NT Workstation OS, saving money on licensing. Just don't go sending NT sysinfo data to MS during a support call.

Also during that time, I was working at a small web hosting company which was running Windows NT 4 Server on a DEC Alpha server at an eye-watering speed of 500MHz. Twice the speed of a then Pentium II.

In a couple years it was all over. x86 CPUs reached 1GHz, could do multi-socket, and were much cheaper than their RISC workstation/server competition. Then threading, 64-bit and multi-core, and now we walk around with 20-core CPUs in our pockets.

I suppose in a roundabout way I'm asking just how "great and useful" is Windows NT4 PPC in 2025?

_________________
All the way, with 68k

@agami: wrong thread?

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Y-cruncher is pure crap as benchmark. Cinebench 2024 doesn't properly benchmark vector 256bit AVX.

Then select another real world application that does it.
Quote:

Quote: As well as Cell and XBox360's CPU were pure crap as CPUs. IBM PPEs are low price CPUs with SIMD VMX128(128 registers variant) bias. After the original Xbox and without Bill Gates intervention, Intel didn't have a design win for the game console market. IBM PPE has a single integer pipeline which is reminiscent of yet another poor man's 68040 class CPU, but with very high speed and attached 128-bit SIMD hardware.

Whatever: it remains a crappy CPU.

If you're not an expert to judge yourself, then take a look at PS3 and Xbox360 developers' comments on Beyond3D.
Quote:

It's an easy win for AMD's Jaguar when it competed against IBM PowerPC A2, ARM Cortex A15 and Intel Atom Saltwell (dual-issue superscalar but with in-order execution). Intel lost Sony's PS6 contract due to the pricing issue. LOL https://www.reuters.com/technology/how-intel-lost-sony-playstation-business-2024-09-16/ The good old price dispute.

Irrelevant.

Last edited by cdimauro on 25-Mar-2025 at 05:35 AM.

@agami

Quote:

agami wrote: @thread Speaking of Windows NT4 and its usefulness, I'm reminded of a simple registry hack that a developer released at the time, which presented the OS as a Windows Server. Microsoft, then an now, are the reigning kings of OS SKU's and editions. Though Windows NT Server 4 was built from the same code base as the workstation OS, they wanted to charge those who ran servers more for essentially the same OS. Want to run an Exchange server? You need to pay for the server OS license + seats, and then the MS Exchange server license + seats. With the useful registry hack, one could run MS Exchange server on NT Workstation OS, saving money on licensing. Just don't go sending NT sysinfo data to MS during a support call. Also during that time, I was working at a small web hosting company which was running Windows NT 4 Server on a DEC Alpha server at an eye-watering speed of 500MHz. Twice the speed of a then Pentium II. In a couple years it was all over. x86 CPUs reached 1GHz, could do multi-socket, and were much cheaper than their RISC workstation/server competition. Then threading, 64-bit and multi-core, and now we walk around with 20-core CPUs in our pockets. I suppose in a roundabout way I'm asking just how "great and useful" is Windows NT4 PPC in 2025?

Well, obviously it's way more useful than AOS.

Personally, I run Hmailserver for my business ... which does not require a 'sever' OS.
https://www.hmailserver.com/