>be released in '95
>cranks out 3 instructions per cycle
>fast forward 30 years
>still at 3-4 instructions per cycle (per core)
why haven't we improved?

>>105808888 (OP)
That said I have a dual Pentium Pro with 128MB of memory collecting dust, what can I do with it?

>>105808888 (OP) (checked)
Use case for more instructions per cycle?

>>105808888 (OP)
Intel cpus actually went backwards in some cases.

>>105808931
Sell it to retroomers.

>>105808888 (OP)
We have this every week
https://wiki.installgentoo.com/wiki/Stagnation

>>105808935
Do morer stuff fasterer

>>105808888 (OP)
why have stopped making cpus look this beautiful?

>>105808888 (OP)
Tragically, the Terbium was terminated. it was our last best hope.

>>105808931
>what can I do with it?
I still use a dual Pentium Pro server, it is rock solid, and predates the mandated backdoors. It runs rather hot, unfortunately.

>>105808888 (OP)
p5 could issue 3 instructions per cycle in limited scenarios
shitass lion cove can issue 12 instructions per cycle in limited scenarios

>>105809258
p6*
p5 was only dual issue

>>105808888 (OP)
That core design wouldnt work at 6ghz even if you produced it with the latest tech.

>>105808972

>>105809423
>Alpha
Never forget what Itanium took from us.

>>105808888 (OP)
>still at 3-4 instructions per cycle (per core)
And good luck feeding that core with pre 2010 caches and branch predictors. Parallelizing is hard, it turns out that without explicit parallelization, a strategy that failed, you're better improving everything else than wasting silicon in more idle blocks.
After 2010 cpus got far better with their branch prediction and chaches so current cores can multitasking more without the penalties in area and power of the old times because nodes improved and the power gating is far more aggressive.
For some task hard to predict the improvement isn't proportional to the width of current cores.

>>105809284

>>105809258
Ibm POWER could do 5 inst/cycle in 1990.

Another thing that powerpc still dominates at is multi-cpu. Intel is stuck at around 1 now, somewhat down from power’s 128. Remember BeOS?
That came from mainframes which have insane I/O capabilities with 256 front-side busses.

>>105809284
> 6 GHz
It could be re-designed to be much faster and on a modern process.

The old z80 is still around, in TI calculators for example, now typically runs at 50 MHz and every instruction is 1 clock/cycle.

To put that into perspective, one could put 3–4 thousand P6 cores on a modern chip die(set).
… and a ridiculous number of z80 cores.
Let’s not worry about how you’re going to (inter)connect them.

>>105809545
> Itainium killed Alpha?
Interesting conspiracy theory.
At the time, PA-RISC had the highest instructions/clock of any processor arch by a big margin, so I’d argue it was a bigger loss.
I remember Alpha as being more of a “toaster”

The biggest historical loss was unquestionably the motorola 680xx, and way before that, the 6809.

>>105809284
> core design wouldnt work at 6ghz
“6 GHz” is probabably about as directly relevant as “nm” is nowadays. What it actually and meaningfully means is debatable.
CPUs are fed with (typically) a 200 MHz clock and use PLLs to boost it for various things.
Even the 8080 used a multi-phase clock.

Only benchmarks matter.

>>105808888 (OP)
Well how long are the cycles?

>>105809857
>visa revoked

>>105809423
what are those nipples used for? they could not be watercooling it at that time?

>>105810256
They're threaded, you keep the heatsink on with nuts

>>105808972
you had p2s and p3s in cartridge form, that was ugly as fug

..eeew..

>>105808888 (OP)
>thinking Israel Inside cares about CPU performance
they're on record prioritizing geopolitics which is code for supporting Israel
https://mitsloan.mit.edu/ideas-made-to-matter/how-intels-cfo-threads-needle-geopolitics-and-more

>>105810569
slotted cpus are cool
you have no taste

>>105810614
real beauty

>>105808931
code on it

>>105810314
holy shit, that is some peak engineering right there. how come we have lost this knowledge?

>>105808931
oh man when I was a kid, there was one another one, his father must have been fucking loaded he had rig like that

>>105808888 (OP)
The dual socket Pentium III 866 MHz was probably my favorite PC of all time. It was so obnoxiously fast running Linux that it might just have been the pinnacle of civilization.

>>105810629
Prioritizing? It’s a little more than that.
More like “Sacrificing its existence to prop up with it’s last gasp”

>>105808888 (OP)
this is what itanium unironically was supposed to fix, vliw architectures can execute what would be many instructions as 1 big instructions
and run them in parallel , unfortunately compiler performance is tricky on those cpus, the transmeta cpus were probably the best attempt at a native vliw cpu. I believe the russian elbrus cpus are also vliw.

>>105808931
you can stuff it into your ass

>>105808938
>>105808931
>>105808888 (OP)

does Pentoium 4 run 8 instructions per cycle?

>>105811456
No

>>105809715

there were news about z80 production line stopping

There are practical limits because of how serial-dependent typical code is in CPU workloads. It isn't beneficial to be able to execute 100 instructions per cycle if, for most workloads, you can only discover 4 threads of ILP to execute simultaneously, the other execution units will just sit idle. You could increase the window of instructions to scan for ILP threads, but now if you mispredict a branch you have to flush a deeper pipeline, and you've done more useless work. SIMD already lets you execute a shit ton of "instructions" per cycle if your data is optimized for it. If you have scalar, serial dependencies you're better off with fewer, lower latency paths. Larger caches and better prefetching are going to be more beneficial for CPU workloads going forward because of how high the latency is to main memory compared to how fast CPUs are now.

>>105811868
> z80 production line stopping
True, but a lot of other companies license the z80 core, and the eZ80 will still be produced.

The old beefy z80s were mainly produced for old equipment and the DoD probably.

>>105810786
The 386 was probably the pinnacle of civilization.
Pretty much all modern software could—albeit minimally—run on it. Even today. And by modern, I mean unix and windows NT like. And OpenVMS.
The 486 implemented COW, but it was otherwise a “Vista” of processors. I seem to recall Mac os/x needed cow to operate acceptably because PCs didn’t have unified memory. And by os/x I mean Nextstep.

>>105811925
> execute 100 instructions per c.
Some of the literature referred to this as “completing xxx instructions per cycle” which kind of implied they’d be sitting around in the fxu unit output latches until something (e.g. scheduler) got around to obtaining the result (or discarding the result).
Which seems like it would scale well beyond 5 or 10 instructions with enough units.
Something like IDIV would certainly benefit from more.
I noticed modulus arithmetic in go used an IDIV instead of cl and gcc both turning into a shr, so still relevant.
IDIV used to be around 300 clocks, but nowadays I thought they’d throw enough die space at it that it would be 1 clock, but last I checked it was around 23 clocks.

>>105808931
I usually use older computers to test how my code performs on them. I want the broke niggas of today to be able to run my shit well, just as I was like them!

>>105808888 (OP)
3 instruction is very good sir

>>105812871
I just eating dinner right now waiting for powershell to start up. Should be mostly there when I get back. Let’s hope for the prompt!

>>105810875
VLIW basically means that multithreading gets really easy because you don't have to worry about synchronization anymore. It's an assembly programmer's wet dream.
Of course high level fags get fucked because their stupid compilers aren't able to optimize for it.
>>105812871
You can also use throttlestop to downclock your cpu to like 800mhz, and then go limit your core affinity to a single core. That should tell you whether your software is slow or fast

>>105808888 (OP)

>8088 digits
>intel 8088


mod thread

>>105812919
VLIW died when memory couldn’t keep with the processor, and intel has a tiny 64 byte cache line that compilers have trouble fitting loops into.
In those cases you can get a 4 x speed-up by using old 1 or two byte 8088 instructions even though they’re emulated nowadays.
We’ll talk about Thumb instructions from SuperH next, LOL.
> throttlestop
What’s that?
We need to go back to Turbo buttons, except make it continuously variable with a 10 digit 7 segment red LED display.

>>105812933
Huh… that’s good evidence that mods are real, and have some level of consciousness and may even be self aware.
Didn’t even notice that.

Time to put up this:
https://wiki.installgentoo.com/wiki//aig/_Alternative_ISA_General

>>105808888 (OP)
>zen is doing 5-6
Haven't we improved?

>>105812970
>What’s that?
it's some program that people used for undervolting between Haswell and Coffeelake. I think jewtel locked it down after that, though, so it's not very useful anymore
but you can still use it to change max core frequency to a very low value like 400mhz or 800mhz depending on the specific cpu model, from inside windows, no need to reboot the PC

>>105812731
Z80 and 6502 derivatives will probably be built and used until the end of time, they're the B-52 of microprocessors. You could probably develop something fractionally better for a few years of R&D, but why reinvent the wheel? It's there, it's cheap, it's proven.

>>105810819
>itoddler filename

>>105812871
Based, I do the same. Really the biggest problem is figuring out how to get libraries running on old systems or how to get rid of libraries you thought were essential.

>>105808888 (OP)

>>105808888 (OP)
> The first Intel Pentium chip was developed by a team of engineers at Intel, led by Vinod Dham, who is often referred to as the "Father of the Pentium". The team designed the P5 microarchitecture, which formed the basis for the original Pentium processor. The first Pentium chip was released on March 22, 1993.

>>105810314
nigga thats nuts

>>105810722
RGB ultra pro gaymer LED killed the bolted heatsink

>>105808888 (OP)
is there anything that does more than 3 instructions per cycle? Also nice get.

>>105808888 (OP)
arm is the future
reject x86 legacy bloat embrace modern technology

>>105815429
Aside from apple silicon, nobody sells good arm cpus. If you could purchase a PC with an powerful ARM in place of x86 then maybe, but no such cpu is available.

>>105815429
>POWER10 enters the chat

>>105808888 (OP)
>still at 3-4 instructions per cycle
bullshit

a single modern “instruction” can encapsulate more computation because of advances like wider issue widths, deeper pipelines, out‑of‑order execution, and richer instruction sets.

not to mention breaking down into uOps means the pipeline is far more saturated.

while a Pentium Pro might have been 3 instructions per cycle (with each instruction representing a relatively complex operation for its time), a modern CPU core can run multiple high-level instructions per cycle—and when you break those down into micro‑ops and account for all of the available execution resources working in parallel, the actual amount of computation performed in a given unit of time is insanely higher.

tl;dr: modern CPUs run significantly more computation per cycle than older processors like the Pentium Pro, even if you’re comparing “instructions” at the architectural level.

>>105808888 (OP)
Isn't memory the real bottle neck when it comes to CPU performance now and it's the reason why processor are having to strap large and larger cope caches to make up for shitty memory speeds? You can do infinite instructions per cycle but if you're waiting for 200+ cycles for the memory to deliver some information then what's the fucking point?

>>105815957
iirc pentium pro was the first intel processor with uOps

>>105815429
>arm is the future
No. The design is too old, even with the revisions over the years. RISC means you need more instructions to do the same thing as for CISC. And having many RISC instruction in-flight means you need speculative OoO which in turns means perhaps half the operations are cancelled.

No, what we need is CISC-X.

>>105815980
>cope caches
jej

>>105809715
> The old z80 is still around, in TI calculators for example, now typically runs at 50 MHz and every instruction is 1 clock/cycle.
Wrong: each instruction takes 1-20 clock cycles (t-states)

t. turned z80 inside out

>>105816067
>too old
aarch64 was designed from scratch in 2011

>RISC means you need more instructions to do the same thing as for CISC
nope it means
less silicon to implement instructions, less complexity, easier to optimize code at compile time, easier to execute multiple instructions per cycle.
CISC died in 90s even intel doesn't use cisc anymore because it's too expensive and hard to make silicon with over 10k instructions, they just emulate cisc at microcode level

There are a couple of things of note here.

First of is microcode. Modern CISC just break down the large instructions into a lot of smaller "RISC" structures, pure CISC doesn't exist anymore. We can probably execute an order of magnitude or two more instructions per cycle in modern CPUs.

Second is the insane limitations we have to deal with nowadays in CPU design. Because of Dennard Scaling stopping and energy efficiency going down at smaller nodes we have more and more dark silicon that can't be used at the same time. There's also a lot of circuitry dedicated to just reducing error rate from leaking electrons between the small gaps.

This doesn't even take into account that the CPU is mostly idle waiting for cache to respond and cache is mostly waiting to be filled by RAM in modern applications.

There needs to be a big re-engineering project just designing CPUs from the ground up. Maybe have a non-von neumann architecture. Try to fix heat dissipation as it's a big bottleneck. Look at error correcting circuitry in an analog way. Bake memory into the computation substrate in and of itself so that the bottleneck isn't as huge.

If society could just throw away a trillion USD into designing a new way of making CPUs we could have computers 3 to 6 orders of magnitudes faster right now.

>>105810819
>invest in Israel
>one ballistic missile to wreck your multi billion dollar facility
lol

>>105810819

pleased Iran strike the Intel fabs in Israel

>>105808931
install openbsd

>>105809715
>Let’s not worry about how you’re going to (inter)connect them.
one way cascading pipelining 2D grid flowing from top left to bottom right, performing giant DOT PRODUCTS and other niggetry so that we can shit up the internet with even more SLOP
you can send your venture capital directly to my monero address no refunds

>>105816067
There is nothing "reduced" about modern ARM. Modern ARM has almost as many instructions as modern x86, and far more than historic x86 cpus.

>>105816162
> they just emulate cisc at microcode level
That equally if not more so applies to 8086, so by your logic x86 was always RISC. The 8086 microcode is a straight up RISC ISA with an instruction counter and branch instructions.

>>105816162
>aarch64 was designed from scratch in 2011
It was launched in 2011, was the design really completed in under a year??

>nope
So you failed to understand the picture posted.

>>105812970
>VLIW died when memory couldn’t keep with the processor
The main problem was that compilers were unable to fill all slots. Check the diagram in >>105816067, had all 3 slots were filled it would have been both compact and 3x faster than what it ended up as.

>>105816005
It was the first p6 so yes

>>105816133
> eZ80
> Wrong: each instruction takes 1-20 clock cycles (t-states)
I stand corrected. I was, indeed wrong there. I went through zilogs 2015 docs, and yes, almost nothing is 1 clock, which is kind of a shame, but they do claim it’s 3 times faster on the same clock freq, so they probably did cut it down quite a bit… might be a fundamental limitation in the design.
It turns out that I was thinking of some new 8051 cores that got virtually everything down to 1 clock.

>>105816515
Yes, that was similar in concept to the CellBE processor with it’s 9 cores. Not really a new idea.

>>105818717
> slot filling problems
Yes, but those problems were well known at the time, and the designers (who had adopted older designs) figured it would be mitigated with memory loads that kept up with processors, or even exceeded it with pre-loading which was plausible in the early days, but it went the other way in the end.
And, with such large words, prediction failures are an unmitigated disaster to the pipeline.

>>105808888 (OP)
you should ask why x86 hasn't been eliminated, once & for all

>>105815980
Yes, basically. It’s a big problem for sure.

> CISC died in 90s
The opposite. The problem was that RISC was stillborn by the time it materialized.
On modern intel, CISC ops were promoted (demoted?) to micro-ops by throwing die space in the form of expansive fanned out 1-, 2-, and 3 level gate logic to get them down to 1 clock cycle.
Not the other way around.
Even the POWER 1 had crazy CISC instructions like LSCBX that we used heavily in C code for databases with short keys.

It should be obvious that virtually any instruction can be made into a single clock cycle by throwing enough die space at it.

>>105819804
Intel suffers from a lot of backward compatibility problems… all the way back to the 8088.
Sometimes I like that, though. Sometimes not.

There’s no doubt that a lot of the success of the power pc was that, when introduced, made life a lot easier for ibm because they could do things “right”

The intel successor was supposed to be Itainium, (not counting i8/960) but we know how those turned out.
I960s were so fast they’d be used to emulate x86 designs in near real time.

I have a lot more respect for the insane skills of the x86 designers that have been able to keep x86 competitive since they can’t start from scratch.

>>105819709
>Yes, but those problems were well known at the time,
Sure, and it was the compiler writers whop promised to take care of that one. They failed monumentally and were the direct cause of the downfall.
>and the designers (who had adopted older designs) figured it would be mitigated with memory loads that kept up with processors,
I never heard that one before. cache would help but if only 1 in 3 slots are filled the resulting bloat will kill all cache and processing performance.
>or even exceeded it with pre-loading which was plausible in the early days, but it went the other way in the end.
>And, with such large words, prediction failures are an unmitigated disaster to the pipeline.
The idea was that compile time scheduling should ensure superb prediction performance. That too was an unmitigated disaster.