New MacPro predictions? Hopes? Fears?

[Daniel Reed]

Nope, as a long time Mac and multi-platform user, the reality of the situation is future prospects for new MacOS hardware will be slim.

The current thinking is Apple skipped the 6th gen Intel CPUs because of well known problems with it.

We should soon see an Apple announcement for a new MBP release and a maybe but doubtful release of a new iMac this year; however,
the dual AMD "Vega 10" GPU on one board w/ expected TDP of 300 Watts rumored as the "Pro" option for iMac (same TDP as current top 5K iMac option) isn't expected to be available until 2017.
This dual GPU iMac "Pro" may be positioned my Apple as the Mac Pro replacement, especially if they offer more then 4 cores - "look at our innovation, we shrunk a Mac Pro into an iMac!!!"

Maybe it will at least be black :undecided:


From what I hear unofficially and of speculation in the bay area tech world in terms of apple and their mid-road plans:
No new Mac Pro or Mac mini is expected (discontinued unofficially),
Further slimming down of the MacOS product line,
Apple is exiting the Mac PC business in favor of focusing on iOS for all consumer computing needs,
But will continue to release thinner Macs with integrated screens for at least 4 more years as they continue to strive to shrink the power of a PC with their own chips into a tablet (iMac, MBP, MB)

 

[Jeff Kilgroe]

There hasn't been a significant boost in Xeon CPU capability or performance for several generations now. Intel has shifted their focus of the platform over to servers and away from performance workstations. With the latest two generations (the ones newer than what's in the 2013 Mac Pro), all we gain is the ability to use DDR4 memory at lower densities and higher cost per module. And we gain the option of a couple more cores on a single CPU, at the expense of slower clock rates and higher purchase price. While people are screaming for upgrades, I can totally see why Apple has not bothered. What they really needed to offer was upgraded GPUs. But more than that, they needed to actually support and utilize the GPUs they already have.

I'd love to see them release a new Mac Pro cylinder with 3 x Thunderbolt 3 ports, 3 x USB 3.1 ports, i7 CPU with the option of 6, 8 or 10 cores and dual nVidia Pascal 8GB (GTX 1080) GPUs. That would be far more cost-effective and attractive to the creative market and would sell like crazy.

 

[Daniel Reed]

Tim Cook's Apple views itself as its only competition.

Dragging out MacOS only delays the goal - iOS for the masses on the vertically integrated platform they control.
This is why they won't license MacOS out to HP/Dell/etc or sell off that division - it would only delay or provide competition to their goals
Upper Apple management attitude is rumored to be: "Sure, some will go to Microsoft, but they'll hate it, and come back to Apple and embrace iOS"
This isn't too shocking really, many believe it is inevitable - mobile OS systems wil mature and replace what came before it for the masses.
The difference is Cook has turned it into a faster paced race then what some consider responsible or the english meaning of word ethical.

An interesting tidbit to consider as well:
Rumors have it Apple has been quicker then usual on take-down notices and other litigation attempts to control any media related to "suggestions" it plans to end the Mac platform.
Which makes some sense, I'm not a lawyer, but i suspect some outfits might sue - so I imagine its another layer of the complex Onion Apple must deal with as it fully transitions to a post PC company



The moderately good news is Microsoft has added Bash and ELF binary support as a subsystem to win10ae - better then VM, but still an emulated kernel, and running inside windows.
https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
https://msdn.microsoft.com/en-us/commandline/wsl/about#


I wish MS would release a Pro version on Win10 with a lot of legacy support factors removed, more features turned on, less processes running in the background, no F#$%ing auto updates, and with a focus on stability.

 

[Jarek Zabczynski]

I had a dream last night that they showed a prototype MacPro to some people. There was no case on it, just the internals could be seen. It was literally a desktop design, tower on its side. It had one Xeon processor, 4 ram slots, 4 USB 3.1 ports, 2 TB3/USBC ports, 2 double wide PCI slots, they were empty and there was some sort of integrated GPU. Boot was a PCIe SSD and there were 4 hard drive slots, 2 for 3.5" and 2 for 2.5"

The entire thing was pretty compact, about half the size of a cMP.

 

[Frank Glencairn]

I wish MS would release a Pro version on Win10 with a lot of legacy support factors removed, more features turned on, less processes running in the background, no F#$%ing auto updates, and with a focus on stability.

If the few clicks to disable those auto updates/background tasks are too much for you, to be bothered with, Win isn't for you.

 

[Antony Newman]

Intel have made some definite improvement in the single core performance of the XEON chips in the last few years.

Geekbench : Single Core Performance : Intel

3223 : Xeon in 12 core Mac Pro (2013) @ 2.7GHz : [Intel 22nm] : >$2000
3827 : State of the art Xeon (2016) : E5-2699 V4 @ 3.6GHz : [Intel 14nm = real_world 13.4nm] : >$4000

Thats a 20% increase per core performance.


Geekbench : Single Core Performance : Apple

3450 : Apple 10 Fusion @ 2.33 GHz : iPhone7 : [TSMC 16FF+ = real world 18.3nm] : Bill of materials estimate <$30


2 core iPhone vs 12 Core MacPro 2013

https://twitter.com/MattMariska/status/776495257311584261

Iphone is approximately 1/4 the speed of the MacPro - not bad given Apples device is using a fraction of the electrical power.


Speculation

Apple could make a 8 core A10_Fusion based CPU that would outperform a Xeon in a Mac Pro.

In 2017 Apple could if they wished make a 32 core that outperforms almost all 14nm Xeons - for a fraction of the cost (under $400) {Sidenote : Intel will help Apple switch people away from 3.5mm Headphone Jacks!}

In 2018 Apple - will switch over to their own ARM-v8-SVE + GPU SOCs on TSMC 7nm (or Intel 10nm if Intel let them)

In 2019 Mclaren will start testing to hollow LiIon Batteries (part of Apples patent portfolio)

AJ

 

[Zack Birlew]

Now, I can't speak for RED 6K+ editing but my 2007 Mac Pro still kicks butt for a lot of things and is still in the running with current systems on its Windows 7 Bootcamp partition. I put together two Dell Hackintoshes based on an XPS 8700 and a $30 XPS 8300 I picked up and those are pretty nice too and running Mavericks. I meant to get Final Cut Pro X but I haven't really gotten around to it as Premiere with the Adobe workflow is what we primarily use at Babs Do on Windows computers with our various 3D and visual effects softwares. I think it is that mixed software aspect of high end production these days that just doesn't fit with the Apple workflow. As has been mentioned, a lot of different rendering engines and 3D programs work best with CUDA which AMD Radeons just don't have and while the Mac Pro's dual GPUs may be powerful, the lack of options for visual effects folks is a big factor when considering getting a Mac over a PC. When a 3D program comes out, it's always Windows first and the Mac version comes later. I remember when that wasn't even an option for software makers and so much that the reverse was the case. Nowadays, a Mac is second even in post and all of your work needs to be transferable to a PC and able to go back and forth, whether it's exchanging video or offloading to visual effects. If you're on a PC too, that's not a step you have to worry about. Some things I do find work better with Apple, for instance, Pro Tools seems to work a lot better on Mac for me than PC as I've had Pro Tools disappear on me completely before and it's always booted fine on my Mac. With what I do now, all of my creative needs are met with Windows and any effects that I've only had on Mac, like the wonderful Coremelt plugins I won at a FCPUG meeting years ago, are now met with other software and plugins and the same goes for audio. I had been wanting to pick up a MacBook Pro or newer Mac Pro about this time last year and I ultimately had to ask myself, "Why?". If there were anything I wanted a Mac for now it's to have something to keep around to edit and update my older projects from FCP7 but otherwise there's nothing else it does differently than my Windows machines. Macs aren't special anymore, there's no Final Cut Pro Studio buzz, no blazing hardware, and no exclusive pro apps like Shake to look towards. If people want an easy interface to surf the web and write papers with then they have their phones, tablets, and both Google Chrome and MS Office work the same on both platforms. If Apple is going to continue making computers, then they need to step up their game and provide real configurable options and update their lines regularly with some real benefits being added to their pro App lineup. If they can't focus enough attention to do that then they might as well offload their computer business to someone else who can.

 

[Antony Newman]

If Metal exptertise is needed for an up-and-coming CUDA platform.... does that mean Volta is going to join the Fruit Factory?

If Nvidia doesn't have the necessary inhouse expertise - (complete guess) ?6-8 months? to develope device drivers ... could mean something is being cooked for mid 2017.

Maybe AMDs lack of funds, and concentration on the low end has forced Apple to look elsewhere?

AJ

 

[Wayne Morellini]

My comcern is that we won't see a mass market Linux platform standard better than Mac OS anytime soon.

We used to buy machines based on monumental improvements (but maybe we just need B&W video on a Amstrad PCW?). But gpu's and other processing platforms is where we have been getting these improvements for over 15 years. But they have not been keeping up, with token GPU use up till recent times. But GPU's are bloated beasts themselves (though lowcost mass components compared to rockets). Intel is forever, seemingly, stuck in the past x86 larrabee etc days (we need a x16 future, but they have not thought of that. Maybe x20, or x25 /30). But very small general purpose enabled processing arrays would bring monumental improvement.

So, the reality, is a number of manufacturers, including Nvidia, are supporting Risc-V processor development. This at least should lend itself to many more full processors per i7, or ARM, transistor counts. The embedded versions allow a greater density. The main issue is the maths circuites. They are so sixablebas to dwarf gains in processor core density gains. You can simply make light weight maths on chip for not many extra transistors, and parallel 12 to 12,000+ cores in place of the CPU/GPU combination. The maths can simply be an complimentary (cantnremember at the moment) addition and carry test function, with other existing functions. However, I've been working towards improving that.

So, there are things afoot in the background, and I don't know what they are planning but this could be part of it. I'm not involved with the webassembly group, but think it might be a good idea to align the instruction set to either a subset of java or as a virtual form of RISC-V. Would make a good industry specification.

 

[Antony Newman]

You may have some good points.

IMO, the issues that Intel (and others) are hitting:
+) Chips become cost innefective to make above a certain size due to less than 100% yield.
+) The area envelope dictates the rate at which heat can be wicked away from the chip.
+) Even if transistor sizes could reduce by a factor of 4, they could not all be switched concurrently without the chip melting.
+) This creates the Dark Silicon problem (i.e. That parts of the chips need to go into a low power mode / not all used at once).
+) Intels use of the AVX (512 bit) extension was an attempt to Do more in one clock cycle, to increase its Instructions-Per-Clock (i.e. Do more with the same power envelope)
+) BUT the maximum speed up (using AVX and/or a boatload of CPUs) is limited by how effectively the code can be parallelised (and the reason why as a relatively low CPU core count, there is almost no gain in adding more CPUs)

Getting CPUs to work on multiple sets of data generally requires More cores, with them all running the same sort of program.
Getting GPUs to work on multiple sets of data is generally more efficient - as that is what they are designed for (but a pain to code for).

With these sort of brick walls being hit - there is a great opportunity to concetrate on the problem rather than turn computers into storage heaters....

AJ

 

[Antony Newman]

... it's easier to see how throwing more money, more cores and a few power stations can help at the extreme end of supercomputing:

China's super duper 10,000,000 core computer (3rd on the list below), had lots of big numbers on 'Peak' performance, but the stark
reality was that when you wanted to compile an run a program .. you would only get 0.4% efficiency.

Conversely, have a look at the (Fujitsu) K from 2011 that achieved 5.3% efficiency....

AJ

 

[Antony Newman]

From a Programmers perspective:

+) ideally, it would be great to have a language that scale effectively - perhaps something like MILK
http://news.mit.edu/2016/faster-parallel-computing-big-data-0913 (which compiles code to run about 4 times faster)

+) And to make use of libraries that are tuned to bits by the platform maker (this is where Apples Numerics team are incredible, as each year, they take swathes of existing CPU OS code and push it out to run in parallel across the GPU)

+) We are going to want power efficient GPUs for today's computer loads,

+) And likely something in the Instruction-Set-Architecture to help acceleration Machine 'Training', sparse data and vectorisation. (Speculation) Especially as the Human-Computer-Interface move away from point and click to intention based semantics.

Coming back to the Job Advert for Apples (graphics language) Metal expertise to help Nvidia work on a project - this might be a longer term Mansfield (4 wheeler) project, or if might mean (if something can be read into it) that Apple is a less than happy at Intels integrated 14nm GPU for Laptop use, or a something destined for a new cylinder ... or just rumour.

AJ

 

[Wayne Morellini]

You may have some good points.

IMO, the issues that Intel (and others) are hitting:
+) Chips become cost innefective to make above a certain size due to less than 100% yield.
+) The area envelope dictates the rate at which heat can be wicked away from the chip.
+) Even if transistor sizes could reduce by a factor of 4, they could not all be switched concurrently without the chip melting.
+) This creates the Dark Silicon problem (i.e. That parts of the chips need to go into a low power mode / not all used at once).
+) Intels use of the AVX (512 bit) extension was an attempt to Do more in one clock cycle, to increase its Instructions-Per-Clock (i.e. Do more with the same power envelope)
+) BUT the maximum speed up (using AVX and/or a boatload of CPUs) is limited by how effectively the code can be parallelised (and the reason why as a relatively low CPU core count, there is almost no gain in adding more CPUs)

Getting CPUs to work on multiple sets of data generally requires More cores, with them all running the same sort of program.
Getting GPUs to work on multiple sets of data is generally more efficient - as that is what they are designed for (but a pain to code for).

With these sort of brick walls being hit - there is a great opportunity to concetrate on the problem rather than turn computers into storage heaters....

AJ

But AJ, that is rather looking at how it is done from before, "is", as in going. I spent decades working on refinements in this area. Refinements, meaning radical shifts of paradigm in large part. Seeking perfect solutions that can handle all cases as a balance.

I don't get Into details, unless some Jonny come lately rediscovers something I had discovered. But the modern reality is more seperate programs are being run at the same time. Not just one program, and of course you have to design programs themselves to be more parallel, one area I was working on. However, GPU's are better designed for this, presently, but you can make data processing arrays more dense. So in my design I identified a mixture of these different processing types produces the best results, with me initially working in the control processor, but I realised these sorts of limitations we are talking about. For instance, a lot of a gpu is geared towards graphics in the consumer end, that can be dumped for other types of data. The issue is that different (sorry my head still hasn't completely recovered from today) mixtures of programs, require different mixtures of processing types. But unless you have very limited, single unction type devices, how do you know which mixture you will need, as it can change depending on what you are running. So, if you have a multiuser computer with large pools of these processing types it is hard to not over implemrnt cores, or find more times of being limited by at least one type. But I realised a way you could make a CPU that could do much of this, so much so that it could be used instead of custom and analogue circuutes. Say, the processor, the chipset, the graphics and gpu, the sound, and anything else, is a lot of parallel and can be replaced by these arrays.

Now as far as running everything hot. The bunch I used to be around had thee lowest energy per cycke cpu technology in the world, a factor of something like 10x less than the competition, and who knows how much less than PC CPU's. True minimalist care bones stuff. Absurdly so. But they were wanting to replace the smallest field programmable gatearray logic (FPGA, as one sort, is often, as you would know, used to as a higher performance option to CPU's). In one reported case they were approached to make a solution to run a mobile sensor, but the solution they came up with used so many times less power than the sensor itself, the company scrapped the plan and used and programmed an bigger arm with the solution at many times the energy usage. However, while they pursued design stratergies on the lowest possible energy envelope, I pursued high performance designs pursyeung the lowest average energy per unit of work. So, while my designs might start out much higher energy they could be x10-x1000+ less energy for complex high performance situations, and a lot easier for non code wizards to program. All my design stratergies basically simplified coding (note, coding is still not simlke, but just simpler).

Now, back to this. They take a low energy process and asynchronously let it run at its own speed. The over clicking for performance actually raises energy usage many times. The speculation is that because they were custom designing on the trace level (simple circyutes replicated in an array, so possible to do) they avoided the design margins for processes, resulting in a 10x advantage again. Design software normally has these so circuits work as predicted. However, they designed their ien design software with different techniques, over time. Another strategy was to use just a ripple adder, that rippled through so fast you could do x bits in a cycle. Another strategy was simple x/y array connections (which I don't like and had other alternatives) where you don't criss link things, but it can work as streams of processing elements on chip that data is passed along, or around. So each processor could even execute a single instruction on the data and it he passed to the next stream, like a pipeline, to process the next bit. The wait system of the processor was extremely low (they measure things in picojoules from memory, I forget if it was lower still, might be now) so this passing constantly was not so much time wasting (the processors are probably easily 6 thousand transistors or less plus very small static memory and ROM as required (is embedded)). A processor can even send an instruction to execute to another oricesdor innthe array, and you can stick child of processors in arrays if chips. Let's say that each processor performs part of a multiplication. The sleep states were rediculously low too.

So you can see a lot of cores can easily be used up, and at a lot lower power, with unused processors and parts of processors dynamically powered (they were also using tristate logic that holds it's value). However, we are looking at performance limitations, but a lot more processors. We see many more processors per x unit of transistors, but essentially not only using the same amount of transistors, but also at lower power per transistor.

So, the industry can do whatever, but I know what they could do. There is opportunity to do much kire, but on the CPU side, RISC-V offers some opportunity for better density. However, it is far from being a fit all solution. However, some mix with other things, or lighter weight cpu data processing oreintsted CPU, might help things. You only need so many administration level CPU's, the rest can be data processing orientated.

To get even more speed you are going to have to rewrite, and do more things. But you might be looking at a 10-100x more processing potential per x unit of energy. That is their design with only the older lite modifications from my designs. As far as I'm concerned, all those other processing conosbies have been, relatively, compared to this, sitting.

 

[Wayne Morellini]

Sorry the writing is not good, rather turned.

 

[Antony Newman]

I briefly followed some of the reaserch into asynchronous CPU designs (that came of DEC).
Even Intel bought some of the IP (of StrongARM) - but found (I believe) that design verification and scalability somewhat tricky, and did not pursue it.

Where I believe the ARM community (including Apple) will benefit because the top brains (Cray & Fijitsu) are bring their skill in designing very high parallelism into the Compiler design - to make use of the Vector hardware that ARM will wave their magic wand on, and that Apple will add to their SoC armoury, and build on TSMC 7nm.

The importance of this is that the Compiler & HW Vectorisation will abstract away much of the complexity of designing and writing parallel code. The initial wand-waving by ARM has brilliantly introduced the idea of Scalable vectorisation.

Intels 512bit AVX greatness will not magically adapt to the future, nor will code that is hardwired for Intels current generation. Conversely the ARM-SVE scales from 128bit - 2048bits - probably good for the next 20 years?

I am not in a position to compare Linux to MacOS - but with Apple investing heavily in rewriting many a low-level API into Metal, and their unique position of vertically interpreting the Hardware - My gut feeling is that macOS / iOS is where I want to 'play'. I also think that Intels may loose is pole position at forefront at the 'leading edge' of process technology.

AJ

 

[Jarek Zabczynski]

I really can't believe it's gone this long without even a hint of an update. It seems like unless there's some major overhaul to the design then it's really the end of Apple for some of us. I mere spec bump after all this time will be embarrassing.

 

[Wayne Morellini]

Close to October dates.

 

[Jarek Zabczynski]

Close to October dates.

Yeah. I think we all have a pretty good idea what's in store for MacBooks and iMacs, the MacPro however, no leaks anywhere.

 

[Wayne Morellini]

I briefly followed some of the reaserch into asynchronous CPU designs (that came of DEC).
Even Intel bought some of the IP (of StrongARM) - but found (I believe) that design verification and scalability somewhat tricky, and did not pursue it.

Where I believe the ARM community (including Apple) will benefit because the top brains (Cray & Fijitsu) are bring their skill in designing very high parallelism into the Compiler design - to make use of the Vector hardware that ARM will wave their magic wand on, and that Apple will add to their SoC armoury, and build on TSMC 7nm.

The importance of this is that the Compiler & HW Vectorisation will abstract away much of the complexity of designing and writing parallel code. The initial wand-waving by ARM has brilliantly introduced the idea of Scalable vectorisation.

Intels 512bit AVX greatness will not magically adapt to the future, nor will code that is hardwired for Intels current generation. Conversely the ARM-SVE scales from 128bit - 2048bits - probably good for the next 20 years?

I am not in a position to compare Linux to MacOS - but with Apple investing heavily in rewriting many a low-level API into Metal, and their unique position of vertically interpreting the Hardware - My gut feeling is that macOS / iOS is where I want to 'play'. I also think that Intels may loose is pole position at forefront at the 'leading edge' of process technology.

AJ

My heads under at the moment. In the late 80:s a research team in the UK, did an asynchronous ARM process I redesign. But as you say thenfeild was an issue. The bunch I mentioned above involves a patent portfolio that includes a vase patentent on asynchronous signaling. Their designs are async on a broad interpretation of the word. But whatever works, sort of thing.

Years back I studied Z notation at university, an eye opener to abstraction capability. By then it was being used in NASA. That Nasa thing again, the other bunch involves somebody that has licensed designs in NASA missions. My VOS was meant to be military grade, and it would be suitable for space usage. Nobody else in the class got it, and I finished well ahead. But only after I got ross river fever, and were seeing flying tea cups and saucers going through the bed room wall the fever was so much. After that z notation seemedba lot easier.

Last decade, I think, I came up with an idea to make an abstracted description of a program that could flexibly be compiled to target processors with high efficiency. Many things I went into to maximise performance of my virtual OS design (the abstracted description wasn't part of this). However, such a description of maths calculations provides long-term flexible viability across hardware types with relatively, hopefully, maximal performance. Sorry, my head is swimming so finding it hard to be to the point.

I'm glad about the metal like initiatives, as that is the way I was designing my VOS in the 80's I think. As I knew about the decrease in performance from abstraction layers, and there were a heap of them, and they introduced much slow down. I designed the API's to be as close driver or lower level as possible. There iprobably is never more than two layers (the GUI for instance), and when it makes sense direct to the hardware is used.

 

[Wayne Morellini]

Yeah. I think we all have a pretty good idea what's in store for MacBooks and iMacs, the MacPro however, no leaks anywhere.

Sorry Jarek, my bad. I thought I was posting to the New Project thread.