Why are we still using cpu architecture from the 70s?

Instruction set architecture*

The hardware underneath is all new.

>>58078546
Backwards compatibility

>>58078546
Because instant replacement is impossible. Also it's the bestest in non-numeric benchmarks.

We're not. x64 doesn't have 16 bit mode.

>>58078546
You know I could bring up the point with the combustion engine, but thats just stupid.

>>58078849
>Backwards compatibility
You can just compile your software for a new architecture.
Debian manages to maintain ~20000 packages for half a dozen architectures just fine.

Why are we still using wheels from the -7,000s?

>>58078832
You can get 6502 variants the same as they always have been.

>>58078546
Reliability is the reason. 6502 is truly tested and is accepted in pacemakers. In applications like that a life time guarantee takes on a whole new level of meanings.

6502 is used in numerous embedded systems where people do not know what is inside, like mice, key fobs, pacemakers, picture frames etc. More than 200 millions are made every year.

Also old chips are well designed, small, thus require little SI area and require very little in power.

>>58079067
>You can just
>Debian

Why are we still using binary from 1679?

File: 1452640435487.jpg (32KB, 736x596px) Image search: [Google]

32KB, 736x596px

>>58078546
>why do we still use wings from billion years back

>>58079110
If a non-profit organization like Debian or Arch can do it, surely billion dollar "enterprises" with thousands of employees who are definitely not cheap imports from India should be able to do it in their sleep :^)

>>58079124
Trinary now!

>>58078546
Embdedded software/hardware is true engineering, thus it values stability and reliability over everything else. That's why people still use "old" but good enough hardware.

>>58079148
I'm actually sure Debian & friends couldn't do it themselves.
They are barely hold together by the actual developers work of making their software somewhat portable, eg taking care of issues like big vs little endian.

Also, you clearly overestimate the capabilities of companies regarding fixing their shit and and their willingness to cooperate on that issue. Someone post that MS windows 10 chat log.

>>58079108
I think you can still get 8086/8088s as well. 80386/80486 variants are still in some places as well.

OP is really talking about the ISA though which is misleading because the parts of the ISA from the 70s make up only a tiny portion of the thing at this point. New instruction set extensions are constantly being added as the need arises. A lot of them were added in the 1990s and 2000s

>>58079213
I don't have the Windows 10 chat log saved but this provides similar insights:

http://blog.zorinaq.com/?e=74

The gist is that change is often punished when it doesn't affect the next quarter's profit, like optimizing the kernel.

>>58079237
>http://blog.zorinaq.com/?e=74
/thread

>>58079231
There are rad hard 486s, but I don't think they lasted long.

>>58078546
Because it Werks pretty good at the moment.

Maybe in a few years also desktops running arm

File: 1476676578843.gif (494KB, 387x305px) Image search: [Google]

494KB, 387x305px

>>58078546
>Why are we still using the same shape of wheel that we've been using for thousands of years?

For about the same reason why cars don't fly, retard.

>>58079067
How do I recompile photoshop?

>>58078546
why not? Assembly x86 is turing complete, what else do you need?

>>58079093
We aren't though. Most wheels are made of aluminum and rubber, this is very different to 1000 years ago.

>>58078546
because it just werks

>>58079661
>How do I recompile photoshop?
That's a problem indeed, a problem of non-free software only.

>>58079044
Literally every x86 compliant processor starts up in legacy 16 bit real mode.

>>58079723
So, your initial claim that backwards compatibility doesn't matter because you can recompile software is false.

>>58079756
You can recompile software, just not all software.
Software that cannot be recompiled is defective.

>>58078546
Mostly stability.

File: 1459385518336.png (1MB, 1300x4704px) Image search: [Google]

1MB, 1300x4704px

>>58079213

>>58079653
Wheels are nothing like they used to be though

>>58079839
Thanks, have a (You).

File: anc.jpg (2MB, 3032x2015px) Image search: [Google]

2MB, 3032x2015px

Why are we still using the same CPU architecture from the 80s?

>>58079874
And processors are any different? Compare a wheel from early history to a wheel from 40 years later in early history and you'll see basically the same shit. Compare a processor from the 70s to one from the 2010s and you'll see an incredible difference in performance.

>>58079670
point
got enough of them together could run what you're looking at

>>58078546
>Why are we still using cpu architecture from the 70s?

Because Moore's Law rendered the efficiency advantage of RISC irrelevant during the processor wars of the 90's. There were many RISC chips that were faster than Intel's x86 offerings throughout the decade. But when processor power doubles every 18 months it doesn't matter as much as backwards compatibility with the massive Windows PC base.

You'll note that we do not use an instruction set architecture from the 70's in mobile. That's because there was no backwards compatibility to consider and efficiency was much more important.

If Moore's Law truly is dead then this equation may change and we may see RISC on the desktop again.

>>58080359
>There are still people on this planet that believe the RISC vs CISC marketing.

File: tony_hawk.webm (908KB, 400x227px) Image search: [Google]

908KB, 400x227px

Because:
• It's currently the most energy efficient
• It currently has highest IPC
• It's backwards compatible with a fuckload of very useful proprietary software

Only reason we use ARM for phones and tablets is because they are cheaper.

>>58080359
https://www.top500.org/green500/lists/2016/11/
Man ARM is really rocking on that list.

>>58080359
I really want a MIPS desktop again.

x86 became the standard because of popularity. It had nothing special

>>58079686
Wheels are backwards compatible.

>>58078546
>we
Speak for yourself, mine's from the 90's

>>58080420
No, I believe benchmarks and real application performance. And there was a reason all the high dollar workstations of the 90's used RISC.

>>58080447
>implying ARM makes processors relevant to that list
ARM cores are optimized for their primary use in the market today, which is mobile. Now that ARM is starting to enter the server space this will change. But it doesn't change overnight.

>>58080693
Should RISC make a comeback on the desktop I would be surprised if it was anything other than ARM simply due to the established market. x86 and ARM have huge leads in engineers and developers because that's what's out there.

And there's no guarantee it will. Backwards compatibility is still a huge point in Intel's favor when it comes to the desktop.

>>58078546
Modern x86 chips are only x86 in compatibility. At the lowest layer they're closer to being RISC than CISC.

>>58081166
Backwards compatibility doesn't really matter to the average user. I don't care what ISA comes up as long as I have a non x86 option. I just have a soft spot for MIPS.

>>58078832
We are just using multi-core pentium 3's and something ati did on mobile 12 years ago

The only NEW architectures are Zen, Moongoose and something apple

>>58081432
Netburst and Bulldozer were new lol

>>58078546
just werks

>>58079108
>like mice
Wait
Does it mean my mouse can be as powerful as Apple ][?

>>58081533
I think flash drives might be more powerful than some old microcomputers.

>>58078546
>Why are we still using cpu architecture from the 70s?

What makes you think we're still using CPU architecture from the 70s?

Since then, pipelines have become much longer and more sophisticated; and they've introduced innovative new techniques -- such as super-scalar, which is where they dispatch multiple instructions to parallel functional units in the same clock cycle. And is putting the GPU on the same die as the CPU not a major architectural enhancement?

If you're talking about the process node size, there's been several orders of magnitude change in the number of transistors per unit area, plus innovations to accommodate a massive increase in clock speeds, such as new materials design and new techniques to manage power, heat, and EMI.

Or are you talking about the fact that the latest Skylake chips still support all the instructions from the original 8086 chip? First of all, 64-bit compilers don't generate ANY of those old 8086 instructions anymore -- they all generate the new AMD64 instructions, which have a much more clean and modern design. Second of all, support for that original 8086 instruction set barely occupies 1% of the surface area of a Skylake chip. Are you whining that 1% of the CPU price is spent on continued support for 8086?

Or are you complaining about the von Neumann bottleneck? (That's the fact that the CPU can only execute one instruction at a time.) What do you think all that emphasis on multiple cores and threads was all about? What we've learned now is that the von Neumann bottleneck is not actually a hardware limitation at all -- it's a software limitation, because 99% of all software we use has still not been re-designed to take advantage of all those extra cores and threads.

Sorry, dude, but if you look at the changes in CPUs from 1970 to 2016 and conclude it's the "same architecture" now, then you just haven't been paying attention.

>>58081554
Yes, much has changed. But we keep piling shit on to an ancient design instead of starting out with something modern.

File: .jpg (280KB, 2048x1536px) Image search: [Google]

280KB, 2048x1536px

>>58081543
Oh wow
Does it mean caring about performance doesn't matter anymore?

>>58081611
Hardware devs use micro-controllers because it's cheaper and easier to (re)program them than it is to (re)design a board with a bunch of discrete components. So basically all the logic in these devices is handled by another smaller computer.

>>58079781
no, it just means it's probably a product. which is perfectly fine if you're not autistic and work for a living.

>>58081584
>we keep piling shit on to an ancient design instead of starting out with something modern

Ummm, I just said that 64-bit compilers do not generate ANY of the original 8086 instructions, and they use the whole new AMD64 ISA exclusively. That's a perfect example of how they have COMPLETELY THROWN OUT old design and replaced it with something entirely new.

What are you looking for here? A CPU that stores data as photons instead of electrons, or something like that? The fact is that every modern innovation you can think of is currently in the process of being studied as a possible replacement for the existing technology. If we're still using the existing technology, that's because it's still more cost-effective. Is that what you're complaining about? -- that we continue to use older technology because it's still the most cost-effective solution?

>>58081762
I'm looking for a CPU that's not initially based on a design from the 70s. Yes, things have changed, yes, it's extremely different. But the bottom line is modern x86 processors are a fuckload of extensions that were piled onto an ancient design.

>>58081791
SPARC
PowerPC

>>58081816
No shit

>>58080359
Here is a link that elaborates on what you just said.
https://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/

>>58081474
Netburst was shitcanned. Core 2 was based on Pentium III.

>>58081655
>So basically all the logic in these devices is handled by another smaller computer.
... and so on ad infinitum.

>>58078546
why are we still using languages from hundreds of years ago? It's 2016, we've come further in every other way but language

>>58081816
Itanium

Kindof a joke these days, but they are at least interesting. Tempted to get a second hand one to dick with.

File: tmp_12579-cat837458421.jpg (14KB, 392x293px) Image search: [Google]

14KB, 392x293px

>>58078546
>Why are we still using spoons? They are like 5000+ years old technology. can't we use something new!?

>>58081533
It is a lot more powerful, the clock is upped from 1 MHz to 16 MHz and the chip has integrated a lot of peripherals including mouse camera tracker and USB communication.

>>58082036
sporks man

>>58079686
We're still using the same wheel architecture (round) just on new hardware

>>58078546
>Why are we still using vaginas from ancient times when we have all the feminine penis alternatives that today has to offer
Sometimes the old stuff just werks, anon

>>58081554
>Second of all, support for that original 8086 instruction set barely occupies 1% of the surface area of a Skylake chip.
This is wrong.

>>58081533
from what i understand, there's basically 3 ways to make complex circuit
a. use lots of simple, generic, discrete components (takes up a lot of space)
b. create an ASIC, aka a custom chip (expensive and difficult to design and test, expensive to produce in small numbers, but the most flexible)
c. use a microcontroller supported by few discreet components (much easier to design and test than an ASIC, cheaper for smaller numbers)

microcontrollers are used everywhere, if you can make your product with a micro (as opposed to an ASIC), you'd use these, and this applies to most stuff

>>58082454
-- oh, there's also FPGA's
they're expensive, and only really show up in special cases
but they have advantages of both ASIC's and microcontrollers

>>58081762
>Ummm, I just said that 64-bit compilers do not generate ANY of the original 8086 instructions, and they use the whole new AMD64 ISA exclusively. That's a perfect example of how they have COMPLETELY THROWN OUT old design and replaced it with something entirely new.

AMD64 added instructions and registers as well as changing register and address sizing so that chips would be 64-bit. But it's still the x86 CISC ISA that has been built up over the years. Nothing was "completely thrown out." 64-bit compilers use the old instructions extensively. And if you know assembly for x86 writing AMD64 is mainly a matter of learning what's new.

https://en.wikipedia.org/wiki/X86_instruction_listings
https://en.wikipedia.org/wiki/X86-64

A RISC instruction set would make some things easier to implement and/or would allow the task to run more smoothly (fewer stalls): decoding; dispatch; out of order execution; speculative branch prediction; cache prefetching; etc. If something is easier it takes less silicon. If it takes less silicon then you're either using less power or you can put the silicon to use for something else like another execution unit or more cache.

On the flip side, x86 instructions can consume less space in the cache and performance on modern processors is very much about optimizing cache hits.

There are many variables in processor performance so you can't just claim "muh RISC is always faster!" But over the years RISC has generally proven to be faster and/or more energy efficient *when someone has had the motivation and cash to compete with an Intel chip.* That last part is important because for years nobody in the RISC world has had reason to fight for the desktop.

If everything else was equal and you gave two design teams the cash to develop modern desktop class CPUs...one x86-64 and one RISC...the RISC design would win on performance. But when is everything else equal?

>>58078546
T-the same reason nearly all of our electricity still comes from heating water into steam?

>>58079191
>Trinary
REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

>>58079727
Not on UEFI systems.

>>58081554
>it's a software limitation, because 99% of all software we use has still not been re-designed to take advantage of all those extra cores and threads.
Yes software is generally written with the assumption that each bit of code executes after the preceding bit of code is executed. A lot of programs are really fucking hard to write without making this assumption since that would kind of fuck them up.

>>58078546
Works on my machine ;)

>>58079661
https://www.youtube.com/watch?v=A_GlGglbu1U

Got you covered ;)

>>58079661
http://computerhistory.org/atchm/adobe-photoshop-source-code/

CTRL / ALT / SCROLL / SYS RQ / PAUSE / BREAK / F1-F12 / ESC / TAB

1970s keys on 2016 keyboards.

mfw no one button Cut/Copy/Paste keys

>>58078546
You would go far with a job at apple.

>>58080754
for now, goy

>>58084114
That shit always annoyed the fuck out of me.
Where are the Cut Copy and Paste keys?
They are such fundamental features of pretty much every OS ever built from the 90s onwards.

Also, fucking INSERT. FUCK
I have NEVER in my entire life seen a good implementation of Overwrite. EVER.
Most worthless key ever. I have disabled it in every OS I've had. Well, recently from XP onwards, made it in to a toggle key for other features, which I still rarely use since I put any custom hotkeys and scripts behind capslock+[key]. Or Alt Gr. Some behind Context Key since nothing fucking uses it either.
Delete is also semi-annoying. Shift+backspace was fine. It STILL works. (try it)
I rarely ever use the Delete key. And I program my ass off. Backspace is almost always easier.
Backspace name itself always sounded stupid to me, even with the explanation for it.
Having it named Delete would have saved the confusion. Delete deletes behind caret, shift-delete deletes anything in front. And it would make sense for Deleting files, or selections, and so on.

What those keys should have been instead was Back and Forward. (or Left / Right, see below)
Home / End next to Page Up.
Back / Forward next to Page Down.
Why the fuck are 2 shitty non-navigation keys in the damn navigation section?!
Another good thing the Back and Forward could have been used for, as mentioned in the brackets, was Left and Right for programs that support tabs, or pages, and so on.
Browsers had a spec for pagination like this. You could move Left and Right, as well as Up to the parent directory. These are not relative assignments, you assigned them in a tag I forgot. (link or meta, not sure again)
I can only remember Opera supporting this. Or at least the last one to.
Or you could have had a third row, which some keyboards do/did have, then put Left, Right, with Up under Page Down. So all the vertical traversal keys are in a line, and the left and right aligned keys in line too.

>>58084114
You know what key is really annoying? Num lock. How frequently do you actually intend to use that key? Isn't the only usage of it basically "oops for some reason my keypad wasn't enabled" and then you turn it on and leave it on forever?

It's been extended... a lot. Keeping the same architecture throughout has made applications able to keep running though. When we transferred from 16 bit to 32 bit, applications did not have to be rewritten for the new platform, but new applications were written for the new platform. Similarly, when we went from 32 bit to 64 bit, applications could again be run with no modifications. The 16 bit applications were basically broken, but there were no recent 16 bit applications, and older applications could easily be run in emulation.

As long as there's no transition problems from one architecture to another, everything is fine.

>>58082839
Yes on UEFI systems.

File: JohnvonNeumann-LosAlamos.gif (281KB, 490x639px) Image search: [Google]

281KB, 490x639px

Why are we still using computer architecture from some dead french guy from the 1940s?

>>58084114
Kill yourself.

>>58084669
The numpad keys have other functions.

>>58084669
I use it mainly for fun, but sometimes for useful reasons.
I wrote a bunch of numpad scripts for various purposes.
Numlock+/ opens a UI to select what mode I want.
Numlock is the toggle key for 2 states of most of those features.
Numlock off is the actual functionality, numlock on is the settings for them.
Scroll-lock off turns off the features entirely and returns to normal numpad operations. (may as well use the thing)

The one I probably use most is numpad mouse. (based loosely on the Autohotkey Numpad mouse, but changed heavily for my needs)
In my case, numlock on let's me change speed of mouse, acceleration, clamping, angle of movement, autoclick speed, whether autoclick does full clicks or auto-repeats key-down events.
And in the case of speed, I have an even slower movement speed I use sometimes. (mainly for looking at large sections of code)
Lowest standard speed is 1 pixel. But that is every tick.
I added the ability to add a delay in milliseconds on top so you can slow it even further. I might combine both of these speeds at one point. Who knows.

Another I made for fun was an implementation of Thumbscript.
http://www.thumbscript.com/
It was fun making that.
I was thinking of extending on it with another page of commands in the numlock-on group. But I lost interest.

Only other legit use I ever had with numpad was Excel and Garrys Mod years ago when it actually had a community and wasn't shitty mini-games and memes.
I miss making Wiremod battle machines in space. (and using Forcefield mod to disable gravity so it is actual space battles)

>>58084669
I'm not sure if you've ever noticed, but the keys on the numpad do things when numlock is off.

I wish they kept the m68k lineage alive

>>58085138
They move the cursor around...like the other keys that do that.

When will we upgrade from binary to trinary?

>>58084692
>from one architecture to another

As explained above >>58082612 it's the same instruction set architecture with some extensions. There have been no real "transitions."

An example of a transition to a new instruction set architecture would be Apple's moves from 68K to PPC and then to x86.

>>58085148
It is (coldfire) :)

Question /g/

Why do old 3d games can run flawlessly without 3d accelerator? I still remember my very old beige powermac can run quake smoothly. And i still clearly remember that Its motherboard doesnt have any expansion card on it.

>>58081432
>ati did on mobile 12 years ago
you mean AMD ? explain
also both multi-core and 64bit processors were AMD's invention, back in their good days.

>>58081364
>Backwards compatibility doesn't really matter to the average user.
Explain why you're making such an obviously false statement

>>58079146
>implying the earth is over 6000 years old.

>>58086288
Old 3D games just ran on CPU and/or math co-processor. OpenGL itself was originally meant to run on CPUs and was created well before they existed. Discrete ASICs(GPUs/Graphics cards) were created to address increasingly demanding games.

>>58078546
Because it's all you need for most things.

>>58078546
>tfw your first CPU you had any experience with was a 8086

I get a sad pride out of being there from the beginning.

>>58086373
Well games and applications in general.

>>58086373
>OpenGL itself was originally meant to run on CPUs and was created well before they existed.
before graphics cards I mean

>>58086288

The resolutions and color count were low and the people developing the renders were optimization wizards.

3D graphics accelerators scale much better than software, especially when you're rendering true three-dimensional scenery.

>>58086310
IBM did the first multicore cpu

https://en.wikipedia.org/wiki/POWER4
>The POWER4 was a multicore microprocessor, with two cores on a single die, the first non-embedded microprocessor to do so.

>>58086288
Low resolution as low polygon count gave you a passable 15 fps.

>>58086340
How many legacy applications does the average person use?

>>58086536
windows

>>58085244
In -50 years.
https://en.wikipedia.org/wiki/Setun

>>58078546
Because modern architectures do not improve performance enough to justify rewriting the whole ecosystem for something new.

>>58086310
Qualcomm bought Adreno and some parts of Snapdragon from AMD.

AMD's then-CEO was fired a year later for selling the smartphone-related assets.

>>58086310
AMD invented neither, they simply had the first multicore AMD64 CPU.

>>58078546
It still works, and it's well understood.

File: Intel_Itanium.png (110KB, 308x342px) Image search: [Google]

110KB, 308x342px

>>58078546
because novelty for the sake of novelty is counter-progressive masturbatory bullshit when you're going to implement the exact same concepts we perfected on the mainframe 50 years ago anyway

>>58079067
try actually using something that isn't a mainstream x86/ARM system some time and get back to us on that, "runs" doesn't mean "runs well"

I mean shit, you could do exactly that on this turd too but it didn't make the compilers and the underlying hardware itself any less shit

hardware quirks and platform differences can also hamper this as well, there's a reason a lot of generally sound platforms like IRIX don't have a working firefox port, for example

>>58086310
>64bit were AMD's invention
in x86 space only, we had 64-bit microprocessors since the R4000 in '91, 64-bit processors in general since Cray started wrecking shit in '75, even Intel still had a 64-bit chip out before them in the form of the Itanic, they just had the sense to bring it to the market in a way that wasn't botched from the start

they didn't even invent native multi-core chips, as other anons pointed out, and MCMs integrating multiple dies in a single module were a thing forever

File: O_shitniggawhattimeisitdamn.jpg (20KB, 300x300px) Image search: [Google]

20KB, 300x300px

>>58079874
> they're square now

>>58078546
because 8+8=10

File: sgi-list.png (71KB, 1117x617px) Image search: [Google]

71KB, 1117x617px

>>58081166
>And there was a reason all the high dollar workstations of the 90's used RISC.
Because x86 wasn't targeted at those applications for most of the golden age of workstations and thus couldn't deliver the performance or feature set they needed. RISC chips didn't need a lot of investment to be good at what they were made to do, and the companies had an architecture they could fully control and tweak based on their own specifications, rather than pleading with a larger vendor like Motorola or Intel to cater to it for them.

It worked out well for a few years, but towards the end of the '90s, most of those "high dollar workstations" were overpriced, glacial trash with a declining market of customers locked into these expensive platforms and their still exclusive software bases as many of the simplicity-oriented philosophies that made RISC chips so incredible started to hit a wall and vendors were forced to adopt all kinds of bloat and complexities to remain competitive. There's a reason they were righteously culled in the 2000s, once Intel, AMD et al started caring about them, users and vendors alike in that market realized how shit things really were.

And by the way, in the context of the average /g/ use case, the benchmarks and "real application" performance was generally shit on those chips that were designed more for squeezing out godly floating-point performance critical to scientific and technical computing rather than integer slogging typical of a business fleet box or home web surfer.

>>58078546
The same reason why some computers still use Pentium processors

>>58086355

TERRY! How is TempleOS coming along?

>>58089134
>Because x86 wasn't targeted at those applications for most of the golden age of workstations and thus couldn't deliver the performance or feature set they needed.

You say that as if it was a marketing decision and Intel was just "holding back." This is false. Intel COULDN'T compete in this space with the lithography available at the time. If Moore's Law had died sometime in the 90's x86 would be dead and we would be using one of the RISC architectures because the performance difference was that large. We're talking about 2-3x for the same die and feature size.

>as many of the simplicity-oriented philosophies that made RISC chips so incredible started to hit a wall

False again. RISC doesn't hit any walls that CISC doesn't. In fact, Intel has faced more difficult challenges in scaling up to take advantage of lithography gains.

>There's a reason they were righteously culled in the 2000s,

And it has nothing to do with what you're imagining. Improved lithography meant that everything was faster. You need X performance to do something and all of a sudden x86 is offering 2X thanks to Moore's Law. Why wouldn't you then take advantage of commodity components that are compatible with the massive Windows software base? This is why x86 won the desktop. Moore's Law meant that CISC inefficiency was something of a temporary problem.

>And by the way, in the context of the average /g/ use case, the benchmarks and "real application" performance was generally shit on those chips

You have no idea what you're talking about. Were you even alive back then? Their performance was fantastic.

>that were designed more for squeezing out godly floating-point performance critical to scientific and technical computing rather than integer slogging typical of a business fleet box or home web surfer.

Where are you getting this shit? RISC was conceived, formalized, and put into practice in large part to make it easier to go superscalar with integer units for massive gains.

What's the earliest year you guys could see Microsoft rewriting Windows from the ground up?

Why do we still use fire? Why do we still use +,-,/,X for maths? Why ABC for English? Why internet for 4chan? Why use dick to fap? Why dicks to fuck pussies?...

Why do you exist anon?

>>58091314
Never

it would cost way to much

If anything they'd just rewrite the kernel and keep the win32 compatibility

>>58078546
because 50 years of maturity

>>58081182
Next you're going to tell me proccessors don't run C.

>>58078546
Because it is compatible with 20+ years worth of applications.

>>58090944
>You say that as if it was a marketing decision and Intel was just "holding back."
They did, Intel had the likes of the i860 and later the Itanium for high-end systems, they never targeted anything but the low end until relatively recently with x86.

>If Moore's Law had died sometime in the 90's x86 would be dead and we would be using one of the RISC architectures because the performance difference was that large
Maybe, but things turned out differently, and you couldn't even give NT4 away for an Alpha.

>False again. RISC doesn't hit any walls that CISC doesn't. In fact, Intel has faced more difficult challenges in scaling up to take advantage of lithography gains.
Simplicity was key in early RISC designs, which had a bonus of allowing them to clock ridiculously fast. Surely, it wasn't everything, but once that became infeasible while x86 designers simply cherrypicked everything they liked in RISC space, the gap only started to close faster.

>You have no idea what you're talking about. Were you even alive back then? Their performance was fantastic.
I own several of those workstations, and I've actually used them (still do). They were great for the things they were made to do, tasks typical of home usage were not any of them. The big RISCs were always FP-strong and generally weak for integer maths, with the exception of some outliers specifically designed to tackle that problem.

>Where are you getting this shit? RISC was conceived, formalized, and put into practice in large part to make it easier to go superscalar with integer units for massive gains.
That's really doubtful, considering that superscalar RISC chips didn't even hit the market until long after Berkeley and others had already pioneered them, that was just a side effect of their simplicity allowing designers to include multiple execution units without much trade-off.

>>58086536
All of them.

>>58086288
>Why do old 3d games can run flawlessly without 3d accelerator?

They were developed by competent people, and they actually optimized things on the lowest possible level to deliver the highest possible performance. They wrote their own engines and their own 3d functions.

Also they used quite low resolutions and low bit-depth. The resolution didn't really matter because going from Monkey Island to Quake was still a paradigm shift.

>>58083049
No the problem is the overhead of starting a parallel computation is on the order of 50 to 90 microseconds. The breakeven point is at 120 microseconds but that means you're burning 4 times as many cores than the single core version which means actually anything below 360 microseconds cannot be efficiently parallelised even if all you want to do is something trivial like taking the sum of an array of integers.

>>58093891
Only the AT&T Hobbit CPU did that

File: 1000509261001_1822941199001_BIO-Biography-31-Innovators-Steve-Jobs-115958-SF.jpg (92KB, 768x432px) Image search: [Google]

92KB, 768x432px

>>58078546
>If it isn't broke don't fix it

>>58081166
>ARM cores are optimized for their primary use in the market today, which is mobile. Now that ARM is starting to enter the server space this will change. But it doesn't change overnight.
It's funny to look at them develop their crappy wannabe xeons instead of capitalising on their strengths.

>>58093952
>They did, Intel had the likes of the i860 and later the Itanium for high-end systems,
One was RISC and the other was VLIW. So Intel themselves recognized the inefficiencies of CISC x86 and were exploring alternative instruction set architectures for more speed.

Checkmate.

>Maybe, but things turned out differently, and you couldn't even give NT4 away for an Alpha.
Yes, but that's not the same thing as saying that RISC has no advantages.

>Simplicity was key in early RISC designs, which had a bonus of allowing them to clock ridiculously fast. Surely, it wasn't everything, but once that became infeasible...

It's not just clock. It's also efficiency. There are plenty of examples of RISC chips out performing x86 chips when the x86 chips were clocked higher.

>The big RISCs were always FP-strong and generally weak for integer maths, with the exception of some outliers specifically designed to tackle that problem.

I don't know what you owned or what you're comparing it to, but throughout the 90's you could just about randomly pick a RISC core and an x86 core of the same generation and watch the RISC core eat the x86 alive on integer ops.

>That's really doubtful, considering that superscalar RISC chips didn't even hit the market until long after Berkeley and others had already pioneered them,

R&D was early to mid 80's, commercialization was late 80's, and the first superscalar chips hit in '89 and '90. That's not "long after." The R&D teams knew what was coming. Several concepts or "rules" of RISC design are directly related to superscalar dispatch. The early books and papers talk about it.

>>58094147
>It's funny to look at them develop their crappy wannabe xeons instead of capitalising on their strengths.
It won't be funny when they are out performing the Xeons.

File: intel-thunderx-xeon-spec-range.jpg (37KB, 710x340px) Image search: [Google]

37KB, 710x340px

>>58094278
Keep deluding yourself
Pic related: the 48 core ARM CPU almost loses against a 6 core 1.7GHz Xeon

File: two-cute-girls-laughing-grass-18205997.jpg (50KB, 400x267px) Image search: [Google]

50KB, 400x267px

>>58094403
>his graph doesn't include Gene3

E5 would still be faster, but you would be a fool to assume that what is true today will always and forever be true. ARM engineers will have an easier time squeezing more performance out of their instruction set then Intel has had squeezing performance out of x86.

File: armv7-armhf.png (68KB, 819x509px) Image search: [Google]

68KB, 819x509px

>>58078546
get on my level

>>58093952
>
>The big RISCs were always FP-strong and generally weak for integer maths, with the exception of some outliers specifically designed to tackle that problem.
>what is PPC and SPARC

>>58079108
>You can get 6502 variants the same as they always have been.
Not true, they fixed a bunch of bugs in the new 6502's, even the good ones (like the many illegal instructions that could save you a lot of cycles)

>>58097869
bogomips or it didn't happen

>>58097926

 dmesg | grep -i bogo
[    0.000002] Calibrating delay loop (skipped), value calculated using timer frequency.. 6585.20 BogoMIPS (lpj=3292600)
[    0.401722] Total of 4 processors activated (26337.77 BogoMIPS). [/code[

>>58097967
what SoC anon? I call bullshit, thats more bogomips than core 2 duo

>>58097869
25MHz ARM 710a

>>58098013
hah, yeah I pasted from the wrong session. RK3288 SoC.

[    0.000000] CPU: ARMv7 Processor [410fc0d1] revision 1 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Google Speedy
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 1044224
[    0.000000] free_area_init_node: node 0, pgdat c0b4f500, node_mem_map ed81b000
[    0.000000]   Normal zone: 1520 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 194560 pages, LIFO batch:31
[    0.000000]   HighMem zone: 6638 pages used for memmap
[    0.000000]   HighMem zone: 849664 pages, LIFO batch:31
[    0.000000] PERCPU: Embedded 9 pages/cpu @ed7c4000 s14400 r8192 d14272 u36864
[    0.000000] pcpu-alloc: s14400 r8192 d14272 u36864 alloc=9*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3

File: IMG_20161220_172736_edit.jpg (2MB, 3120x2340px) Image search: [Google]

2MB, 3120x2340px

>>58098081
Forgot photo

>>58098089
where's the bogomips boi

>>58098104
ikr

>>58098104
They're too bogus. It sez 48.00. wtf. It actually compiles the kernel pretty quick using make -j4

dmesg | grep -i bogo
[    0.001046] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)

>>58098164
lolz my casio watch gets more mips

>>58098164
lol rockchip trying to be clever bumping up for benchmarks then it gets bad results...dumb dumb

>>58098228
bogomips is literally how fast the processor can do nothing. Not that meaningful.

>>58098368
Not true.

body:  decl eax
jns  body

>>58078546
Why are we still breathing air from millions of years ago?

>>58098478
You think that's air you're breathing?

>>58098164
https://en.wikipedia.org/wiki/BogoMips

In 2012, ARM contributed a new udelay implementation allowing the system timer built into many ARMv7 CPUs to be used instead of a busy-wait loop.[8] Timer-based delays are more robust on systems that use frequency scaling to dynamically adjust the processor's speed at runtime, as loops_per_jiffies values may not necessarily scale linearly. Also, since the timer frequency is known in advance, no calibration is needed at boot time.

One side effect of this change is that the BogoMIPS value will reflect the timer frequency, not the CPU's core frequency. Typically the timer frequency is much lower than the processor's maximum frequency, and some users may be surprised to see an unusually low BogoMIPS value when comparing against systems that use traditional busy-wait loops.

>>58079108
the pic is an 8086, not a 6502

>>58081073
what is this?

>>58090944
>RISC was conceived, formalized, and put into practice in large part to make it easier to go superscalar with integer units for massive gains.
so what you're saying is I should eat 4 scoops of RISC ALU's a day if I want to get big

>>58090806
no didn't you see the CIA got terry.

File: 457257271-lolmorpheusair.jpg (36KB, 800x772px) Image search: [Google]

36KB, 800x772px

>>58098492

File: Ultra_76ac37_1954542.jpg (60KB, 546x652px) Image search: [Google]

60KB, 546x652px

>>58099175
You think he got this big eating CISCs?

>>58099189
OH NOES did he ded?

>>58099796
His twitter was banned and his youtube streams got bandwidth throttled..

>>58099783
I think he was eating VLIWs

File: 1482034560114.jpg (62KB, 640x640px) Image search: [Google]

62KB, 640x640px

Actually it's Pentium Pro arch but whatevs

>>58099870
Still based on shit from the '70s.

>>58079191
ah wow another trinaryfag

shadilay

>>58078546
You tell me why you're still using it. And then you'll have your answer.

File: 1461221326369.gif (778KB, 245x190px) Image search: [Google]

778KB, 245x190px

>>58080754
post of the fucking year

>>58094258
>So Intel themselves recognized the inefficiencies of CISC x86 and were exploring alternative instruction set architectures for more speed.
And boy I'll be damned if both of them didn't tackle any of those nebulous "inefficiencies" worth a shit to avoid becoming utter failures outside of a few niche applications. And the i860 was not meant to replace x86, it was meant to complement it in the high-end, because high-end chips with high-end features are quite expensive, and a poor value for the x86 customer base.

Checkmate indeed.

>Yes, but that's not the same thing as saying that RISC has no advantages.
True, but those advantages are worthless when they can't be utilized.

>It's not just clock. It's also efficiency. There are plenty of examples of RISC chips out performing x86 chips when the x86 chips were clocked higher.
Not the chips you're trying to conjure, the majority of RISC designs in the early '90s clocked much faster than their x86 contemporaries thanks to their simplicity. It was half of their edge. Later on they did get efficient clock-for-clock out of necessity, but it sure has hell didn't make a shit of difference and the remained quite power hungry platforms in general.

>you could just about randomly pick a RISC core and an x86 core of the same generation and watch the RISC core eat the x86 alive on integer ops.
Here's what SGI, Sun, and Digital had to answer to a prosumer Dell:
https://www.spec.org/osg/cpu95/results/res96q2/cpu95-960610-00950.html
https://www.spec.org/osg/cpu95/results/res96q4/cpu95-960913-01322.html
https://www.spec.org/osg/cpu95/results/res96q2/cpu95-960606-00850.html
https://www.spec.org/osg/cpu95/results/res96q3/cpu95-960708-01016.html

I'll admit, I wasn't really sure what Digital's most competitive offering was to an entry-level P6 box at that time, but even if you bump it up all the way to the 333 MHz EV5, it sure as hell isn't the holocaust you think it was.

>>58094258
>R&D was early to mid 80's, commercialization was late 80's
And the majority of those commercialized chips; ARM, MIPS, SPARC, PA-RISC, ROMP/POWER, I could go on, were *not* initially superscalar, and those features weren't introduced for the most part until the mid '90s. That's a pretty long time in tech terms.

File: power-fp.png (41KB, 509x752px) Image search: [Google]

41KB, 509x752px

>>58097904
>>what is PPC and SPARC
definitely not what you seem to be implying

Because backwards compatibility has held us back and cause we suck in the computer industry. We just build hacks upon hacks on an old as design when we can come up with something newer and better now. Anyone who says otherwise is just an indoctrinated CS major. There are reasons to use x86 but that's not an excuse to not innovate. Samething with C, Unix and a bunch of other shit. CS is a joke

>>58084631
and you wonder why no woman comes to your house to just ride your cock nerd

>>58102888
>Because backwards compatibility has held us back and cause we suck in the computer industry. We just build hacks upon hacks on an old as design when we can come up with something newer and better now.
It's funny because you probably couldn't even give a single valid example of those "hacks" that aren't just trivial ideological nitpicking or meaningless obstacles that were documented and worked around without a hitch decades ago, nor any "innovation" to fix them.

We spent years doing that shit, that was practically the bulk of the '80s, '90s and a bit of the 2000s inventing all of these brand new architectures to fix the "mistakes" of previous architectures only for those same mistake-laden platforms to blow them all out of the weeds within a few years. Reinventing the wheel is unnecessary, it takes work, it takes retooling, it takes money, and all it brings to the table is jacking material for bikeshedding college undergrads who wiki-skimmed the history of Sun and SGI and thought themselves enlightened afterwards.

>CS is a joke
That's a computer engineering issue, not a computer science issue.

>>58078546
Because you haven't invented anything better - Anyone in the world can ask this question. See above answer. You want something different you need to create it - this goes for much of life.

>>58078546
Quantum Processors when?

File: sumerian-wheel.jpg (73KB, 400x338px) Image search: [Google]

73KB, 400x338px

>>58078546
Why are we still using prehistoric tech? Because it works. CPU architectures don't fail because they're bad. They fail when their company fails.

>>58081791
itanium?

>>58081816
ancient shit from the '80s both derived directly from work done in the '70s, implementing concepts perfected in the '60s like everything else

>>58103234
based on '80s ideas

you can't avoid "old" ideas and paradigms in computing, because ideas aren't shiny iToys that deprecate every two months for the next best thing(TM), there are only so many ways you can design logic in a way that isn't shit

>>58087507
>AMD didn't invent AMD64
Nice one

>>58103355
I literally said AMD invented AMD64 in that post, you fucking retard.

>>58103355
the fag he replied to said they invented 64bit processors which is blatantly false you cockend

>>58103385
It's obvious he meant AMD64 when he said 64 bit CPUs you pathetically pedantic NEET.

>>58103397
>giving the average retard on /g/ this much credit

>>58103397
No, it's really not.

>>58103443
>Nh-NO YOURE WRONF
I know there's a lot of autism on this board but try and get it under control.

>>58103463
>lol everyone but me has autism xDDDD
Nice meme.

>>58103467
Not everyone, just you. I notice that you didn't even try to deny it either.

>>58103492
Why would I? It's just some baseless insult tossed around in 90% of the posts on the board.

>>58078546
Gee IDK why the fuck do we still use Unix-like OSs, smart guy?

The hell we still fucking around with C for?

Why did LISP come back? Like what the fuck, isn't that from the 70s?

>>58103637
lisp is literally one of the first high-level programming languages along with fortran developed in the late '50s you mong

get your autism right

>>58081432
modern core chips do not directly descend from the pentium III any more than netburst did, only the core duos and pentium M can claim that

>>58103921
ate that bait m8

>>58104195
i-i knew it was a ruse all along

>>58103637
JavaScript is pretty much Scheme with a Java-like syntax.
So everything old is new again.

>>58104250
Oh, you just crossed the fucking line now, nigger. How the fuck dare you say that js is pretty much scheme??? Like, how the fuck do you back that up??? How the fuck is Javascript a functional language (Idfc yes I know you can do functional in it but that doesn't matter) but Scheme??? Back that shit up right now nigger I wanna hear this. JS /= Lisp you fucking kike.

>>58104279
JavaScript is just the kiddie version of Java

>>58104279
>muh clojure
Grow up, faggot. JS pretty much IS scheme if you understand how to use it, it just has a c-like syntax. Ooo curly braces, I'm so scared. (you (are (a (faggot))))

>>58104298
Java is the shit version of C. What's your point? I'm more concerned with types that depend on values than fucking memory management, why would I want to bother with the retarded cousin of a compiler that thinks it's a language?

>>58104279
But it's true.
If you ignore all the hipster shit that's been added onto it, you still see the Scheme semantics everywhere:

var x = function()
(setf x (lambda ))

You even see a similar approach to solving things.
Lambda the Ultimate is fucking everywhere in JS. You need a namespace? Just put it in a function() {}. Just like... if you needed a namespace in old fashioned scheme, you'd use a lambda.

You could read the old 70s papers on that stuff, implement it in scheme and make good beautiful stuff in JS. It's not the language that is bad, it's the hipsters that have formed a shit-tier culture around it.

>>58104242
Well it looks like you just got hoodwinked by a master ruseman. You see, I implied that I was too retarded to know my history and also too over-chromosomed to be able to just google some shit before I posted it. But you fell into my gambit and it played off, flawlessly. Look how stupid you look, you loser. Look how dumb you are after being spat out my the machinations of my devious tomfoolery. I'm sure you're cleaning your trousers right now and thinking twice before ever touching a keyboard again, you little puke.

>>58104335
>Java is the shit version of C.
Can you support that claim?

If you never used HotJava then you have no idea why Java was invented and are likely to make numerous incorrect statements.

>>58104375

Mine caught a retarded fish tho.

>JavaScript is just the kiddie version of Java

Hard to say whether I succeeded or not

>>58104338
I can't argue with that at all. You're actually 100% right.

I just wish people would write their fucking js to be a little more schemish, but desu half of these developers are like "lambda calculus uhh whatever i think i got the hang of that"

File: bedintruder-dumb.jpg (22KB, 480x360px) Image search: [Google]

22KB, 480x360px

>>58104375
https://www.youtube.com/watch?v=bobp5OHVsWY

>>58104400
That was actually pretty good.
>>58104390
Bitch I had every one of those crapplets crash back in the 90s when you were still your cuck daddy's balls so STFU. Java is fucking gay and so is the JVM, give it like twenty years and everyone will being using Dis.

>>58104414
https://www.youtube.com/watch?v=ucyRR9wy8e8

>>58078546
Because the rest has been classified

>>58104404
It's one of the saddest things about JavaScript.

To be fair, it's what happens when people who get hired to make the hamster dance when you put your mouse cursor over it have to suddenly build large applications.

When Java Enterprise people try to make a language that is fast to program stuff in, you get Scala, for instance.

>>58102482
>one comparison

The G3...as a counter example from a time period when AIM wanted to take Intel head on in desktops...trounced the P2 and edged out the P3 on integer ops.

>>58103003
>only for those same mistake-laden platforms to blow them all out of the weeds within a few years
>what is Moore's Law?
>what is marketshare?
>what is backwards compatibility?

Give two teams equal time, money, and lithography. Ask one to build a RISC processor, and the other x86. When finished test to see which is fastest.

The RISC chip will win without question.

But the world doesn't work that way. Compatibility is a huge issue. So is money for R&D. Intel was able to stay close enough in the 90's that no RISC chip knocked them out. As Moore's Law allowed everyone to go faster and faster, tasks which used to require RISC could be run on commodity x86.

That x86 won does not mean RISC is unsound or a meme. If you design your instruction set correctly up front it really does make performance on the die easier to achieve.

>>58105623

The primary savings on a RISC is that fewer registers are changed per operation.

A RISC processor uses less power and is cheaper to manufacture, however:

You can't ignore the difference in RAM usage by instructions when the bottleneck is the FSB

Some people claim that RISC is more pipelineable, but this is somewhat of a fallacy.

In CISC, the pipeline optimizations simply move to compile time which achieves economy of scale (write once, run many.)

Overall, believe it or not, CISC outperforms in the real world -- albeit for higher power consumption.

>>58105623
>>58106110

*note that maximum actual concurrency on a RISC will however be closer to the theoretical N-1 because of register consistency -- meaning:

Parallel code benefits from RISC.
Procedural code (where stack is popped) doesn't.

>>58086288
my guess that it was using software renderer which runs fast enough with pentium class and above CPU, but looked like shit compared to the opengl/glide renderer

>>58106810
simpler lighting, lots of fake precompute optimizations, low texture res

>>58106110
>The primary savings on a RISC is that fewer registers are changed per operation.
>and pipelining
>and parallelism
>and fewer stalls
>and better branch prediction
>and cache management
>and...

>You can't ignore the difference in RAM usage by instructions when the bottleneck is the FSB
And you can't ignore boundary issues when your instructions are 1-2 bytes (x86) and up to 15 bytes (x86-64). If your instruction straddles two pages you just fucked your cache up. If you insert nops for alignment then you might as well be using RISC.

PPC op codes (for example) were 4 bytes with strict alignment. Nice and easy for prefetch and cache management.

>Overall, believe it or not, CISC outperforms in the real world -- albeit for higher power consumption.
I don't believe it because when companies were challenging Intel head on CISC did not out perform.

>>58086288
simply put, that's what they were designed to run on, if it didn't run fast on a cpu, it just didn't run fast, because nobody had a 3D accelerator
3D accelerators were only becoming a thing that existed around when quake came out, and only closer to the end of the 90s did games come out expecting a 3D accelerator