Slashdot Mirror
Apple's Redesigned Mac Pro is Coming in 2019 (theverge.com)
Apple's long-awaited update to the 2013 Mac Pro won't be released until sometime next year, the company told TechCrunch. From a report: We've known since a press roundtable in April 2017 that Apple was "completely rethinking" the Mac Pro, in the words of marketing chief Phil Schiller. Now, we have confirmation that the product is arriving next year after some speculation that it could make an appearance this year at a fall hardware event typically reserved for MacBook announcements.
"We want to be transparent and communicate openly with our pro community so we want them to know that the Mac Pro is a 2019 product. It's not something for this year," Tom Boger, Apple's senior director of Mac hardware product marketing, told TechCrunch. "In addition to transparency for pro customers on an individual basis, there's also a larger fiscal reasoning behind it."
"We want to be transparent and communicate openly with our pro community so we want them to know that the Mac Pro is a 2019 product. It's not something for this year," Tom Boger, Apple's senior director of Mac hardware product marketing, told TechCrunch. "In addition to transparency for pro customers on an individual basis, there's also a larger fiscal reasoning behind it."
My 2009 2x 6 core Xeon 3.4ghz system is faster than Apple's 2013 tubular 6 core Mac Pro that sells for $3000. Apple won't repair my Mac Pro's heat sensors but I'll be damned if I'll buy a new computer that costs a ton of money and runs slower. So I'm stuck with loud fans for the time being. It's frustrating as hell.
Remember kids, if you're not paying for the service, YOU ARE THE PRODUCT THAT IS BEING SOLD.
We want to be transparent and communicate openly with our pro community so we want them to know that the Mac Pro is a 2019 product. It's not something for this year,
Translation: We couldn't be bothered to get off our ass and work on this before now because we make all our money from iPhones these days.
In addition to transparency for pro customers on an individual basis, there's also a larger fiscal reasoning behind it.
If Apple wants to be transparent it might help if they didn't say things that only have meaning if you work at Apple. "Larger fiscal reasoning" could mean almost anything.
Velcro is not exotic or proprietary enough. They will use a patented, 3D printed, titanium, sintered, anodized clip with a custom bluetooth chip.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Seriously... "Fiscal Reasoning?!?" That's like saying Bill Gates needs to save for a few days to buy himself a Big Mac.
-- Sometimes you have to turn the lights off in order to see.
I doubt they could do much better than simply going back to the 2012 cheesegrater hardware, with a new motherboard that offers the same expansion capabilities but newer, faster/more CPU and RAM and so forth. Pluggable gfx cards, hard drives, absolutely no non-replaceable flash storage, optical drives, lots of standard USB I/O, ethernet, optical and analog audio, etc.
I also highly doubt they'll do it. They'll almost certainly just screw up again. Look at the mini and so on; just one more screwup after another last few iterations. There's no sign of sanity over there at all. And the iMac "Pro" is outright ridiculous.
That's okay, though. The cheesegraters will probably last for many years yet. I feel no burning need to give them money for yet another design fail.
OTOH, I'd be happy to give them money if they actually improved the mac pro beyond the cheesegrater. Or went back to the cheesegrater. Or actually improved the mini beyond its peak (which is not the current mini.) Or put out a decent mid-tower.
But again... breath-holding is not called for here. The evidence shows they're thoroughly lost in stupidland.
I've fallen off your lawn, and I can't get up.
They will Solder the Mouse and Keyboard in directly.
Too prevent counterfeit Mice and Keyboards, or something.
This will be called 'Courage".
It will be like they epoxied two mac-minis together. Nope. My prediction is it'll be pyramid shaped. They've done a cube. They've done a tube. This one will be a pyramid. Got to be! Nothing says innovation like a pyramid.
Pyramid
Pyramid
Pyramid
iPyramid
iPyramid Pro
Apple, come on! Just give us a tower with good cooling and standard expansion slots. That's what the pros want. This shouldn't take long to design, even if you want to make it all shiny.
If you can't handle designing a tower anymore, just give us a "blessed" motherboard that we can assemble our own computer out of. No support, etc. For pros only.
add segment_register:[disp + r32_A + r32_B*n], r32_C
That's no-one's idea of a classic RISC instruction.
And even though this gets decoded into micro-ops, the complex address generation is computed only once, and the memory order checks take advantage of this having been a single, fused instruction, so the semantic nuances are carried deep through the OOO pipeline.
There's so much crap on the Internet about RISC, it blows my mind.
50% of the RISC hype was about being able to compete against the legacy vendors with smaller, cheaper design teams.
You can call x86 RISC, but it never got cheaper to design. The cost of the design is almost a superset of its CISC and RISC elements (I'm pretty sure its hybrid nature creates headaches above and beyond the sum of its parts).
The RISC hype bubble had some validity for roughly a five-year period before Intel launched the Pentium Pro in 1995 (RISC hype persisted outside the clue nucleus for another five years after that for largely political reasons). The Pentium Pro is where the complexity of the CPU core and the complexity of the memory subsystem (and latency hiding) began to cross over. There is no possible way to design a processor with a deep, concurrent queue of in-flight cache and memory transactions (with SMP coherence), and extensive latency hiding in the execution engine using a small design team.
Wikipedia's article on the Pentium Pro makes it sounds like its performance sucked, but it held up amazingly well on mixed Windows NT server workloads compared to any RISC architecture at anywhere near the price (it's deep OOO latency-hiding was a huge boon to memory thrashing compared to in-order RISC with wider dispatch.)
Wide dispatch = straight line speed (American car).
OOO latency absorbers = cornering speed (German car).
Of course, most benchmarks are biased to the salt-flat quarter mile.
Another thing, the majority of CISC junk-in-the-trunk (e.g. 286 call gates) is subject to exponential shrinkage; barely a third decimal point by the time you reach a billion transistors.
On the matter of superscalar execution, this naturally prioritizes the quick and the fleeting (only these instructions could pair up in the P5). Superscalar under OOO is a different beast: now the killer dimension becomes instruction flight time. This for the macro-ops at the level of the retirement order buffer, the micro-ops at the level of the dispatch buffer, and the outstanding memory operations at the level of the memory order buffer.
Intel's x86 architecture is more HISC than RISC: Hasty Instruction Set Computing. The faster you retire the operations (at any level), the sooner you free up precious reservation buffers. (x86 never inched one step closer to a conventional load/store architecture, the cardinal 'R' in RISC; most especially, transient addresses off the stack frame do not retire to the register model in x86—what a waste of reservation stations—because they are never register-assigned in the first place.)
Micro-operation
If some traditional RISC architecture adds macro-op fusion to its internal implementation, do I get to declare that "modern MIPS is nothing more than a MIPS translation layer around a CISC chip, anyway"?
Since the early 1990s, this debate has been my #1 personal case study in technological propaganda, herd following, and revisionist misinformation.
I originally got onto this file asking myself a hard question: just who is this messianic charlatan named Steve Jobs?
No, since the Pentium Pro in 1995, which already employed microcode translation; not with the Pentium IV, which was deliberately brain damaged to win the MHz war (I don't even know how to classify the trace cache, except ungodly hot); again with the Core Duo, after that (god bless Israel).
How Israel saved Intel
What you are calling a RISC core has more proprietary CISC-world abstraction violations than you could shake a stick at (these are primarily performance hacks, but nonetheless).
Explain to me why micro-op fission gets more air time in your lexicon than macro-op fusion? Because modern x86 processors use both tricks to obtain a working representation which minimizes in-flight resource consumption (which is similar to RISC, but is not directly motivated by either "simple" or "reduced"—hasty is a better proxy—and none of this is reflected in the instruction set, as is patently obvious). And even then, the micro-op fission remains semantically distinct from an actual RISC instruction stream deep into the pipeline in small yet critical details (internal modern x86 micro-ops are fuzzy creatures, but these implementation tricks aren't publicly documented).
There's actually a more basic level underneath RISC: readers and writers attached to separate busses. But this is so low level is tends to make your ISA non-portable to the next iteration, so no-one sane goes here (I'm looking at you, Itanium, even though after you started here, you went another 100 miles downstream).
write_assert rA to register_bus_1
read rB from register bus_1
read rC from register bus_1
write_deassert rA to register_bus_1
Register files tend to be multiple ported, so there would be other register busses available concurrently. That's all one clock cycle if your macro-op fusion puts Humpty back together again (and not analogous to any RISC instruction).
mov ebx, eax
mov ecx, eax
In a transport triggered architecture-like world, these two instructions could be fused into a single assertion of eax, and a simultaneous read by register file ebx and register file ecx off the same bus.
But you'd still call it a RISC core, wouldn't you, so long as the internal representation was granulated into some kind of small, vaguely uniform ops? (Macro or micro, who cares?)
Between 1985 and 1995, I must have read many dozen articles in computer magazines about how x86 CISC could never grow up to compete against the Big Boys (where RISC was the prototypical Big Boy). This was a potent brew of aesthetic disgust (with which I largely concurred), competitive ambition, and mentally defective bullshit—as history now records. In order to advance this kind of claim in a falsifiable way, RISC has to actually mean something.
Back when I wrote a fair amount of 486 code, I mainly worked in a RISC subset (most of which dated back to the 8086 or were simple extensions), heavily augmented with non-RISC ModR/M sib addressing modes. There was no OOO, so there was no need for an intermediate micro-op representation: the complex read/modify/write instruction were decomposed into RISC primitives (load,operation,store) by an execution-engine state machine (which I suppose you could call a micro-op sequencer on the understanding that the machine supported exactly one in-flight macro-op. A non-distinction without a difference?) Compared to 386, 486 felt a bit RISCy because many of your core operations had a single-cycle execution time (and you tended to ignore program fetch delays, because of the concurrent internal i-cache).
Once you get into OOO, you need track multiple i