The issue with Itanium was not that market didn’t care of superior performance. The issue was that Itanium is slow. Market didn’t care for theoretical beauty over actual performance.
It is not the first time Intel does something similar. In the 80’s they tried to introduce an ”object oriented” processor. It was ridiculously slow and no-one cared about it.
The market “demands” cheap, turnkey, easily replaceable programmers who don’t really know what they’re doing, and justifies this with “I made a website last weekend, programming is easy, you’re just pretending its hard to keep out competition”. Until software engineering is treated as actual professional engineering, time, money and resources will continue to be wasted frivolously.
Having a credentialing body that has to review and certify you just kills wages and innovation, and makes it take an outrageously long time to enter the field. But, more importantly, it will not prevent bad programmers from existing and shipping bad software.
Further, software engineering most assuredly is treated as actual professional engineering in most of the industry. That there are many companies that don’t treat it that way just means there are a lot of poorly led or non-software companies out there, which is no different than any other field.
What happens in Portugal is that although most people tend not to do the admission exam, all universities that give engineering degrees (including in computing) need to be certified by the order, and signing legal contracts for projects as Engineer does require the exam approval.
It was discontinued because less than 100 people applied for it over the course of several years.
To become a PE, first the candidate has to pass one of the Fundamentals of Engineering exam to become an engineer-in-training. Except, whoops, there wasn't ever a software specific FE exam; the most relevant one is the EE/Comp. E. exam. Take a look at the list of topics: https://ncees.org/wp-content/uploads/FE-Ele-CBT-specs.pdf Most developers aren't going to pass that even with a CS degree.
Secondly, you need 4-8 years of supervision by a licensed engineer. Again, whoops, there are barely any software developers with a PE license, so who would they get to supervise them?
Only then do you get to take the PE exam for software engineering. Frankly, the situation was so absurd that one has to suspect that NSPE didn't want to certify software developers as PEs.
Unlike other professions, software is ambigously placed in between art and commerce. Perhaps, the only art form that drives commerce heavily compared to music/painting etc. Just like there are no certifying bodies for qualified painters/sculptors/musicians (even if they exist, they are not stopping actual artists creating and sharing stuff), creating a certifying body for software will not take anyone anywhere.
I like the idea of professionalizing but also understand it can be constraining to the labor market, but could increase “quality” of products?
https://pt.wikipedia.org/wiki/Engenharia_Inform%C3%A1tica#Co...
Quality of assurance of 5 year studies, with assessement of university study plans.
Coding isn't and never will be Engineering.
Software Development right now has a little too much BroScience.
Thought of being told what is correct is just wrong. It would crush so many people. So much innovation would be stifled.
Had a test question in college asking what is better, white on black or black on white for text. Knew I was wasting my time with “formal” education.
The principles I was thinking of is the act of trade offs, cost, performance, time and TCO. And it isn't about which set of trade offs is right, it is about knowingly and justify those trade offs. Throughput Vs Latency, CPU vs Memory etc. A lot of these seems to be learned while they are on the job and from mistakes. I wish there are more of these thoughts being taught.
Yep, that's _exactly_ what the "I made a website last weekend, so programming isn't hard, programmers just pretend it's hard" types say.
What kind of innovation? Compiler optimizations? New language paradigms?
Am I right to think computers should adopt a more parallel architecture and design, and to expand on techs like OpenCL and CUDA, and generalize those technique to everything done by a computer, because we've hit a frequency limit?
We often see software being either sharded, distributed, load balanced, etc, but it seems that there is much more performance being possible if we start building chips that enforce the division of a task on the programmer. Of course it seems like it is a very big paradigm shift, which might be too expensive and complicated, but since bleeding edge techs like deep learning cannot be properly accomplished with traditional computers, I tend to believe the computer model of today is outdated.
https://en.wikipedia.org/wiki/Amdahl%27s_law
"...Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors. For example, if a program needs 20 hours using a single processor core, and a particular part of the program which takes one hour to execute cannot be parallelized, while the remaining 19 hours (p = 0.95) of execution time can be parallelized, then regardless of how many processors are devoted to a parallelized execution of this program, the minimum execution time cannot be less than that critical one hour. Hence, the theoretical speedup is limited to at most 20 times {\displaystyle \left({\dfrac {1}{1-p}}=20\right)}{\displaystyle \left({\dfrac {1}{1-p}}=20\right)}. For this reason, parallel computing with many processors is useful only for highly parallelizable programs..."
So, in answer to your question, no.
Intel Skylake has 8x execution ports with 6x way dispatch PER CORE. Typical code can achieve more than 1-instruction per clock tick, maybe 3 or 4 instructions/clock if you really work hard at your optimization. With 6x instructions/clock as the hard limit due to the uOp cache.
That's a normal CPU. Modern CPUs are incredibly parallel. They just "pretend" to be serial, so that the typical programmer doesn't have to think of those parallelization issues. A combination of compiler (aka: dependency cutting), and CPU (aka: Tomasulo's Algorithm) works together to achieve this parallelism (out-of-order, superscalar, pipelined).
----------
EPIC / VLIW are "leaky abstractions", which bleed the parallelism into the assembly language. But you don't get a lot of parallelism out of EPIC / VLIW, not compared to SIMD anyway.
So if you really have a huge amount of parallelism available, SIMD seems to be a superior methodology (and modern compilers can auto-vectorize loops when the compiler detects the parallelism).
I'm just not sure where EPIC / VLIW techniques come in handy. Its not parallel enough to compete with SIMD, but its still more complicated than traditional CPUs.
Because SIMD seems to be easier in practice when you actually need performance.
Every high-performance application seems to dip into explicit SIMD-parallelism: H264 / H265 encoders, GPU-based deep learning... video game shaders and raytracing, etc. etc. All of which get more performance from SIMD than VLIW / EPIC.
I think the market has spoken: if you are aiming for explicit instruction level parallelism, why not go for 32-way parallelism per clock tick (NVidia Volta or AMD RDNA architectures) instead of just 3 or 4 parallel assembly statements (aka a "bundle") that EPIC / VLIW Itanium can do?
----------
Another note: normal CPUs these days are approximately 6-way parallel. The Skylake i9-9900k can execute 6-uops per clock tick from the uop cache (ex: 2x Load instructions, 2x Additions, 1x XOR, 1x 512-bit SIMD statement). In addition to pipelines, reorder buffers, and other such tricks to "extract" more parallelism from instruction streams.
EPIC / VLIW just happens to sit in an uncomfortable spot. Its "different enough" that it requires new compiler algorithms and new ways of thinking. But its not "dramatic enough" such that it creates huge parallelism like SIMD can easily represent.
Back in the 90s and 00s, it was probably assumed that SIMD-compute was too hard to program, while traditional CPUs couldn't scale very easily.
EPIC / VLIW was wrong on both counts. OpenCL and CUDA made SIMD far easier to program, while traditional CPUs became increasingly parallel. And that is the history IMO.
Without AMD, the market would not have spoken anything.
What authority do you propose to gate who is and is not allowed to design semiconductors?
The x86 ISA started at 8 bits, sharing design elements with an earlier 4 bit device. It was successfully extended first to 16 and then 32 bits. Extension to 64 bits was inevitable. The fact that a hungry competitor fulfilled this inevitability before the market forced Intel to do so is an interesting detail and little more. The fact that this obvious evolution was all that was necessary to wipe out Itanium is telling.
Intel 80x86 architecture was successfully to 16 and then 32 bits, by Intel.
Intel would have been forced to extend x86 to 64 bits sans AMD. The market wanted address space. It did not want a "better" ISA, a new programming paradigm and all the other junk. The part of Intel still listening to customers understood this and Project Yamhill (Intel's 64 bit extension to x64) was underway at least a year before the first AMD x86_64 device appeared and after the first Itanium devices were sold. They knew they had a product the market didn't want and started moving to 64 bit x86 before AMD even delivered their first K8.
That sounds like an awesome idea, but it's actually a major issue because once you expose something you freeze it in time forever.
Pretty much all modern processors larger than in-order embedded cores are basically virtual machines implemented in hardware. The actual execution units are behind a sophisticated instruction decoder that schedules operations to achieve maximum instruction level parallelism and balance many other concerns including heat and power use in modern designs.
The presence of this translation layer frees the innermost core of the chip to evolve with almost total freedom. Even if fundamental innovations were discovered like practical trinary logic or quantum acceleration of some kind, this could safely be kept behind the instruction decoder.
EPIC on the other hand by exposing the core freezes it. I predict that if EPIC would have taken over eventually you'd have... drum roll... an instruction decoder for each EPIC "lane" or whatever that did exactly what today's instruction decoders do. It probably would have ended up evolving into a synchronous multithreaded vector processor with cores that look not unlike today's cores complete with pipelines and instruction schedulers and all the rest of that stuff.
I can imagine one scenario where EPIC and other designs that show their guts could work, but it would require the cooperation of operating system vendors. (Stop laughing!)
OSes could implement the instruction decoder layer in software, transpiling binaries from a standard bitcode like WASM, JVM bytecode, LLVM intermediate code, and/or even pre-existing instruction sets like X86 and ARM to the underlying instruction set of the processor core. Each new processor core would require what amounts to a driver that would look not unlike an LLVM code generator.
Have fun getting OS vendors to do that. Another major problem would be that CPU vendors would be incentivized to distribute these things as opaque blobs, making it very hard for open source OSes to support new chip versions. It would be a bit like the ARM / mobile phone binary blob hell, which is one of the factors making it hard to ship open source phone OSes or make open phones.
Keeping the instruction decoder on the silicon basically just avoids this whole shitshow. It lets the CPU vendors keep their innovations closed as they wish without imposing that closed-ness on the OS or apps.
The final issue with kernel compilation is that the performance probably wouldn't be much better than what we get now. We'd trade the overhead of an instruction decoder in silicon for a lot of JIT or AOT compilation and caching in the OS kernel. The performance and power use hit might be just as large or larger.
Here is an example that should be pretty familiar. When you have an auto-vectorizing compiler and it generates AVX instructions then you will have to recompile your program when AVX2 or AVX512 are out.
With EPIC this problem is extended across the entire program. The ADD instruction is twice as fast? You now have to recompile everything to use ADDv2.
We already have that; the bitcode is called "source code" and the instruction decoder is called a "compiler".
That is exactly what IBM and Unisys mainframes do with their language environments, and has been picked up on Windows Store, Android and watchOS as well.
x86* is a terrible architecture, though. The world would be a much better place without it.
Turing completeness and standardization > whiz-bang over-engineering
Turing completeness and standardization are fine, but there were and are better things to standardize on. "Something with a reasonable amount of thought going into it" is not "over-engineered."
Claiming "planned-obsolescence" would be reasonable if people weren't going through all of this work to maintain fifty years of (near) compatibility with an architecture originally used in a calculator.
It's not a bug. It's the scar tissue of hard won success. Long live x86!
It's easy to prove x86 is lousy by seeing its success in embedded and mobile devices: it hasn't had any, despite trying (Atom). ARM reigns supreme here.
x86 manages to hold on because of 1) backwards compatibility with proprietary software (namely Windows), and 2) inertia. We don't really notice it that much because we've covered over it with abstraction layers: almost no one writes assembly code any more.
We would be better off if we switched to something better, but we wouldn't notice it much; we might see a slight amount of power savings, and OS developers would be happier. But the benefits just aren't worth the costs. It's unfortunate, though: the major chipmakers should be able to just develop a nice, clean-sheet architecture which retains the good parts of x86 (like the PCIe bus and enumeration, things missing on ARM) and cleans up the bad things, and users shouldn't have to do anything other than make sure to select the Linux distro that matches that architecture. The presence of binary-only proprietary software that only works on x86(/64) is probably the biggest reason we're stuck with it: a competing CPU maker can't just come up with something new and have it "just work" (after getting their compiler changes merged into GCC and LLVM of course).
Funny thing.
Whether you boot a modern x86 system in 32 bit mode or 64 bit mode doesn't change the number of registers you're using. You're still using the 32-128 physical registers on the core. That's why x86_64 code isn't particularly faster (sometimes slower) than the same code compiled for x86_32 mode.
People have this zany idea that assembly language is a low level language. It's not. When the CPU executes 32 bit x86 code it "compiles" it to uops that are totally unrecognizable to us and use dozens to hundreds of registers.
The thing about embedded kinda exposes your mental bias. When you scale up the x86 instruction decoder from Intel Atom scale to Xeon scale, the instruction decoder gets a little bit more complicated, but it's given a ton more tools to use. So sure, Atom sucks at embedded, but x86 is still king at desktop and beyond, and ARM will never be able to challenge it.
If ARM wanted to challenge x86 in terms of single threaded performance, it would need to do the same thing x86 does: have a super complicated instruction decoder that maps the 32 logical registers defined by the ISA to its 128 physical ones, reschedules everything, renames stuff where appropriate, identify loads that can be elided, etc. And all of the advantages of having a simple ISA go out the window, because the ISA is an illusion.
Unfortunately Intel's Architecture Code Analyzer is dead. LLVM MCA is almost as good. I recommend you play around with it a bit some time. CPUs kinda don't give a crap if you're speculating four loop iterations ahead and you're just using the same few registers over and over again for multiple purposes.
Yes, but the x86 code itself can't address hundreds of registers, only a handful, because it assumes that's all there is (because that's all there was in the actual x86 processors way back). So the fact that you're using a complicated instruction decoder to get around this and make use of much more capable hardware underneath seems to me to be a big source of inefficiency: surely you would have more performance if your ISA could directly use the hardware resources, instead of needing a super complicated instruction decoder.
>So sure, Atom sucks at embedded, but x86 is still king at desktop and beyond, and ARM will never be able to challenge it.
ARM is already challenging it. They have ARM-64 servers now. Here's a place selling them, from a quick Google search: https://system76.com/servers/starling
>If ARM wanted to challenge x86 in terms of single threaded performance, it would need to do the same thing x86 does: have a super complicated instruction decoder that maps the 32 logical registers defined by the ISA to its 128 physical ones, reschedules everything, renames stuff where appropriate, identify loads that can be elided, etc.
Ok, then why not just make a new (or at least extended) ISA that makes direct use of all those things, instead of needing a super complicated instruction decoder? We already have lots of different ISAs for embedded CPUS: ARM has all kinds of variants (ARMv7, ARMv9, etc.), and MIPS does too. For best performance, you have to compile for the exact ISA you're targeting. We don't do this for desktop stuff mainly because Microsoft isn't going to make 30 different versions of Windows, but for embedded systems it's perfectly normal because everything is compiled from source.
TBH that's not challenging x86, any more than Atom is challenging ARM in the embedded space. The fact that they're for sale doesn't mean they're good. Those server CPUs have terrible performance per core.
> Ok, then why not just make a new (or at least extended) ISA that makes direct use of all those things, instead of needing a super complicated instruction decoder?
Directly accessing all the parts which are hidden behind the ISA is called VLIW, and the performance is terrible every time someone tries to reinvent it. It sucked even when Intel released the Itanium, which ran Windows.
The problem is that many of the data dependencies are dependent on timings which aren't available at compile time. (Integer division, for instance, the latency is sensitive to the values of its operands. To say nothing of cache timing.) A super complicated instruction decoder knows what data it has and what it doesn't while it is making decisions about what uops to dispatch on the half dozen or so lanes it's managing. A sufficiently advanced compiler does not, so a VLIW has to wait for all data in the half dozen or so lanes to become available before it is allowed to dispatch the instruction. If you want to do "interesting" rescheduling/renaming, you need to bring back the super complicated instruction decoder. (AFAIK later Itaniums started down the path of a complicated instruction decoder, but the Itanium was canned long before its complexity started approaching contemporary x86 standards. It would have been interesting to watch that develop.)
I think you're fundamentally misunderstanding how much stuff the instruction decoder does. To be fair, I'm not doing it its full justice, (how can I? It won't fit.) but I think you're too quick to think all a CPU does is perform the assembly instructions which are fed to it. As the article states, modern computers aren't just fast PDP-11s.
From the site "Starling Pro ARM is currently unavailable.
We’ll loop you in when we have more to share. Want to be the first to learn when it arrives? Get exclusive access before anyone else."
Which is sadly the typical story with ARM servers - limited availability.
In theory memory can be renamed as well, but this was not done untill the very last intel and amd architectures and, IIRC, it still has to be conclusively confirmed.
By that logic everything is lousy. x86 is lousy because it couldn't replace ARM. ARM is lousy because it couldn't replace x86.
You can run unmodified, compiled OS/360 code from the 1960s on a z15 machine built this year. The market values the tools and code it has invested in far more than any idealized computing model you care to speculate about.
The flaws in contemporary CPUs that device manufacturers perpetrated on their customers for almost 20 years are not the fault of C and its users. They are the fault of reckless manufacturers that squandered their reputation in the name of performance and, ironically, helped perpetuate the lack of innovation in programming techniques called out in this paper.