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."

Comments

Apple has been lost for a while, hardware-wise.

[fyngyrz]

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.

Re:My Mac Pro is faster than Apple's Mac Pro

[OrangeTide]

I'm still using my 2008 Mac Pro as my main game system (dual boot Windows 7), with a 1070 Ti it still runs the games I play pretty nicely (MMOs mainly) and doesn't have nearly as much fan noise of my wife's Dell.

I think the era where your computer was obsolete every 2 years is over.

Re:My Mac Pro is faster than Apple's Mac Pro

[omnichad]

Considering they're just dealing with loud fans, it's a better situation already. The fact is, you can buy heat sensors on eBay for under $5 if it's really worth it to you.

you have to bypass and screw around with something that shouldn't be broken in the first place?

Because other brands of computer never have failing components out of warranty? Because this computer has heat sensors beyond what typical PCs have, so there's more to fail? I'm not a huge Mac fan, but that's a bit of a stretch of an argument.

Hasty Instruction Set Computing

[epine]

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

Execution optimization has gone even further; processors not only translate many machine instructions into a series of uops, but also do the opposite when appropriate; they combine certain machine instruction sequences (such as a compare followed by a conditional jump) into a more complex uop. This is also known as macro-op fusion.

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?

botanist vs engineer

[epine]

You're right. It's not. That, sir, is an x86 instruction, which the x86 translation layer takes as input and passes to a RISC core. Intel, at least, has been doing this since the Core series was released.

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