To be clear, you don't get all three.
Also, are these Apple's numbers? They are better than what TSMC say (1st gen) 3nm silicon provides:
> N3 technology will offer up to 70% logic density gain, up to 15% speed improvement at the same power and up to 30% power reduction at the same speed as compared with N5 technology
https://www.tsmc.com/english/dedicatedFoundry/technology/log...
'70% logic density gain' sounds like 'reduce area by 35%' to me
The only one that might not line up is 'reduce power consumption by up to 50%' vs 'up to 30% power reduction at the same speed as compared with N5 technology'
...but you have to know what's being compared before deciding the numbers do (or don't) make sense
Typically, sram (cache memories for example) doesn't scale as much as core logic, and interconnect (connections between the cores, DDR, etc...) almost don't scale at all.
This is highly dependent on the design of the SoC, but the core logic is rarely the largest of the three, so you will not see a 35% reduction of the total area of the chip: only of the areas the most densely packed with logic. What you could have for example is a 35% more powerful neural network accelerator in the same area as the previous generation. But you will not have 35% bigger cache.
N3 is a stop-gap as TSMC is behind on their N2 GAA process. It's not so different from Intel's 14nm++++++ where it was dramatically better than before, but still not enough.
No, but improving density still makes it smaller (for an otherwise-"identical" offering) :)
Can you elaborate?
Start with processor pipelining, branch prediction, speculative execution, etc
Then move to multiple CPUs/CPU cores
A practically-linear program (ie hardly any unpredictable branching) can be run ~5x faster on a 5-stage-pipelined CPU than an unpipelined CPU
Liekwise, parallelizable tasks can benefit from multiple CPUs/cores, whereas non-parallelizable tasks will not (much)
And then you have performance-per-watt vs raw hertz count: today, most people seem to care more about performance-per-watt than raw "performance"
Ie, ceteris peribis, a 30w 4 core CPU at 1Ghz is going to be more favorably viewed than a 100w 6 core CPU at 1.8Ghz - you can throw 12 "low power", "slower" cores at the problem for ~10% less power draw than the "high power", "faster" cores
Then you can also look at the relative efficiency of different CPU platforms and/or microcode changes in a single platform: that was the major selling point of Apple's anti-Intel ads 15-20 years ago - the PowerPC was "faster" than the Pentium because it was "more efficient" at several families of tasks (even though the raw clock speed of the PPC was typically lower than the comparable Pentium offerings)
This comes up with the Apple M-series CPUs vs the Intel chips they replaced - they may not be "faster" (in raw ghz), but they're more performant
Hope it's obvious, but no, they are not Apple's numbers—this is a rumor about unreleased products.
Actually you do. The branding is called FinFlex, but the upshot is that you can use different FETs for different parts of a circuit. So some critical timing bottleneck blocks could be built with performance optimized FETs and other blocks can optimize for low power.
The numbers from TSMC for N3E are +18% speed improvement at same power, -34% power reduction at same speed, and 1.7x density improvement.
https://www.tomshardware.com/news/tsmc-outlines-3nm-roadmap
>Also, are these Apple's numbers?
Ha ha. That's funny. Does Apple ever release any numbers prerelease?
You probably also take photos, where Apple automatically applies some Machine Learning tricks.
And wherever Machine Learning is used, more can be used. One day they could put an entire ChatGPT on the iPhone.
That sounds great except I never use siri...(in car commands being the exception).
Where is AMD's competitive chip that came out July 2021?
If you need further evidence of this pattern, look at Nvidia's ridiculous 40-series cards. More expensive than a used car, but they were able to secure TSMC's 4nm node and annihilate everyone else. Apple did the same thing with M1, and it looks like that's what they're gearing up for with M3.
> Battery life was a good few hours shorter than the M1
They do not care about this:
> ...but it was also manufactured on 7nm versus the Apple's 5nm
Power envelopes are reported in very misleading ways by companies, in practice it is not even close. The way they report stuff is having their cake and eat it too: the benchmarks results assume boosting their frequencies above the base one, while the "power envelopes" advertised are on the base frequency. It becomes quite apparent when you run them on battery, where M1/2s continue performing the same as plugged in, and amd/intel laptops underperform, while also not even lasting as much as apple's on battery.
[1] - https://nanoreview.net/en/cpu-compare/apple-m1-pro-vs-amd-ry...
[2] - https://nanoreview.net/en/cpu-compare/apple-m1-vs-amd-ryzen-...
We’ve been reading for decades that ISAs don’t matter that much anymore, and yet everything that needs good battery life is ARM. Intel was the undisputed manufacturing kind for 40 years or so. Things change.
Seems like node size for the price beats everything else which is what we're talking about here.
Apple's anticompetitive practices are not particularly compelling evidence of some inherent architectural superiority.
I'd like to see evidence for that, i.e. that the change from 4nm to 3nm offers significantly larger efficiency improvements than the change from 5nm to 4nm.
You can see it in the smaller performance gains of 4nm A16 chips vs 4nm A15 chips from Apple.
Obviously there's many caveats here based on how each person uses their device. But the broad takeaway is - a 45% reduction in power consumption by Apple's chips doesn't result in a corresponding increase in battery life. We'll only know when the final product is shipped.
I've seen this comment over and over again, everytime an increase in processor efficiency is talked about and yet those gains usually do result in a very noticiable improvement on battery life.
The real life luxury of just being able to toss a 14" macbook pro that weighs almost nothing into your bag and have a savage development machine with up to 96gb of ram, no fan noise and minimal heat, great battery life, is very valuable.
I've started noticing all the processes that really bog my intel mac down. Indexing, running out of ram, builds, etc.. I was pretty pessimistic about macs for a while, but it feels right now like when they started putting retina displays in them. My previous mac couldn't even smoothly play a 1080p YouTube video very well.
Yeah, it struggles with YouTube videos and fans are spinning in vacuum cleaner mode. But it didn't in 2019. I feel OS and software updates ruined it. Not what I expect after only about 3 years of use. (obviously it wasn't cheap either)
Oh well, still gave Apple my money, just hope it's a special situation with the chipset transition and not the regular lifespan from now on.
Not saying you're doing that or that they are otherwise great machines (they're not) but they can go from being a steak grill back to being a relatively serviceable computer just by switching the charging port.
Pretty sure you have it backwards, it's charging from the _left_ that causes more throttling.
In terms of latency it's usually slower by an order of magnitude.
There should be a law that mandates developers to use at least two generations older hardware than the average consumer.
What we get is a result of nobody on the entire stack giving a shit. It's not a technological limitation.
With a tiny bit of attention to performance you can do insane things
About text editors... you can use blazing fast editors if you want like cli-base ones, notepad++ or sublimetext... If devs are not using those to code anymore there may be reasons, right?
That's a bit of an exaggeration. What stack's hello world takes 10 minutes to build?
Since the discussion is around CPU hardware improvements, I don't think network speeds are too relevant.
You’re doing something extremely wrong if this is the case.
Or more likely, the people complaining about “10 minute” web app compile times are just repeating hyperbole they found in other cynical comments.
We can all agree software is not as resource efficient as it used to be on the whole.
Beyond that we’d have to discuss specific examples and benchmarks.
I could be wrong. I often am. But I suspect that Electron consumes far more resources in the minds of HN users than it does in most computers.
However the differences are real and have been measured. [1] [2] You are welcome to argue that the performance work isn't worth prioritizing, but don't fall into the trap of claiming the performance gap doesn't exist.
--
Eclipse ran better on my $600 laptop in 2012 than pycharm runs on my 6 core 2019 macbook. Also, on my macbook, high cpu activity causes constant pops in my audio, which is just a thing that happens with macbooks that people just ignore apparently.
It is apparently an iron law of the Universe that all available computer pier must be wasted.
Typing in Sublime Text is always fast. Except for the first line which is the title of the tab. After that, it is fast.
I often switch to ST to type, then copy and paste to the slow app.
It's kinda nuts.
Because it sure seems like this exact comment is a tinnitus-like constant ringing noise amongst the tech community.
I'm already in the minority because I do all my work in Sublime Text so I might be completely wrong about all this, but this is how I suspect it will play out.
But I only use python and no demanding software like docker.
Sublime Text was always faster than all of these (and still is) but that’s not why people are picking text editors.
Tauri is great for certain use cases but it’s not even close to a replacement for Electron at this point (having used both).
Optimizing for speed above all else is the kind of thing that appeals to a subset of programmers, but most people just don’t care about at all as long as it’s fast enough. Products like VSCode are more than fast enough for all but a few people who like to count milliseconds.
Personally, I think VSCode has massive adoption because it's free and it's easiest to configure which both appeal to newcomers. The other camp that like VSCode are the nomads who like to work in the cloud. The senior devs I've met generally prefer either Jetbrains or Sublime, depending on if they like a maximal or minimal setup. And then there's the hardcore camp who can get on with Vim and Emacs. I don't know how the latter do it personally, I've tried multiple times to get something similar in functionality to Sublime/VSCode with them and it is always a monumentally frustrating fuck about.
> Tauri is great for certain use cases but it’s not even close to a replacement for Electron at this point (having used both).
I agree but it will definitely be ready within 5 years.
> Optimizing for speed above all else is the kind of thing that appeals to a subset of programmers, but most people just don’t care about at all as long as it’s fast enough. Products like VSCode are more than fast enough for all but a few people who like to count milliseconds.
I do agree with this to an extent but another reason I'm a big Sublime Text fan is the interface. I really appreciate the lack of screen clutter compared to VSCode and especially compared to Jetbrains.
People care about speed. Even non-technical people. Every non-technical person I know that has bought a new computer even though they already had one was because of performance. People care about performance so much that they are replacing their whole device! That costs a significant amount of money and comes with a real hassle of transferring their data.
I think people use VSCode over Sublime because of its features, not because they don't care about the speed. It's certainly what got me to migrate from Sublime to VSCode. Sublime is so much faster, but it just doesn't do the things that I want my editor to do. I would instantly switch away from VSCode to a faster alternative if it actually had the subset of VSCode features I care about.
In VSCode the search gets refined as I type, the results are in a sidepanel and clicking on a result will change the main editor's view to that location in that file.
In Sublime I have to first define which files are even subject to the search. There are options to add folders or to search all currently open files, however a bizarre omission of searching all the files in the currently open project, which is what I almost always want and how VSCode works by default.
Then I have to type out the search term, which is sometimes needlessly precise - because in VSCode thanks to the incremental search I sometimes already see that there are no results or just a few results when I've typed in only a small prefix of what I was going to.
Once the search is done, in Sublime the results are opened as a pseudo-file in a new tab and clicking on a result switches away to a different file tab. It works, sure, but it's very inconvenient for cases where I want to quickly click through a bunch of resulting files to see which is the one I actually wanted. Lots of switching back-and-forth between file tabs, as opposed to VSCode where it's all done in a single view context with the results always visible in the sidepanel. This is especially annoying in Sublime when a search result is in a file that I already have open but is very far from the search result pseudo-file tab. This means that to get back to the search results I can't even just switch the file tab, I need to first scroll through the open files tabs to even find the pseudo-file.
So in short, I guess I would describe Sublime's search as a sort of middle point between using grep and VSCode. It's serviceable, but annoying and wastes my time.
Sublime 100% does this because I use it everyday. You just have to use command + shift + f, type whatever you want and hit enter and it will search all files in the open project by default. Only time it won't do this is if there's something in the "where" input from a previous search.
I find the VSCode search results packed in like sardines and like the greater amount of context you with Sublime tab which generally means I get to find what I'm looking for without having to click through to check. I've got a keyboard shortcut set to jump between the entries which makes it feel a bit snappier to cycle through results as well. All personal preference at the end of the day though.
I will admit there doesn't seem to be as much in it as I thought there was.
The instances in which Tauri is faster are when you write your business logic in Rust and your frontend logic in JS.
Simply switching to Tauri will not instantly speed up your app.
> Then after most devs switched to using M3 Macs, app performance will regress back to the baseline, making everything slow on M1/M2 machines, and basically unusable on Intel Macs
which I felt can't be true because my laptop is ancient by modern standards but still usable. Not as snappy as I would like it to be, but also not terrible or unusable.
I’m starting to see less software support, though. I should put Linux on it.
This is one of those HN comments that has me feeling like I live in a different world than the commenter. What Electron apps are you using that are really that slow? I use several of the popular Electron and CEF apps on a daily basis and everything is fast.
The exceptions are anything that loads over a network. Spotify, Slack, and others can feel “slow” when the content is loading from a backend over the internet, but obviously that’s not the fault of the UI
Or tried to help students use an electron IDE on a computer with 8Gb and a 2 ghz 10 year old processor that their dad saved to buy secondhand to help his kid not need to work overtime at the factory to keep food on the table?
Electon is only fast on developer and gamer tier hardware.
Try running this stuff on the hardware steam says is the average gamer and see how fast it actually feels.
Is the codebase getting de-optimized with time? Is it badly architectures extensions? Is the JS runtime becoming slower?
People definitely don't optimise their Electron apps as well as they could for time reasons, normally not too bad if you're running 1 Electron app, but if you're running several then it becomes more obvious.
Tbh it's a old/new software design principle I guess. We all hear the stories of some 386 machine in the basement running some fortran program that hasn't been touched in years; whereas modern JS-based codebases are expected to be constantly updated. I've worked in JS my whole career & it's very rare to see a project that's one & done like software used to be.
Maybe old software did get updated, but in long release cycles, version 1, 1.1 etc. Now JS-based software is updated (sometimes) every day!
What kind of real-world impact are we likely to see on the 3nm chips for the new iPhone and M3 macs? These figures seem outstanding and generationally impactful if true.