The Fall of Intel

We have heard repeatedly that x86 works just like RISC internally, which is fundamentally not the case because of the basic architechure – RISC uses instruction repurposing and flexibility in ways that x86 simply cannot. Still, the μop implementation might offer a way out for them: they might be able to expose the inner architecture to an alternate coding framework, which could allow full modal x86 backward compatibility along with a more efficient ISA mode to transition to. If they could do that, there could well be life left in their old beast.

As far as code density goes, x86-64 does not really have an advantage there. The stats I have seen show ARM code having an edge much of the time, and R-V can go even denser with their thumbish coding scheme.
 
Cmaier said:
Probably I’d (1) fully embrace the future, which will be RISC chips with integrated graphics solutions. So I’d set my design teams on that. Arm with integrated graphics, aiming to destroy QC at that game, and offering customers the ability to get custom designs - let dell pick how many cores, how many graphics cores, pick from a menu of IP blocks, etc. (2) spin off the fabs. (3) put minimal efforts into x86-64 compatible designs. x86-64 isn’t long for the world, and “lots of people still buy them” were the last words of lots of tech companies in the past.
Click to expand...
Good points. However, I suspect its hard for a company like Intel (with a reputation of being rather conservative) to fully understand that the business model (and/or product) that basically defines the company (and has been a money making machine for decades) is about to become obsolete.
 
Agent47 said:
Good points. However, I suspect its hard for a company like Intel (with a reputation of being rather conservative) to fully understand that the business model (and/or product) that basically defines the company (and has been a money making machine for decades) is about to become obsolete.
Click to expand...

That’s one of the reasons Gelsinger was a dumb hire. They needed an outsider with a track record of correctly seeing which way the market is going.
 
Cmaier said:
Nobody at Intel is under the misapprehension that x86-64 can win, long term. The only inherent advantage it might have is instruction density.
Click to expand...

And even that is no longer the case:

Debunking CISC vs RISC code density – Bits'n'Bites

www.bitsnbites.eu www.bitsnbites.eu

Also, the code itself is just a fraction of the data on our mass storages (and in RAM) these days that these small differences don't matter any longer.
 
KingOfPain said:
Also, the code itself is just a fraction of the data on our mass storages (and in RAM) these days that these small differences don't matter any longer.
Click to expand...

Unless you are using C++ templates so heavily that you start hitting the limits of what Apple's static analysis for the App Store can handle and start getting rejections due to "your TEXT segment is too large". :)
 
mr_roboto said:
@Nycturne Is that one of those jokes which aren't a joke? Because if so I bet you have some interesting war stories about it. ;)
Click to expand...

It's a real thing. The first time I found out about it, the limit was ~50MB for the TEXT segment. It changed quickly and repeatedly in fairly short order at that point in time because I don't think Apple was seriously expecting a single TEXT segment to be that large. But yes, my job at one point was to investigate why we exceeded the limit, which included writing tools that did a fairly rough "blame" on the TEXT segment itself by estimating the size of the symbols and letting us look at it by namespace / static lib. (EDIT: At this point in time, our executable was something like 25-33% of the total bundle size, IIRC)

At the time, I hadn't really dug deep into the guts of C++ templating yet in my career, so it was a bit of a crash course on the internals of C++ template code-gen. That knowledge came in handy later when a co-worker was trying to debug a crash in C++ that made no sense. Turns out there were two versions of a specific class template with different v-table layouts included by different libraries. And the linker as it noticed the duplicated generated functions, proceeded to create a final binary that was a mix of both versions. So function A would call function B, but function A had the 'v1' v-table, and used the wrong function offset for the actual object which was created with the 'v2' allocator. (EDIT: This whole thing is one reason why I'm an advocate for Swift/Rust these days)

We weren't even the only ones to run into this, now that I look around a little:

How can i reduce __TEXT segment si… | Apple Developer Forums

forums.developer.apple.com forums.developer.apple.com
stackoverflow.com

How can i reduce __TEXT segment size in iOS App?

My App failed to submit due to app size problem before, and the following build options were applied. So I could submit an app. *. Dead Code Stripping(DEAD_CODE_STRIPPING) : YES *. Enable C++ Exce...
stackoverflow.com stackoverflow.com
 
Last edited:
Nycturne said:
Unless you are using C++ templates so heavily that you start hitting the limits of what Apple's static analysis for the App Store can handle and start getting rejections due to "your TEXT segment is too large". :)
Click to expand...

Only slightly off-topic, because it is related to a x86 design limitation...

At one company I had to use a RAD tool called Clarion for Windows. I would be surprised if anyone here has heard of it.
An database application was described in two files: an APP file, which defined the GUI and code segments, and the DICT file, which described the database.
During the build process rules that Clarion called "templates" described how the actual code was generated with the information from the APP file. Then the generated code would be run through the compiler.

After an update of Clarion, at least one of the applications would no longer build.
I found out that the subroutine that was generally used to open all the files in a module (in this case actually database tables) was too big for the compiler (I cannot remember what the size limitation was here).
I spent some time to rewrite the template to put the file opening code in several smaller subroutines. Then the compile run was successful.
But the linker choked, because the resulting object file was larger than 64K!

Eventually, I found out that the Clarion update ignored a flag in the DICT file that defined that only files that are actually used by the module should be opened in the subroutine.
I hadn't thought of that at first, because prior to this problem I never had to work directly with those templates before.
After I fixed the template to recognize that flag again, the whole build was fine.

But the really funny thing about that was the fact that we had been using Windows NT for quite a while, but still had to build 16-bit applications, because one single customer was still using Windows for Workgroups 3.11, yay!
 
Perhaps less important but still:

www.anandtech.com

Intel Postpones Innovation 2024 Event, Cites Poor Finances

www.anandtech.com www.anandtech.com

Innovation is Intel’s regular technical showcase for developers, customers, and the public, and is the successor to the company’s legendary IDF show. In recent years the show has been used to deliver status updates on Intel’s fabs, introduce new client platforms like Panther Lake, launch new products, and more.
Click to expand...

But after 3 years of shows, the future of Innovation is up in the air, as Intel has officially postponed the show – and with a less-than-assuring commitment to when it may return.
Click to expand...
 
Nycturne said:
Turns out there were two versions of a specific class template with different v-table layouts included by different libraries. And the linker as it noticed the duplicated generated functions, proceeded to create a final binary that was a mix of both versions.
Click to expand...
That sounds horrifying.
 
Andropov said:
That sounds horrifying.
Click to expand...

It’s a side effect of two different design decisions of C++. The v-table and template symbol deduplication. In C++, your ‘ptrToObject->virtualFunction()’ is really something like ‘ptrToObject->__vtable[2]()’ under the hood. So what happens when you take header v1, and insert a virtual function at the front rather than append it? Well, your function indexes no longer match. The above now becomes ‘ptrToObject->__vtable[3]()’ when using v2 of this header. As you could imagine, this does lead to crashes all on its own without templates getting involved, but it’s usually cleaner separation between the caller outside a module, and the class inside a module when this occurs.

The other bit is that when using templates, because different object files can have implementations for the same template function, the linker deduplicates template symbols, rather than throw a duplicate symbol error. But this means having two different versions of a header that aren’t properly versioned gets you into big trouble as the linker can easily mix and match and give you a Frankenstein set of symbols out the other end. This is what made this particular bug difficult, as it meant using static analysis of binaries to find out what modules were contributing the offending symbols due to a "too many 3rd party dependencies" problem with the project. The symbols didn’t come from the library, but rather two different consumers of the library.

The other ugly thing is that it’s possible to convert pointers into references, and get null dereference crashes in a function that only uses a reference (and thus no null checks). All because the caller didn’t null check before converting to a reference. Fun.

While C++ does add nice features, including ones meant to make some mistakes harder to make, the design is such that I’d consider it easier to write reliable C code than C++.
 
Intel always has their fab to fall back on. And I think they own IP on USB and TB, so they will get a little revenue there.
 
Yoused said:
I am sad/not-sad. To me, the biggest contribution they made to the industry has been to set a standard that basically almost anyone with some imagination can do better than. But there is so much out there that is better these days that Intel's usefulness has expired.
Click to expand...

I'm annoyed that their busted architecture basically set computing back a decade or two due to the primary platform (the PC) making use of it.

We had full flat 32 bit memory model in the late 1970s with the 68k and due to dirty tricks against AMD in the 90s and 2000s where they almost sent AMD broke via basically bribing OEMs to not use competitor products we were stuck on 4 cores for about a decade until Zen shook things up.

Ditto for duping the high performance computing market into itanic and killing off MIPS, PPC, etc. in the process.

I shed no tears for intel; the PC has been responsible for the death of a bunch of interesting platforms in the past and intel has been largely responsible for the PC architecture being so damn mediocre for so long.

We could and should have had far better.

2c.
 
throAU said:
Is this the fab crew that got stuck on 14nm for a decade and shat out 10nm that barely worked?
Click to expand...
Was it the process that was broken or the implementation of the bailing wire and bubblegum architecture? Maybe if they can put more effort into the fab by putting less into trying to make x86 run properly, it will work better.
 

Similar threads

Jimmyjames
Microsoft: "DirectX Adopting SPIR-V as the Interchange Format of the Future"
Replies
2
Views
90
leman
L
Colstan
  • Poll Poll
End of days: Intel Macs - for whom the bell tolls.
2
Replies
27
Views
2K
Yoused
Yoused
Cmaier
Intel to lay off thousands
Replies
8
Views
606
Yoused
Yoused
Jimmyjames
Geekerwan’s Review of the Snapdragon 8 Gen 3 (Xiaomi 14).
4 5 6
Replies
112
Views
7K
dada_dave
D
Eric
17-year-old discovers planet 6.9 times larger than Earth on third day of internship with NASA
Replies
2
Views
411
Nycturne
Nycturne
Back
Top