Apple's 'Macroscalar' Trademark Application Sparks Speculation on Processor Architecture Advances

Apple don't design CPU's, they design SoC's

ipod socks?

Sounds like a prelude to some very, very big things - another shift. This is pretty exciting.

Wow. Just wow.

How excited do you get when something of substance is the thread topic?

This excited over an adjective?

ANOTHER processor change? If I have to go through this all over again a forth time I will stop programming and become a barista! :confused:

If you, as a programmer, still give two craps what chip your code is running on -- well, you suck. That would also explain why barista is an acceptable move, salary wise.

Abstract, brother, abstract. Use blocks, adapter objects, build lightweight APIs around your process intensive work and use the core APIs wherever possible -- and advances in chips becomes basically free. Stop ice skating uphill.

Can someone with a better understanding on the topic break this down into laymans terms?

for some reason it took me 2 min. to read that headline.:)

It makes sense that Apple will eventually move away from Intel chipsets to their own. The benefits are in abundance;

- Apple nets more profit with each sale, since they won't have to hand Intel various licensing fees. Everyone in the pro community knows just how much the workstation class CPU's have gone up in price, and that has only inflated the Mac Pro's now ridiculous value. It only seems like 3-years ago that the Mac Pro was around £500 cheaper.

- They can control the release schedules and progress of their own technologies, rather than waiting on Intel to release their products.

- Their chipsets will work independently, and they won't have to compromise performance/features as has occurred between the Intel and Nvidia with their own disputes.

- It adds more control to Apple's products, and they market the chips to their hearts content with fancy names.

- Lastly of course, it means they can introduce new technologies now found in Intel chips or those from other rivals.

It all sounds good, but I can't imagine it'll happen for a while.

That doesn't sound good, nor is that likely to be what this is. The biggest problem from switching away from Intel would be the MASSIVE incompatibility problem that would occur.

No iOS users.

ooh a good bit of news... for mac pro users

Mac Pros will stay i86 for a very long time and I really doubt that Intel would have licensed the IP to Apple to build an enhanced i86 processor.

I'm strongly leaning towards this being either ARM enhancement or is being rolled into a custom GPU. Either approach could offer Apple a significant performance advantage.

It is actually very interesting to read some of Apple CPU patents that have been filed over the years. In some cases it looks like they are trying to design or enhance a processor for the execution of Objective C code. I'm just wondering if this tech will debut in the A6 processor.

ANOTHER processor change? If I have to go through this all over again a forth time I will stop programming and become a barista! :confused:

This sounds more like compile-time optimization. Unless they introduce some new API's to help with loop optimization, odds are you won't even notice, as it will be implemented as the compiler translates into some shiny new operands in the object code, not in the Objective C itself.

I studied micro architecture in college and did some work with instruction-level parallelism; I find this very interesting indeed.

Are you sure they don't mean, "Mac Pro Scalar" ?

...oh well! ;)

Microarchitectural enhancements...

This doesn't sound like a new idea at all, nor does it sound very important since modern chips do branch prediction to keep the pipelines full and do it well.

Consider, for example, the trace cache, which does the same thing but based on dynamic execution of the program, and so requires no compiler support.

http://en.wikipedia.org/wiki/NetBurst_(microarchitecture)#Execution_Trace_Cache (http://en.wikipedia.org/wiki/NetBurst_(microarchitecture)#Execution_Trace_Cache)

You're actually confusing a couple of things here. First of all, the end of a loop is typically not predicted by branch prediction (or even a branch target buffer), but by a special hardware loop counter. (Although I've never seen a loop counter implemented in conjunction with a trace cache, and I don't think x86 supports loop counters.) Secondly, the one situation not handled by any of the methods you've mentioned is the end of a loop, which is precisely what this patent deals with. Neither branch predictors, branch target buffers nor trace caches do well with the loop ending - they all end up with an empty pipeline to fill, because they all (rightfully) predict the loop will continue. Granted, you could craft a loop to work with a very specific branch predictor, but that's going beyond the boundaries of safely targeted code.

The flipside of this statement is there's a REASON everyone focuses on getting the loop part right - almost all an application's execution time is inside the loop, and it only exits once, so there's not a lot of motive to try to solve that problem.

Regarding the other posts, I seriously doubt this would be relevant to any other architecture than ARM, and it's probably mostly a microarchitectural enhancement, meaning the ISA wouldn't change, or would change ever so slightly in a way that wouldn't break correctness.

But I just wanted to add - it sounds like their design is much larger scope than the way we're describing it - and it would have to be to justify such a name. Sound more like a form of software pipelining in hardware, where you trace through the dependent code chains across loop bodies as fast as possible while letting the independent parts complete in parallel. This could cause a major paradigm shift for high level parallelism because no longer would a loop body have to be truly parallel to be parallelized. Just about any loop could take advantage of multiple cores.