Intel disaster.

Lol yeah ask them about, print master or norton commander or about pain :) I am pretty much from the 286 monchome era.

I was one of the larney kids because we had this beast....had a enough space a whopping 5mb at the time....:). You don't know what pain and suffering is unless you had a two floppy disk system, you boot from one and run whatever program from the other.

Ask them gen z what the turbo button did......wrong answers only.

View attachment 1780405
That's a standard ST-506 hard disk and I know how to interface to that beast.
 
Not that simple, do you know how many system still use fortran today as an example a language developed in 1957.....there are some large industrial hardware that still run on 1980s, 1990s x86 hardware


The 737 max and airbus A320 STILL uses 286 single core cpus, these older CPUs and hardware, is about stability, safety and certification. In the aeronautical space 80286 is still very much a thing. In some instances, there simply isn't an alternative. You have no idea how many banking system across the world still rely on old 20th century computer hardware.

Sadly NEWER isn't always better.....
That's what I said... I can't provide specifics because I am still under NDA but ABSA bank is a particular dinosaur in this regard.
 
Couple of points:
  • Calling ARM vs x86 a RISC vs CISC arguement is a bit of a misleading distinction nowadays tbh.
Fine, x86 vs anything else.

  • The M4 Mac mini is the best priced desktop PC on the market by far. You cannot build a desktop PC with its performance for its price.
It's out of the price range of more than half of the market, it can't be upgraded, and can't be maintained much past its service life. R 13k not far from triple the price of a basic home PC (still double once you add a Windows license), and well into the price range of a gaming PC.

There's a massive difference between price/performance, and being affordable to the masses.

  • ARM has absolutely proven itself to be a viable alternative to x86 for desktop PCs. Microsoft has thrown themselves fully into ARM as well. Windows ARM runs very nicely on my M4 via UTM.
  • Power usage is also highly relevant for data center usage.
ARM has has a long way to go in proving itself, not least of which is compatibility. Nobody is saying it's a bad architecture, but mass adoption is, at a guess, decades away.

Then use that time to wait until you actually have something that can blow both Apple and AMD out the water. Releasing substandard products has proven to be a disaster for them.
It doesn't matter the resources you have, sometimes simulations and predictions are incorrect. That's how we ended up with Netburst and, now, Arrow Lake. The worst thing you can do is sit back and wait for your next architecture to come out, especially when your current (now prior) product had major flaws.

It has happened to everyone. It happened to AMD with K10, and this isn't Intel's first rodeo with a failed product. Regardless, they will continue to print money hand over fist. Retail Core Ultra CPUs are selling at an alarming rate, and SIs have started to introduce them.

I used to have an Athlon XP system I purchased in the early 2000s, I remember that machine fondly, it ran hot but it was a good machine. I still sold it for some money in 2011...
I loved mine. I had a JIUHB stepping 1700+ that ran in the 2.2 GHz range all day long, and then a Barton 2500+ which came darn close to 2.5 GHz 24/7. Unfortunately this was before the days of HWBot, and the results were uploaded to the long-gone ripping.org. I had so much fun on that platform (Abit NF7-S) that in the late 2000s I hunted down a 2600+, but it sucked - less than 2.5 GHz under phase change cooling.

Yeah I can google as well......
I can dodge that one, I covered it in a feature article I had published in 2013 about the first three decades of overclocking.

Last paragraph of page 22, spilling to page 23

That saying "I've forgotten more than you know" is so true, as I've probably forgotten half of what I knew back then.
 
ARM has has a long way to go in proving itself, not least of which is compatibility. Nobody is saying it's a bad architecture, but mass adoption is, at a guess, decades away.
Past decade of my life spent writing applications exclusively for ARM here... er... doesn't need to prove anything right now. It's a viable and very important alternative for embedded systems particularly.
 
It's out of the price range of more than half of the market, it can't be upgraded, and can't be maintained much past its service life. R 13k not far from triple the price of a basic home PC (still double once you add a Windows license), and well into the price range of a gaming PC.

There's a massive difference between price/performance, and being affordable to the masses.
It isn't. My wife's PC died a few months ago (before the M4 Mac mini was released annoyingly).

Screenshot 2024-12-11 at 16.32.08.png

I re-used the case, SSD and OS. I needed a decent CPU because she uses Inkscape to edit sewing pattern PDFs.

For her purposes, getting an M4 mini, which would take up a fraction of the space, and completely mogg that 5700G in terms of performance both in CPU and GPU, it was absolutely perfect.



ARM has has a long way to go in proving itself, not least of which is compatibility. Nobody is saying it's a bad architecture, but mass adoption is, at a guess, decades away.
I would give it 5 years at most. Remember, all the mobile phone manufacturers know how to make performant ARM devices for mobile.

You are already seeing Windows with ARM chips. Compatibility nowadays is actually insane. Both Rosetta 2 and Microsoft's equivalent of it work very well.
We have some archaic bluetooth serial library that was last updated in like 2008. So you are talking about replacing system calls to hardware with a compatibility layer. And the result is it works pretty much seamlessly.

Gaming is the only thing really left to x86 these days. Which I think is a perfectly decent niche to be in TBH.


It doesn't matter the resources you have, sometimes simulations and predictions are incorrect. That's how we ended up with Netburst and, now, Arrow Lake. The worst thing you can do is sit back and wait for your next architecture to come out, especially when your current (now prior) product had major flaws.

It has happened to everyone. It happened to AMD with K10, and this isn't Intel's first rodeo with a failed product. Regardless, they will continue to print money hand over fist. Retail Core Ultra CPUs are selling at an alarming rate, and SIs have started to introduce them..

Just remember, Intel completely lost out on the mobile segment by not being able to adapt their designs to meet mobile requirements. If they don't do the same now with laptops (and data centers I might add), they could be in for a world of hurt.
 
nvidia’s ARM cpu will handle gaming, it would be weird if it didn’t.
 
And then of course we have the court document leaks that Microsoft was considering switching to ARM64 for the next Xbox.
 
it's not as simple as saying x86 is better than ARM or ARM is better than x86

x86 can and does outperform ARM in high computational tasks, they always have as they have high clock speeds, x86 can perform more complex tasks. So CISC vs RISC is well in the name itself... ummm C = complex, R = reduced
x86 higher cache = more RAM = well, more high performance which is critical in say video editing or any memory intensive stuff.

ARM is catching up for sure, whether they actually surpass x86 in ALL aspects is yet to be seen. Maybe Ai can solve all that.

Just follow the porn industry, they've always led the way!
 
nvidia’s ARM cpu will handle gaming, it would be weird if it didn’t.
It depends, Yes and no, there is already ARM based laptops on the market snapdragon X and gaming isn't al rosy either, it depends on support, from the developer as well as the driver support. As pointed out, if the game requires AVX2 or any other x86 features your shyte out of luck.

Commercial game engines that currently has multi-platform support, has mobile ARM support, but this is heavily geared to mobile platform and not a fully fledged ARM PC or laptop running windows.

If you were to run some stuff it would be via hardware/software emulation and if you don't know by now it is already a hit and miss.

ARM is A LONNNNNNNNNG way from being a x86 desktop replacement for gaming, for other workloads and general computing not a problem, the x86 is old and very much established.

I am speaking from experience having been a game developer for the past 20+ years.
 
Its much the same as IBM died mantra.

They made massive missteps which cost them market share, and even markets themselves.. but the company never died and has a market cap of over 200 billion dollars today.
They still hold a massive market on storage, especially tape. Guess what a lot of cloud uses
 
They still hold a massive market on storage, especially tape. Guess what a lot of cloud uses
Well for the cheap nasty storage tiers yes.

But yup in the server and especially mainframe space, IBM is still a market giant and that isn't going to change anytime soon.
 
Well for the cheap nasty storage tiers yes.

But yup in the server and especially mainframe space, IBM is still a market giant and that isn't going to change anytime soon.
Well yeah, for the tiers that actually make sense for cloud.
 
it's not as simple as saying x86 is better than ARM or ARM is better than x86

x86 can and does outperform ARM in high computational tasks, they always have as they have high clock speeds, x86 can perform more complex tasks. So CISC vs RISC is well in the name itself... ummm C = complex, R = reduced
x86 higher cache = more RAM = well, more high performance which is critical in say video editing or any memory intensive stuff.

ARM is catching up for sure, whether they actually surpass x86 in ALL aspects is yet to be seen. Maybe Ai can solve all that.

Just follow the porn industry, they've always led the way!
Um nooo.......time for your realty check to be "cached"


FYI Snapdragon X, has 45mb cache

14900K as an example
Number of Cores24 (8 x P-Cores + 16 x E-Cores)
Number of Threads32
Base Clock SpeedP-Core: 3.2 GHz E-Core: 2.4 GHz
Maximum Boost SpeedP-Core Thermal Velocity Boost: 6 GHz P-Core Turbo 3.0: 5.8 GHz P-Core Turbo: 5.6 GHz E-Core Turbo: 4.4 GHz
L3 Cache36 MB

Versus snapdragon X elite.

Clock Rate3800 - 4200 MHz
Number of Cores / Threads12 / 12
12 x 4.2 GHz Qualcomm Oryon
TDP Turbo PL280 Watt
Manufacturing Technology4 nm
GPUQualcomm SD X Adreno X1-85 4.6 TFLOPS
64 Bit64 Bit support
 
Um nooo.......time for your realty check to be "cached"


FYI Snapdragon X, has 45mb cache

14900K as an example
Number of Cores24 (8 x P-Cores + 16 x E-Cores)
Number of Threads32
Base Clock SpeedP-Core: 3.2 GHz E-Core: 2.4 GHz
Maximum Boost SpeedP-Core Thermal Velocity Boost: 6 GHz P-Core Turbo 3.0: 5.8 GHz P-Core Turbo: 5.6 GHz E-Core Turbo: 4.4 GHz
L3 Cache36 MB

Versus snapdragon X elite.

Clock Rate3800 - 4200 MHz
Number of Cores / Threads12 / 12
12 x 4.2 GHz Qualcomm Oryon
TDP Turbo PL280 Watt
Manufacturing Technology4 nm
GPUQualcomm SD X Adreno X1-85 4.6 TFLOPS
64 Bit64 Bit support
Someone links LTT.. my eyes glaze over and i skip the post :P The guy doesnt even know what raid 1/5 is without googling it.
 
Indeed, the forum is chock full with Gen Z that got lured into the front door in droves with all the click bait
I can also see in the responses to this thread who are coders and who aren't. I was going to write a long reply but it's a waste of my time.

I used to have an Athlon XP system I purchased in the early 2000s, I remember that machine fondly, it ran hot but it was a good machine. I still sold it for some money in 2011...

In recent months I've decided to just stop sharing knowledge because there's always some know-it-all that comes along with this MBA mindset or their freshly minted Stellenbosch indoctrination to tell us old-timers we're wrong.
I've been familiar with the Intel product since the 8085, 8086, and later. Intel have at several times even advocated for dropping the architecture because it is a drag on innovation, yet they keep finding ingenious ways to keep it competitive in terms of performance.

ARM is a superior architecture, in terms of every kind of metric, code execution, raw speed, and power consumption. Even Microsoft Windows has had ARM versions for ages now. It has not been so much about standards, rather about compatibility. The main thing today is that an awful lot of important software still runs on x86 hardware and the legacy will take a long time to shift. Trillions of lines of code need to be ported, you know how long that will take- decades.
Uhh nani?
 
Um nooo.......time for your realty check to be "cached"


FYI Snapdragon X, has 45mb cache

14900K as an example
Number of Cores24 (8 x P-Cores + 16 x E-Cores)
Number of Threads32
Base Clock SpeedP-Core: 3.2 GHz E-Core: 2.4 GHz
Maximum Boost SpeedP-Core Thermal Velocity Boost: 6 GHz P-Core Turbo 3.0: 5.8 GHz P-Core Turbo: 5.6 GHz E-Core Turbo: 4.4 GHz
L3 Cache36 MB

Versus snapdragon X elite.

Clock Rate3800 - 4200 MHz
Number of Cores / Threads12 / 12
12 x 4.2 GHz Qualcomm Oryon
TDP Turbo PL280 Watt
Manufacturing Technology4 nm
GPUQualcomm SD X Adreno X1-85 4.6 TFLOPS
64 Bit64 Bit support
I can't take anyone or any post serious if it contains a Linus Tech Tips or Asmongold video.
 
Last edited:
it's not as simple as saying x86 is better than ARM or ARM is better than x86

x86 can and does outperform ARM in high computational tasks, they always have as they have high clock speeds, x86 can perform more complex tasks. So CISC vs RISC is well in the name itself... ummm C = complex, R = reduced
x86 higher cache = more RAM = well, more high performance which is critical in say video editing or any memory intensive stuff.


ARM is catching up for sure, whether they actually surpass x86 in ALL aspects is yet to be seen. Maybe Ai can solve all that.

Just follow the porn industry, they've always led the way!
Just stop.

If what you are saying is true, then the compiled assembly for ARM would be longer than the equivalent x86 assembly. Except that isn't the case.

using the excellent godbolt site
https://godbolt.org

For the following C++ program:
C++:
#include <iostream>

int main() {
    long long sum = 0;
    int iterations = 1000000;

    for (int i = 0; i < iterations; ++i) {
        sum += i;
    }

    double average = static_cast<double>(sum) / iterations;
    std::cout << "Average: " << average << std::endl;

    return 0;
}

Using GCC for both.

x86 assembly:

Code:
main:
        push    {lr}
        movs    r2, #9
        movw    r1, #:lower16:.LANCHOR0
        movt    r1, #:upper16:.LANCHOR0
        sub     sp, sp, #12
        movw    r0, #:lower16:std::cout
        movt    r0, #:upper16:std::cout
        bl      std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, int)
        vldr.64 d0, .L8
        movw    r0, #:lower16:std::cout
        movt    r0, #:upper16:std::cout
        bl      std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)
        ldr     r2, [r0]
        mov     r3, r0
        ldr     r2, [r2, #-12]
        add     r2, r2, r0
        ldr     r0, [r2, #124]
        cbz     r0, .L7
        ldrb    r2, [r0, #28]   @ zero_extendqisi2
        cbz     r2, .L3
        ldrb    r1, [r0, #39]   @ zero_extendqisi2
.L4:
        mov     r0, r3
        bl      std::basic_ostream<char, std::char_traits<char> >::put(char)
        bl      std::basic_ostream<char, std::char_traits<char> >::flush()
        movs    r0, #0
        add     sp, sp, #12
        ldr     pc, [sp], #4
.L3:
        strd    r0, r3, [sp]
        bl      std::ctype<char>::_M_widen_init() const
        ldr     r0, [sp]
        movs    r1, #10
        ldr     r2, [r0]
        ldr     r2, [r2, #24]
        blx     r2
        ldr     r3, [sp, #4]
        mov     r1, r0
        b       .L4
.L7:
        bl      std::__throw_bad_cast()
.L8:
        .word   0
        .word   1092519038

ARM assembly:
Code:
.LC0:
        .string "Average: "
main:
        mov     edx, 9
        sub     rsp, 24
        mov     esi, OFFSET FLAT:.LC0
        mov     edi, OFFSET FLAT:std::cout
        call    std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)
        movsd   xmm0, QWORD PTR .LC1[rip]
        mov     edi, OFFSET FLAT:std::cout
        call    std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)
        mov     rdx, rax
        mov     rax, QWORD PTR [rax]
        mov     rax, QWORD PTR [rax-24]
        mov     rdi, QWORD PTR [rdx+240+rax]
        test    rdi, rdi
        je      .L5
        cmp     BYTE PTR [rdi+56], 0
        je      .L3
        movzx   eax, BYTE PTR [rdi+67]
.L4:
        mov     rdi, rdx
        movsx   esi, al
        call    std::basic_ostream<char, std::char_traits<char> >::put(char)
        mov     rdi, rax
        call    std::basic_ostream<char, std::char_traits<char> >::flush()
        xor     eax, eax
        add     rsp, 24
        ret
.L3:
        mov     QWORD PTR [rsp+8], rdx
        mov     QWORD PTR [rsp], rdi
        call    std::ctype<char>::_M_widen_init() const
        mov     rdi, QWORD PTR [rsp]
        mov     esi, 10
        mov     rax, QWORD PTR [rdi]
        call    [QWORD PTR [rax+48]]
        mov     rdx, QWORD PTR [rsp+8]
        jmp     .L4
main.cold:
.LC1:
        .long   0
        .long   1092519038

ARM assembly is 45 lines
x86 assembly is 43 lines

Which actually means there is basically zero difference in terms of "complexity" of instructions between these instruction sets. (at least for a simple program like this.)


Primagen did a really high quality video on this going over some hackaday article saying how x86 needs to die. Point being is that both ARM and x86 instruction sets are actually quite complex nowadays.
 
Top
Sign up to the MyBroadband newsletter
X