[Tom's Hardware] Apple Considering Moving Macs Away From Intel Chips - Page 14

assembly is between binary and c, programming in binary is going direct to the hardware level, Assembly is as close as you can get and still have reasonable inteligibility.Also, with todays c/c++/c++99 and other language and modern compilers. The performance benefits of coding in assembler are largely gone. The only real savings might "might" be space in certain circumstances. Like thats a issue these days for code, its not.

I have somewhat of a random thought here...
Yes ARM is good for cutting cost and power consumption but in the end if Apple did use that(which i can only see them using it in the MBA) they would have a hard time with all the current software they use seeing as its x86(then again there could be like a custom x86 arm chip sometime maybe?)

Another thing..If they did go with AMD as thier CPU's i wouldnt think for a second that they would use the FX line but more of the APU line, my reasons are to believe that they might be looking into HSA and other various stuff they can do with that along with getting more software on thier systems to make thier brand a bit more.how should i say...WORTH forking out 1k for.

And yeah..prices would drop with either solutions and Apple would have something thats not just brute force to mess with.

Loongson mips cpu's are not this good, though MIPS used to stomp a mudhole in x86 performance, way back in the day. It likely still could. One of the interesting benefits of MIPS, is that it would fit far better with hsa, then x86

edit: I'll help your google a little. How's spectrum.IEEE.org?
How about the official isscc PDF whitepaper?

I hope these are credible.

Google Loongson. It's amazing how fast an architecture can advance when patent don't need to be worked around and bad ISAs don't need to be fixed while maintaining compatibility with chips designed 25 years ago.

True RISC architectures have always had a huge advantage over x86 (realworldtech article on risc vs cisc still matters.

my source for Linpack numbers came from here(bright side of news)
You miss the point. Intel has a huge fab advantage and even if the numbers you give are true, Same performance, same power usage an 3 nodes (and billions of transistors) advantage doesn't favor Intel in any way.

As to Loongson being good at vector floats, AVX is nothing more than a vector SIMD ie. It's Intel's attempt to compete in this same market, so a comparison is fair (and what makes for good fluid simulations also makes for good performance in other areas). Since bypassing x86 to get at Intel's RISC insides is currently impossible (whereas Loongson can run in either mode), the point is a useless gesture (though it would be great as I've discussed elsewhere in the past).
Edited by hajile - 10/6/12 at 10:31pm

And my two year old, 17w, Mobility Radon 5650 destroys both parts in GFLOPS.

FLOPS is a largely useless metric. It says little about real world, and nothing about integer, performance. If FLOPS was all that mattered we'd all be better off running everything on Radeon 5850s that on nearly any CPU.

The handful of real-world benchmarks I've seen don't show a Loongson 3A quad coming anywhere near the performance of a 3770k.

This article is over 12 years old...the Pentium III was fairly new, AMD and Intel had just hit 1GHz, and x86-64 was a distant blip on the horizon.

A lot has changed since then; x86 has been expanded and the fraction of transistors used to maintain x86 compatibility has shrunk by orders of magnitude.

RISC vs. CISC doesn't really matter any more. It may have been debatable a decade ago, but not now.

The future is AMD's APU's

As I said, comparing two completely different instruction sets are irrelevant especially where one has a massive overhead(x86)...I've said this time and time again: Not all FLOPS are created equal.

I'll wager that any modern x86 CPU will get much closer to its theoretical performance sustained.

This also doesn't account for the on-board graphics in modern Intel chips which are themselves massive floating point calculators.

I believe I read somewhere that future iterations will take over FP duties entirely, instead of having specialized hardware.
Edited by BizzareRide - 10/7/12 at 2:33am

It's not too high for Intel, they added the uop cache in order to help with that and pipeline length, I think the majority of instructions can be cached in the uop cache so it's only the rarer ones that have the full decoding time, others have a much reduced one.

Just because you don't know about MIPS, doesn't mean it's unknown. MIPS powered the PS1 and PSP among other things and x86 is hardly the fastest or most efficient of architectures...Hence why AMD and Intel both moved to having an entirely different architecture internally with decoders to still "talk" x86, SSE, SSE2, etc all help as well.

It's not as high as it was, but there's still significant performance gains from bypassing programming languages, but I'd imagine it'd be horribly confusing and difficult to get those improvements on the average modern application too, simply due to the size.

I'd hazard a guess ARM, PPC and MIPS would be taking x86 down if they were more popular/had someone with x86s level of R&D funding.

It all comes down to R&D and use, most people run x86 and x86 has Intel pouring a metric tonne of R&D money into it, hence why it'd have faster performance..Think of it like theoretical performance vs real world performance, x86 might have lower theoretical performance than MIPS, but it's real world performance is still higher because it's say, using 90% of its theoretical performance while MIPS is still at 50% or 75%. (Not real numbers)

No chance

Your GPU is hard to exploit correctly. Loongson uses a float architecture that shares a lot in common with 512-AVX without the x86 overhead (and that overhead goes much farther than raw performance finding a place to stuff a few dozen instructions is also performance draining and increases the size of the decode). Loongson uses a revolutionary bus/mesh core interconnect which improves both power usage and performance making it even easier to hit those theoretical values. In addition, being a RISC chip means that there's fewer parts upstream to cause varied performance. Real cache access also plays a part (for compatibility reasons, x86 can't know that cache exists and this causes a performance hit and needless added complexity in the design

An interesting architecture (and the first potentially significant one since Alpha and EPIC (aka Uranium) were designed in the 1990's) is harmony, a new Chinese architecture (the project leaders are a former principle engineer at Nvidia and a former chief scientist at SGI who was also principle engineer at MIPS). I'm sceptical, but look forward to the results.

Even with the article being old, almost all of the points apply today (even in 2000, Intel claimed that RISC vs. CISC didn't matter, but just like when that article was written, CISC vs RISC still matters). Though chip size has increased, the fundamental problems can't change without hitting the reset button. Old X86 compatibility still comes out everywhere. For example, 8 registers was great 30 years ago since die size was so constrained, but now, it is a performance liability. AMD claimed when hammer was released that 64-bit extensions alone increased performance by 20% simply because fewer cycles were wasted transferring between the stack and registers (x86_64 has 16 registers. They would probably have added more, but they didn't have a good place to tack them on). The problem Is so bad that according to AMD, switching to 64-bit code only increases average size by 5%. While most current x86 processors are 64-bit (with the exception of Atom), lots of code still executes in 32-bit compatibility mode and suffers from this problem.
Edited by hajile - 10/7/12 at 5:45am