Also, the codec being decoded matters a lot. H.264 is trivial to decode at this point while something like AV1 will require a bit more power to decode.
The Acer Swift Go 14 has a battery with 53 WHrs and for e.g. the Asus Zenbook S 14 has a 72 WHrs battery. Would this mean the Ryzen Laptop could have lasted ~1.35 times longer than it currently did i.e. 21:15 hours instead of 15:40?
So far I have a Surface Laptop 7 with the Snapdragon which has blown me away in terms of battery life. I'm talking 10+ hours watching video on full brightness.
And I'll happily sacrifice 50% of that for a better screen and a more powerful GPU.
The worst part today Windows 11 ARM is that on WSL `brew` is not supported.
Loading up powertop on my i7 6600u reports an idle draw of 5.5w with my browser open playing music. I think that's pretty damn good, for an old-ish laptop with mitigations enabled on Linux.
That assumes the motherboard vendor implemented ACPI properly, and most don't, you're often lucky to have something that is able to keep Windows alive enough to pass certifications. Linux, xBSD or macOS compatibility? Forget it unless you're talking servers with support contracts making it actually worth the effort for manufacturers.
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.
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.
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;
typedef char* (*(*NumberToStringFunction)(int))(void);
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.
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.
Yet GP's point still holds.
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.
Language syntax does affect the speed of the parser
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
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? ;)
>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.
------
[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...
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-...
FWIW the alternative these days is probably running a 32-bit RTOS on your battery hardware which isn't much simpler.
Bottom line, linux on laptops only really works because of ACPI, if you were wondering what the laptop space looks like without it, I might suggest grabbing a couple random arm laptops/chromebooks and giving them a spin.
Right now I am listening to music on this computer while I work on another computer. When the screen turns off on this computer the headphones get switched to headset (telecommunications) mode and the music quality goes down... On a desktop computer where saving power is not a big issue and I certainly don't want worse audio just because the screen powered off.
It's been a long term issue that USB devices will not work properly if USB power management is enabled and that's scary when some of those devices are mass storage devices that could corrupt data.
As a single vendor, I trust Apple better to get things like this right, but I don't particularly like MacOS.
I think you'd have a pretty hard time finding an x86 system that couldnt run Linux these days. If you gave me a random x86 machine from the past decade, I'd actually feel more confident installing Linux than Windows.
They go over it in detail here: https://www.notebookcheck.net/Our-Test-Criteria.15394.0.html
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.
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.
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?
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.
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.)
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.
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?
>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 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.
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.
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!