91–100 of 155 posts
Earlier quoted context omitted.
If I remember correctly it didn't have the biendian capability of the G4 so Virtual PC wouldn't run.
Virtual PC for Mac did get an update to run on the G5.
Earlier quoted context omitted.
price-to-performance is the last resort of a company that has failed at taking the performance crown. Nobody cuts prices more than they have to , but everyone adjusts prices to where they need to go to sell the product. Bulldozer was priced low because it was genuine garbage, it was actually slower than Phenom in a lot of cases (which blows the "it was about price to peformance!" thing out of the water - nobody regre…
But as a consumer, all I really care about is price/perf (and maybe power and a few other variables). Far to much of the tech industry runs around talking about how great the top dog (this week) is because they bin, push the engineering margins and sell some golden chip that ends up being .0000001% of their product line for some crazy $$$$$. During the early part of the bulldozer timeframe AMD could provide a competi…
But making a low-cost product was not what AMD set out to do at the outset, so that's not really a defense of the technical flaws in Bulldozer's design. Sure, when they realized it was a trainwreck, they cut prices. Everyone does that, though, and that wasn't plan A.
Nobody is going to go through the expense of R&D and design and tapeout and then just not sell the product because it sucks/"missed expectations". You adjust the price to wherever it needs to be to sell the product.
Even in laptop the bulldozer chips were way power-hungry (actually this matters a lot more than in desktop) and just not that good a performer.
It was Intel's CEO's job to smile and sell hyper-clocked 14nm chips going against TSMC 7nm and it was AMD's CEO's job to smile and sell bulldozers going up against sandy bridge. That's what officers of the company do, even when they know it's shit. You go to war with the army you have, not the one you want, and you go to market with the product you have, not the one you want.
Earlier quoted context omitted.
I think transmeta was MUCH better than Itanium. Itanium held the idea that we could accurately predict ILP at compile time (when the halting problem clearly states that we cannot). Transmeta said VLIW has the best theoretical PPA possible, so let's wrap that in a large, programmable JIT to analyze/optimize stuff to take advantage. Modern CPUs run quite a bit closer to transmeta, but they largely use fixed-function ha…
> Itanium held the idea that we could accurately predict ILP at compile time (when the halting problem clearly states that we cannot). I don't know where these notions are coming from. Compilers can (and do) reorder instructions to extract as much parallelism as possible. Further, SIMD has forced most compilers down a path of figuring out how to parallelize, at the instruction level, the processing of data. Further,…
> Compilers can (and do) reorder instructions to extract as much parallelism as possible. Further, SIMD has forced most compilers down a path of figuring out how to parallelize, at the instruction level, the processing of data.
Peephole optimizations are literally just rewrite rules and very limited in what they can accomplish, but we can't find an even moderately reliable way to optimize larger bits of the program. Auto-vectorization is still so bad that even unskilled devs can probably do a better job by hand.
> Further, most CPUs now-a-days are doing instruction reordering to try and extract as much instruction level parallelism out as possible.
This is true and proves my point rather than yours. If the compiler could do the job, then the VLIW output would be faster and not require OoO execution. It's telling that the fastest versions of Itanium were the ones that took the incoming VLIW commands and ripped them apart into a traditional OoO instruction window effectively negating the whole idea while preserving the externally-facing ISA.
> Figuring out what instructions can be run in parallel is a data dependency problem, one that compilers have been solving for years.
If they solved it years ago, then why do we get such MASSIVE ILP boosts from bigger instruction windows? Why is 2-3 instructions of throughput the maximum efficiency we can get from in-order systems?
For a bit of time, I ran an over clocked FX 8320 and crossfire 7970's. The heat that machine put out was tremendous. I only had a wall mounted AC unit so I had to practically take my shirt off when I loaded it up.
Ah yes, AMD/ATI crossfire. I had nearly forgotten that was a thing...
Earlier quoted context omitted.
Ze Fuji Quicksnap CPUs. (Single use analog pocket cameras)
Anymore details on those? I can't find any info on the CPUs inside
Earlier quoted context omitted.
Wow, a garbage collector implemented inside of the processor. Chip level support for objects. You can't fault Intel for their ambition here, just their common sense. And the whole thing is built for a world where everybody is writing code in Ada. I bet some compiler makers were salivating at the prospect of collecting all of those huge license fees from developers.
It was a different time - memory/CPU speed trade-offs were very different - we saw RISC once we were able to move cache on-chip (or very very close) - but at that point CISC made sense and the 432 pushed CISC to the extreme. IMHO the x86 won out (an d is still with us) because of all the CISCs of its time it was the closest to RISC when memory started to get a lot faster (almost all instructions make at most 1 memory…
I'm currently building a homebrew system built on the TMS99105A CPU, one of the final descendants of the TMS9900. It's a nifty little CPU. There's a lot of hidden little features once you dig in. It can actually address multiple separate 64k memory namespaces: data memory, instruction memory, macroinstruction memory, and mapped memory with the assistance of a then-standard chip. Normally these are all the same space…
This doesn't seem to be the best-researched article out there. If they thought Itanium was bad, they should have looked into the i860. Itanium was an attempt to fix a bunch of the i860 ideas. i860 quickly went from a supercomputer chip to a cheap DSP alternative (where it had at least the hope of hitting more than 10% of its theoretical performance). Intel iAPX 432 was preached as the second coming back in the 80s, b…
Cell (for example) was an asymmetric/hybrid multicore CPU; Apple Silicon is perhaps a modern example of asymmetric performance vs. efficiency cores, and also features special-purpose accelerator cores such as the neural engine.
The 432 had capability-based addressing. Speed-over-security has had a good run, but with some disastrous consequences. We may be seeing the return of capabilities with CHERI/ARM.
The 960 was an early superscalar design, supported tag bits, and was also a successful product.
This doesn't seem to be the best-researched article out there. If they thought Itanium was bad, they should have looked into the i860. Itanium was an attempt to fix a bunch of the i860 ideas. i860 quickly went from a supercomputer chip to a cheap DSP alternative (where it had at least the hope of hitting more than 10% of its theoretical performance). Intel iAPX 432 was preached as the second coming back in the 80s, b…
the Cell processor in the PS3 was not terrible in the PS3 and I doubt you ever worked on it. So talk about 'not the best-researched'. You can find many people singing it's praises, including me.
If the chip were so wonderful to work on, then it would still be in use today as the theoretical performance per area beats everything else by a wide margin.
Roadrunner was built in 2008. It would still be just barely off the top 500 list in 2021, but was decommissioned just FIVE years later in 2013. Its x86 replacement was already underway in 2010 TWO years after its launch.
I'm glad you got to work with the architecture you loved for so many years, but I think the rest of the world disagrees with your assessment.
Earlier quoted context omitted.
I think transmeta was MUCH better than Itanium. Itanium held the idea that we could accurately predict ILP at compile time (when the halting problem clearly states that we cannot). Transmeta said VLIW has the best theoretical PPA possible, so let's wrap that in a large, programmable JIT to analyze/optimize stuff to take advantage. Modern CPUs run quite a bit closer to transmeta, but they largely use fixed-function ha…
> Itanium held the idea that we could accurately predict ILP at compile time (when the halting problem clearly states that we cannot). I don't know where these notions are coming from. Compilers can (and do) reorder instructions to extract as much parallelism as possible. Further, SIMD has forced most compilers down a path of figuring out how to parallelize, at the instruction level, the processing of data. Further,…
The first thing to point out is that the dynamic filling of the execution units in superscalar hardware will always do no worse than whatever a pure-compiler solution can do, and will very frequently do better. Hardware can take advantage of dynamic opportunities, such as the ability to fill execution slots from code both before and after a branch (or even across function boundaries!), or being more responsive to instructions with data-dependent execution times. Yes, this does take not-insignificant amounts of hardware. But given the limitations of what compilers can statically do, it's not clear that you can put the savings to better use.
The second issue is that such an arrangement usually ends up with the hardware encoding microarchitectural details into the ISA. And when you do that, and you desire to change microarchitecture, you're stuck with either changing the ISA and dealing with attendant issues, or you have to add the hardware that you're theoretically saving in the first place.
On top of this, you're struck with practical performance being driven by the availability and adoption of sufficiently smart compilers, which is largely out of your control.
It's worth noting that you can ameliorate these issues to a larger degree if you restrict your inputs to a more structured subset of possible programs, i.e., you try to build an accelerator instead of a general-purpose CPU. And that's why you see more interesting architectures come out in the accelerator space. But for most general-purpose programs, you're not really going to do better than modern superscalar architectures, even with all the space and power they consume.