Hacker News Reader

Comment by tester756 | Hacker News Reader

Where are all those people who for years (or since M1) were claiming that x86 is dead because ARM ISA (magically) offers significantly better energy-efficiency than x86 ISA.

Of course they ignored things like node advantage, but who cares? ;)

Meanwhile industry veterans were claiming something different and turns out they were right

https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...

Asking which - x86 or ARM is faster/more energy eff is like asking which syntax (letters) is faster - syntax of Rust, Java or C++?

And same as with CPUs - everything is up to the implementation - compiler, runtime/vm, libraries, etc.

View on HN

I'm curious how this new chip actually compares in power consumption to the apple cpus. Certainly at the time, when I went from an x86 macbook to an M1, the ability to really work all day on fairly compute intensive stuff, e.g. on an airplane or park bench with no AC was revolutionary.

x86 is certainly not dead, and I don't think it will anytime soon, but they are still behind Apple M3 in terms of performance per watt. And M4 is about to arrive. I'm a bit disappointed because I really want more competition for Apple, but they're just not there yet, nor x86 nor Qualcomm.

Apple will also run into the diminishing returns, but they will retain the real killer advantage over general purpose CPU vendors that the have in other hardware areas: being able to retire or rework old or misconceived parts of the architecture entirely in future versions unilaterally. If they want to drop M1 support in some future MacOS version, all it will take will be a WWDC announcement that the next version won't simply work on that generation it earlier of machines.

Yeah, that all makes senses. But having legacy software that you support has been a big advantage for x86 for, basically, forever. For a lot of purposes, that is way more important than performance per watt.

> x86 is certainly not dead, and I don't think it will anytime soon, but they are still behind Apple M3 in terms of performance per watt.

Do you have a source for this? I havent seen a good review of Lunar Lake yet. The article this HN story links to is pretty bad.

I think they're running out of optimizations (hacks). They moved memory on package and bought the latest TSMC node. I guess they could keep buying the latest node but I don't expect any more large leaps.

> is like asking which syntax (letters) is faster - syntax of Rust, Java or C++?

This is actually a bad example because C style decls are provably, objectively, bad. They make parsing harder and once the types are non-trivial, they are absurdly hard to read and write. The case in point being non-trivial function pointers in C. The syntax for declaring a function pointer of a type that returns a function pointer is hidious.

Meanwhile here is how you define a function in that returns a function that returns a string in a modern language (Typescript):

    type NumberToStringFunction = (num: number) => () => string;

Compare that to C

    typedef char* (*(*NumberToStringFunction)(int))(void);

> And same as with CPUs - everything is up to the implementation

It is very easy to add CPU features that place a hard limit on performance. That is why Arm64 dropped all the conditional stuff! (Any instruction that limits the potential branch prediction is going to severely impact potential CPU performance.) History is littered with failed CPU architectures that just couldn't scale up, Intel's famous folly being Itanium.

That said, x86 is mature and it dropped some of its less pleasant aspects with x64.

Also IMHO drivers matter more for laptops than the CPU does. A bad driver keeping the GPU on w/o need or just not being able to enter the lower sleep states in general, will kill battery faster than anything else.

>This is actually a bad example because C style decls are provably, objectively, bad. They make parsing harder and once the types are non-trivial, they are absurdly hard to read and write. The case in point being non-trivial function pointers in C. The syntax for declaring a function pointer of a type that returns a function pointer is hidious.

The example is good, I just dont understand why you focused on compiler performance or developer experience. It doesnt imply program's performance.

We were talking purely about performance/energy eff of generated binary, not other RELEVANT things like developer experience/low compilation times because it is outside the scope of this discussion.

Yes, C++ is poorly designed language, but point that syntax (letters) don't imply language's performance stands. The result is up to the implementation: compiler, runtime/vm, std libs, etc.

ah I didn't understand that your "syntax (faster)" referred to the compiler speed, I thought you were referring to the speed of development/engineering!

Actually I meant speed of generated program/binary :P

The funny part of your example is, decoding AArch64 instructions (argubly, "parsing") is also easier than decoding x86_64.

Yet GP's point still holds.

> This is actually a bad example because C style decls are provably, objectively, bad.

I found your comment extremely funny. You singled out the language which is not only one of the most popular languages ever designed but also the one whose syntax inspired or was straight out cloned by the bulk of the world's most popular programming languages.

Yes, the programming language defined in the 70s isn't perfect and has a couple of kinks that could be improved. As does every single programming language.

But when you see a curly-bracket language you see programming language designers yelling to the world that C got way more things right than any other language not derived from C, which is the exact opposite of your unbelievable claim.

> Yes, the programming language defined in the 70s isn't perfect and has a couple of kinks that could be improved. As does every single programming language.

Back in the 70s, they didn't know as much about writing parsers as we do now. The field was much younger.

There is a reason that Go's declaration syntax is not based on C's, despite Go being created by one of the co-creators of C.

> which is the exact opposite of your unbelievable claim.

I'm not making claims, I'm stating facts. Parsing C declarations is difficult. Writing C declarations is difficult. Reading non-trivial C declarations is difficult. For examples of this in action read https://en.wikipedia.org/wiki/Most_vexing_parse.

C++'s horrific syntaxial complexity is the ultimate end of C-style decls. C++'s syntax is, again, objectively overly complicated for what it does. The reason it is overly complicated it because of the syntax it inherited from C.

C got some things right, mostly around ease of porting to different architectures. However, 50 years later we know a lot more about how to design programming languages.

C is not perfect, and even when it was created, better designed programming languages existed. However C was cheap and good enough, and because it was easy to port, it spread to lots of platforms.

FWIW I started my career in C/C++ compilers, I have first hand experience with these topics. I love C as a language, but I also acknowledge it is not perfect. The machines it was designed to run on in the 70s were not the height of Computer Engineering and C is not the height of programming language design.

Millions of flies can’t be wrong.

Or, more politely, a primer on how to confuse first-mover advantage with being any good.

C is abysmal by today’s standards, it being the first popular language for weak computers is literally what’s keeping it popular. Popularity is very valuable but please don’t confuse it with being good.

> Millions of flies can’t be wrong.

You're talking about experts in programming language design. They decided that C's syntax was the best for their needs.

Then the whole software development world adopted these languages, based in no small part due to their readability and user-friendlyness.

If you think the whole world is wrong and you are the only one who is right then sure why not?

If I was the only one, you wouldn't have all the other languages around, a lot of which have nothing in common with C.

C is good enough for some tasks. It doesn't mean it's good. I don't see many of those programming language experts saying that C is good. I see many people who don't think they need anything more than C in their work.

> your unbelievable claim

Please quote the specific claim you think is unbelievable.

(I assume you don't mean the declarations claim because you didn't even disagree with it.)

I'm presuming the poster either never took a compilers course, never had to write a parser, slept through their entire CS curriculum, or doesn't have a background in CS. (Which to be clear, doesn't have to involve a degree! The people who invented Computer Science sure as heck didn't have CS degrees!)

People forget that Computer Scientists has actual foundations built upon objective, scientifically backed, work in multiple disciplines, including mathematics, linguistics, and philosophy.

We use those foundations to build the tools that we then use to engineer software. It is one of the few fields where practitioners are expected to know both the foundational theories underpinning the tools they build, as well as then use those tools to create absurdly complex projects.

Sadly some people skip over the theory part.

I don't think a lot of theory went into most of C's syntax. History is important but it doesn't make designs good.

And if we really want to get into how much C was copied, that's more because of familiarity than correctness. Look how many languages copied C's goofy precedence for bitwise operations, which was only there because they made a syntax change and didn't want to disrupt a few existing programs.

But all this aside, you didn't answer the question at all. What was their unbelievable claim?

> I don't think a lot of theory went into most of C's syntax. History is important but it doesn't make designs good.

Agreed. C is just what sort of worked at the time. 50 years on, we can do better. Theory is what lets us do so in a scientific way, instead of just throwing stuff at the wall and seeing what works.

Although, there is something to be said for testing out new syntax and seeing how it feels in the real world!

It annoys me too, especially when the explanation is: “because RISC simpler so it is faster, duh”. However x64 is at disadvantage for instruction decoding (it’s difficult to decode multiple variable length instructions in parallel), and secondly the guarantees for memory coherence across cores. Both come with an extra burden intel can’t eliminate for backward compatibility.

And this disadvantage quantified translates to… 0.1% area, performance, perf/watt, something else?

I am going to observe that competition is good for consumers. However, using video playback for battery life / efficiency is sketchy as all modern chips have specialized hardware for video decoding. Interestingly Apple also uses video playback as a proxy for battery life... probably for the same make number go bigger reason.

"is like asking which syntax (letters) is faster - syntax of Rust, Java or C++"

Language syntax does affect the speed of the parser

Correct, but I meant the performance of generated program.

I got that, but it's not a good analogy. It's the parser that is to the language what the CPU is to the instruction set

I see your point, but isn't decoder part of implementation for ISA just like compiler, runtime/vm, stdlib and more... are for programming language?

Yeah, I guess neither of them is a great analogy

> (or since M1)

The bigger deal about the M-series performance and efficiency is SoC, not the ISA. This is something that could take off in the x86 world though it stifles upgradeability

This is a laptop chip, though. Upgradeability seems to be not a thing anymore at this point anyway (besides maybe an m2 slot or two). I don't think Lunar Lake even supports non-soldered memory even if the laptop manufacturer wanted to use DIMMs.

I agree. It's getting more and more pointless to avoid SoC. No need to do expensive bus transports when you can just stay on-die. The only upgradeability that's needed is to swap out entire SoCs.

Actually, Apple's M3 and even Qualcomm's X Elite are significantly ahead of the new Intel chip in raw performance and especially perf/watt.

Cinebench R24 ST[0]:

* M3: 12.7 points/watt, 141 score

* X Elite: 9.3 points/watt, 123 score

* Intel Ultra 7 258V (new): 5.36 points/watt, 120 score

* AMD HX 370: 3.74 points/watt, 116 score

* AMD 8845HS: 3.1 points/watt, 102 score

* Intel 155H: 3.1 points/watt, 102 score

Cinebench R24 MT[0]:

* M3: 28.3 points/watt, 598 score

* X Elite: 22.6 points/watt, 1033 score

* AMD HX 370: 19.7 points/watt, 1213 score

* Intel Ultra 7 258V (new): 17.7 points/watt, 602 score

* AMD 8845HS: 14.8 points/watt, 912 score

* Intel 155H: 14.5 points/watt, 752 score

PCMark did a battery life comparison using identical Dell XPS 13s[1]:

* X Elite: 1,168 minutes, performance of 204,333 in Procyon Office

* Intel Ultra 7 256V (new): 1,253 minutes, performance of 123,000 in Procyon Office

* Meteor Lake 155H: 956 minutes, performance of 129,000 in Procyon Office

Basically, Intel's new chip has 7% more battery life than X Elite but the X Elite is 66% faster while on battery. In other words, Intel's new chip throttles heavily to get that battery life.

  >Of course they ignored things like node advantage, but who cares? ;)

Intel's new chip is using TSMC's N3B in the compute tile, same as M3 and better than X Elite's N4P.

  >Where are all those people who for years (or since M1) were claiming that x86 is dead because ARM ISA (magically) offers significantly better energy-efficiency than x86 ISA.

I'm still here.

------

[0]Data for M3, X Elite, AMD, Meteor Lake taken from the best scores available here: https://www.notebookcheck.net/AMD-Zen-5-Strix-Point-CPU-anal...

[0]Data for Core Ultra 7 taken from here: https://www.notebookcheck.net/Asus-Zenbook-S-14-UX5406-lapto...

[1]https://youtu.be/QB1u4mjpBQI?si=0Wyf-sohY9ZytQYK&t=2648

The efficiency tests are garbage. Notebookcheck are comparing whole system power draw and equating it with SOC power draw, when in reality the SOC may draw a fraction of total system power, especially under single core workloads. Take those numbers with a full truck of salt.

They take full power and subtract idle power.

How does that Qualcom X Elite compares with LL when it comes to gaming/iGPU?

How many FPS in e.g Black Myth: Wukong on battery like this guy: https://www.youtube.com/watch?v=gZ1xXh2lj2A

or Cyberpunk as benched here?

https://www.pcworld.com/article/2463714/tested-intels-lunar-...

Cinebench is really a terrible benchmark and not indicative of real-world numbers for performance or efficiency (particularly not for any of my use cases). I'll wait for better reviews and benchmarks before deciding who's "won".

Geekbench shows the same gap in performance. Cinebench has historically favored Intel chips more than Arm.

Geekbench is also terrible though? I'm not an Intel fanboy that's upset about Intel not winning, I've owned AMD chips for most of my life. These are just terrible benchmarks that don't tell us anything. I'm more interested in seeing what Phoronix or gaming benchmarks (particularly Factorio and MSFS) have to show. Real-world benchmarks are infinitely more useful to guaging the real-world benefit of buying one or the other hardware.

AMD fanboys will back Intel if it’s against ARM.

Am I interpreting this correctly- the M3 still uses only roughly half the power of this new Intel cpu discussed here?

It doesn't necessarily use half the power. But it does have greater than 2x in perf/watt and it has noticeably faster ST performance.

Aren't those roughly equivalent in a cpu which dynamically varies its clock speed and power consumption in response to compute demand?

Performance vs power across a CPUs operating range is not a linear relationship. Which is why a naive perf/Watt metric like Notebookcheck does at each chip's top operating point is almost worthless for comparing efficiency. You need to at the very least normalize to either the same power or same performance, but preferably reviewers should be measuring and reporting a full perf/power curve for each chip instead of just one data point. Geekerwan seems to be the only reviewer that understands this, and they mostly focus on phones.

  >Which is why a naive perf/Watt metric like Notebookcheck does at each chip's top operating point is almost worthless for comparing efficiency.

It isn't worthless. It clearly gives a good enough picture on efficiency to draw conclusions. It's not like Apple and Qualcomm drastically slow their chips down in order to get better perf/watt. No. They have better raw performance than Intel's chips regardless of perf/watt.

You can't even get perf/watt curves on Apple's A series and M series of chips because it's impossible to manually control the wattage given to the SoC. On PCs, you can do that. But not on iPhones and Macs. Therefore, Geekerwan's curves are not real curves for Apple chips - just projections.

> It isn't worthless. It clearly gives a good enough picture on efficiency to draw conclusions.

They routinely draw wrong conclusions when comparing parts that are close, such as comparing between generations of Apple's chips when the maximum power has increased.

I think Notebookcheck uses peak power in their perf/watt measurements.

They go over it in detail here: https://www.notebookcheck.net/Our-Test-Criteria.15394.0.html

nope, IIRC power scales with the square of clock speed

It's early. Im sure they'll be here moving goalposts and cherry picking some new stat that's suddenly a deal breaker.

Reply on news.ycombinator.com