MIPS vs x86
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
Why did x86 surpass MIPS?
more winfags = more money
>>52167471
Because when it came to powerful processors, the only ones available were PPC and x86.
Microsoft chose to support x86, so naturally x86 became the dominant desktop platform in that regard.
Apple chose PPC at first, but when it became clear that IBM was not going to improve the energy efficiency, they switched to x86 to improve their laptops.
With both Microsoft and Apple allowing this piss poor architecture to dominate all their computer platforms, we finally had the x86 dominance.
because intel had/has a ton of money and it turned out that shitty instruction sets don't really matter at all
also most historic RISC designs are really memory inefficient
DOS and Windows
>>52167537
dumbest post of 2016
>>52167471
MIPS = million instructions per second
x86 = x86 times more instructions per second
Obvious
>>52167593
lel
Seriously though, what is the most efficient instruction set?
>>52167701
probably some kind of VLIW except nobody can write optimizing compilers gud enuf
>>52167701
That depends on the implementation. x86 currently smokes everything at the high end.
>>52167701
Arm but it is shitte at more than 9 watts
X86 is shutte at less than 6 watts
Mips is shitte when using electricity
PPC is 2hot2handle
I think the nvidia's and amd's propietary gpu architecture is pretty efficient when scalled down, for computing and stuff
>>52167701
x86_64
It has a very powerful instruction set. Actually all the alternatives are pretty much incomplete, so that leaves x86_64 only there by the process of elimination. ARM doesn't have a lot of instructions that other architectures do, so count ARM out
>>52167789
>all the alternatives are pretty much incomplete
i want to hear more about your crazy ideas
>>52167779
Almost nothing you said is true.
>>52167471
x86 was never behind MIPS in anything but performance. It was always a high-end chip for high-end systems, and in that market it did very well until x86 and PC compatibles in general surpassed a baseline where they were passably good at most of the tasks you used to pull out a RISC workstation for.
Not to mention Intel's financial juggernaut meant the company could throw nothing but money at bettering x86 chips while SGI had to split their relatively small income between systems development, software development, and everything else to keep the entire ecosystem going.
>>52167537
>Because when it came to powerful processors, the only ones available were PPC and x86.
Nobody ever used x86 because it was powerful, they used it because it was compatible. Intel was always outclassed from the beginning, whether by the Motorola 68000 and the Natsemi 32032 in the early days or the Alpha and UltraSPARC in the '90s. PPC enjoyed a brief few moments in the sun with the 601 and 604 being fitted into RS/6000s, but after that point development split and the series was relegated to Apple shitboxes and their various clones for the next decade.
The high-end was always the sole domain of RISC and various special snowflakes, split between Alpha, MIPS, SPARC, PA-RISC, POWER, later Itanium as well. x86 couldn't even hold a candle to any of these until the Pentium Pro, and didn't start to really reach their level until the mid 2000s.
>>52167701
>>52167746
>>52167779
>>52167789
wrong.
>>52167738
has it.
If we ever get AIs up and running one of the first things i suspect they'll make is a proper compiler for VLIW-based designs.
Then after we enjoy the 300%+ performance uplift over whatever is available at the time, we'll be murdered to make way for the new robotic overlords.
>>52167471
IBM
>>52167789
>RISC architectures don't have as many instructions as CISC
what a shocker
>>52167959
>x86 was never behind MIPS in anything but performance.
That's like saying Romney was never behind Obama in anything but one election.
It's the only thing that matters.
>>52167789
doesn't matter for shit when none of the software uses those instructions, it just bloats out the chip, makes it slower and more complex
ARM and other RISC designs emphasized on the most commonly used instructions and optimized the shit out of the chip for them, leading to an overall more simple and faster design that can be clocked faster as well, though that latter part isn't working as well as many would have hoped nowadays
>2016
>using x86
>https://github.com/xoreaxeaxeax/sinkhole/blob/master/sinkhole.asm
When will OpenRISC become viable?
>>52169313
>It's the only thing that matters.
No, not really. If that was the case, then x86 would have been dead before it was even born and gamertards would be shitposting in SGI vs HP threads. Price and compatibility are huge considerations in personal computing, it doesn't matter if a particular system will help your accountants shave two or so seconds off of recalculating their spreadsheets when fitting them out with some shiny new Sun workstations will cost you millions plus licensing an unfamiliar new spreadsheet application that doesn't include some of the same features as your old software plus training them to use the new ecosystem.
>>52167471
OP, you can implement and improve that MIPS R3000 core on an FPGA. https://github.com/alfikpl/aoR3000
MIPS always pushed hard on the embedded systems front and pretty much nothing else.
There were basically the high-end ARM of that era.
An array of R4000 series chips with their native 64bit capability was excellent for high powered workstations with 4GB of RAM.
>>52169551
MIPS didn't really become embedded-only until recently, for most of its history it was quite a high-performance desktop/server chip. In the same way ARM started out as a desktop chip as well.
>>52167471
I guess Intel made had the right idea to spend a huge shitload of money on engineers without worrying, and that in the end paid off.
If you think about it, Intel processors beat the crap out of pretty much anything on the high end and they are cheaper.
RISC architecture is gonna change everything
>>52167701
SPARC64 but Oracle and their ass eating fuck friend Fujitsu have it locked up pretty well to maintain their business model
>2016
>not using the best arch
http://riscv.org/
>>52167701
their isn't really
but generally theirs two schools of thought, RISC few simple instructions that take the least amount of clock cycles to complete, complex instructions have to be a combination of these, See ARM, PPC, MIPS.
CISC lots of instructions, with very complex instructions that can take lots of clock cycles to complete.
CISC is easier to write software for but is very complex hardware wise, it also requires less memory for programs since programs generally have less instructions in them, x86 and its variants are in this catagory.
RISC is very simple hardware wise, but programs take more memory and its harder to write software for and harder to optimize that software.
RISC is the prefered approach in the modern world since CPUs are getting exponentially more complex on the hardware side and only Intel has the RnD money to keep developing CISC.
>>52173334
thanks. this is like my microP class.
>>52173334
only compiler writers will notice the difference.
RISC is better in my opinion since there is less software voodoo on the chip itself
>>52173499
its the preferred modern arch, but x86 has a monopoly on the high end and intel has buckets of money to poor into development so they don't give a fuck.
>>52173462
pretty much taken straight from my text book brotha
>>52173334
You do realize that people don't write programs in assembly language? Specially not user end applications and even operating systems are for the vast majority built in higher level languages like C, meaning that there's no real difference in what hardware architecture is being used.
Not only that, because of the way x86 works (i.e microcode interpreting binaries rather than binaries being run as is like most other architectures) it's actually been very RISC-esque in the way it actually executes the binaries ever since the 90's. What this means is that they have been able to make enormous changes in the way the x86 chips work without breaking binary compatibility. Modern day x86 chips are after all referred to as "post RISC" (i.e RISC chips with things like heavy out of order execution that used to be the domain of CISC chips) architectures, not "post CISC".
In short: /v/ pls go...
>>52173601
it still has an impact on compiled program memory usage.
second most arch's have microcode, and it has nothing to do with it being RISC or CISC, its with the fact its a better way to do it, things can be fixed post launch without having to recall all the chips.
>>52173334
This CISC vs. RISC debate is completely irrelevant for modern cpu's.
Modern cpus (except for embedded), are usually superscaler and OoO (out of order). They execute multiple instructions at the same time (superscaler) and they re-order the instruction stream in flight to get more instruction level parallelism. They normally also do branch prediction. Based on the history of code execution they can execute down the most likely direction of a branch before the code that determines the state of the if() even finishes executing. If the guess was wrong, the work done down the wrong branch is discarded. On top of all of that is the massive cache hierarchy and data pre-fetching (based on observing memory access patterns)
The frontend RISC vs CISC really means nothing anymore.
It is only a question of price/performance, compatibility, power efficiency, and RAS (reliability, availability and scale-ability) features. i.e. if you need to hotswap a memory module, you won't do that on a desktop processor.
Intel has been killing everybody since the PPro, except in RAS features, and they have been working on that for a long time. Even if a processor is faster, it does not matter. A processor has to be 2x faster for you to bother porting your code. The DEC Alpha was almost 2x faster for such a short period of time that people did not move.
>>52173334
x86 is only CISC on the surface. Modern x86 CPUs take complex x86 instructions and break them into small "micro-ops" which are then executed in parallel much like RISC instructions. Having the underlying hardware be RISC-like means they can reduce the amount of hardware dedicated to unique heavy and unique instructions and use those savings to increase the amount of hardware dedicated to those simpler instructions. One of the significant benefits of this method is that you can write "simplified" software for x86(CISC) hardware and still get 95-99% of the benefits of a RISC architecture.
>>52173661
this
modern 'CISC' cpu's are just RISC chips that use internal software to emulate CISC
>>52173777
>modern 'CISC' cpu's
you mean CISC architectures that had billions of RnD dollars shit into them
>>52173833
And you think IBM does not spend a fortune to make it's mainframe cpus?
IBM's mainframe stuff executes the same thing at least twice in two different places and double checks the results before committing the results. Do you think visa and MC are running on x86? probably not.
Why hate on x86? Lots of people are trying to do better, including intel itself with the Itanium. Shit Intel has mfg lots of risc chips itself (I saw an old i860 supercomputer once).
RISC vs CISC hasn't mattered for years
>MIPS (SGI), POWER (Apple, IBM and Motorola), SPARC (Sun), PA-RISC (HP) and Alpha (DEC/Compaq/HP) etc were too expensive, relegating them to servers/workstations or HPC
>x86 was comparatively cheaper
>Intel started putting x86 on steroids since Pentium Pro
>They tried to do a clean sheet design with Itanium but it failed (but conveniently - they managed to persuade everyone else to drop their proprietary RISC architectures in order to jump on the Itanium hype train)
>In the last few years Intel has been putting more RAS/high end Itanium features in to Xeons whilst keeping the price low vs SPARC/POWER
>This has caused POWER and SPARC to die off slowly
>>52167471
Because x86 and x86_64 is RISC deep down inside
>>52174000
>>MIPS (SGI), POWER (Apple, IBM and Motorola), SPARC (Sun), PA-RISC (HP) and Alpha (DEC/Compaq/HP) etc were too expensive, relegating them to servers/workstations or HPC
None of those were ever targeted at the home or office, they were designed exactly for HPC jobs.
>>52167471
Because MIPS is shit.
>>52167959
>Alpha and UltraSPARC in the '90s
Completely different markets; Alphas and SPARCs outperformed them, but were "workstation grade" chips as opposed to "desktop grade" -- you didn't cross-shop a Pentium and an Alpha *on the basis of chip performance* anyway since the operating systems you ran on them were largely mutually exclusive (outside of stuff like NT Alpha, which was an abortion).
>Not to mention Intel's financial juggernaut
Honestly more than anything else, the domination of Intel is more due to the fact that the other major chip designers (i.e., those that had the clout to push a non-x86/ISA based architecture; by the time AMD was real competition, Intel had already beat DEC/IBM/Sun/etc) thought the future was in the high-end, not the mid-to-low-end. Even today, outside of AMD selling largely compatible chips, the only real competition in the field of processors is in the performance space *below* (or, at least, willing to sacrifice lots of performance for lower power footprints) desktop processors, like ARM's resurgence.
Intel's where it is because they picked the right horse in the '70s and '80s, and the other big computer companies aimed too high.
>>52173601
>>52173655
>>52173777
>>52173661
This. Modern chips that implement x86 or x86_64 have silicon that converts those instruction sets to the internal instruction set that the core itself runs; the manufacturers do not publish these internal instruction sets (and it's typically impossible to actually create binaries built on them) so they can make sweeping changes to the instruction set between iterations of silicon and still keep compatibility with the instruction set that compilers generate binaries for.
>>52177823
Of course, they were never made to compete with x86 in that market space, despite the wishful thinking of many magazine columnists. I'm just saying that x86 didn't win in the end because it was powerful, as that anon implied. It won because it had IBM and a massive software library behind it, a better value for home and office use and it was good enough for most jobs.
>>52173655
>They normally also do branch prediction. Based on the history of code execution they can execute down the most likely direction of a branch before the code that determines the state of the if() even finishes executing. If the guess was wrong, the work done down the wrong branch is discarded. On top of all of that is the massive cache hierarchy and data pre-fetching (based on observing memory access patterns)
all chips besides toy ones do branch prediction. what you are describing is called 'speculative execution'.
v12 graphics a shit
>>52168854
>wrong
correct them then
Linux is what killed it. Running an AMD opteron server with Linux killed SGI. My old SGI O2 server is a meme compared to what a Xeon system with Nvidia Titan can do.
>>52181045
it's almost like an entry-level 2D graphics workstation from 1999 couldn't hope to hold a candle to modern mid-range general purpose workstation, fascinating
SGI died because its graphical superiority was becoming stagnant while PC platforms were really starting to shine, the very last of their workstations didn't even feature SGI engineered graphics systems
>>52180239
he did dumbass
why did RISC desktop chips stagnate so much compared to x86 in the 2000s? did the dotcom bubble really hit them that hard, or did the "make it simple and clock it fast" philosophy just not pan out the way they expected?
>>52183574
>make it simple
Logically speaking this isn't possible with SIMD and MIMO architectures.
Maybe the electrical engineers got butthurt when they realized that it was impossible to make a pristine architecture that still did what people wanted.
>>52167471
MIPS had a very strong portfolio of products up until ARM began to really compete with some of the best MIPS chips. I would say ARM is outpacing x86 now depending on how you look at itand it has a very bright future in all kinds of applications.
>>52184616
Shit, I don't think ARM was capable of touching anything SGI was putting out back when it was actually putting stuff out. Now in the embedded market, definitely.
