26 ms·
It does not just feel faster, in many cases it is faster. E.g. compiling Rust code is so much faster that it is not even funny. cargo install -f ripgrep takes
by kryps 5y ago
It does not just feel faster, in many cases it is faster.
E.g. compiling Rust code is so much faster that it is not even funny. cargo install -f ripgrep takes 22 seconds on a Mac Book Air with M1, same on a hexacore 2020 Dell XPS 17 with 64GB RAM takes 34 seconds.
- Nullabillity 5y agoHard to compare without mentioning the actual CPU in it. FWIW my Ryzen 3900X completes that compile in 15s. To be fair, that is a relatively high-end desktop CPU, but it's also a massive margin for a last-gen model.
- throwaway5752 5y agoWe also have to consider the i7 and M1 run at about 1/7 the TDP of the Ryzen. Just underscores the good design behind the QoS and judicious use of the Performance cores vs Efficiency cores.
- cbsmith 5y agoYeah, but that's previous generation. Get a 5850U or even a 5980HX...
- sundvor 5y agoMy water-cooled 3900XT is locked to 4.4ghz all cores with relatively fast double banked 2x16GB c15 3600mhz memory. (It never drops under 4.4 on any of the 12/24 cores.) Also has a Samsung 980 1TB drive, and a 3070 GPU; the system truly is extremely quick. (Win10+WSL2). (I'll have to try that compile in the next day or so; will reply to myself here).
- agloeregrets 5y agoIn native Typescript compile of a very large angular app I see an even more dramatic 1:20s to 40s compared to a desktop i9. I feel as if the M1 may have been designed around a detailed and careful look at how computers and compliers work and then designed a CPU around that rather than the other way around. It's like buying a car and modifying to take it racing vs buying a race car, the race car was designed to do this.
- zerkten 5y ago>> I feel as if the M1 may have been designed around a detailed and careful look at how computers and compliers work and then designed a CPU around that rather than the other way around. This is the position that Apple have set up for themselves with their philosophy and process. It would seem that Intel and AMD have to play a very conservative game with compatibility and building a product that increments support for x86 and x64. They can't make some sweeping change because they have to think about Linux and Windows. Apple own their ecosystem and can move everything at once (to a large degree.) This also gives an opportunity to design how the components should interact. Incompatibility won't be heavily penalized unless really important apps get left behind. The improvements also incentivize app makers to be there since their developer experience will improve.
- cbsmith 5y ago> It would seem that Intel and AMD have to play a very conservative game with compatibility and building a product that increments support for x86 and x64. Talk to people who design chips. The compatibility barely impacts the chip transistor budget these days, and since the underlying CPU isn't running x86 or x64 instructions, it really doesn't impact the CPU design. There may be some intrinsic overhead coming from limitations of the ISA itself, but even there they keep adding new instructions for specialized operations when opportunities allow.
- apozem 5y agoExactly this. Apple has spent decades drilling a message into third-party developers: Update your apps regularly or get left behind. Everyone who develops for one of their platforms is just used to running that treadmill. An ARM transition is just another thing to update your apps for.
- karmelapple 5y agoApp developers are incentivized in another way: software that takes advantage of new features or performance are often what Apple chooses to promote in a keynote or in an App Store’s featured section.
- 5y ago
- Keyframe 5y agoAre you counting download time as well? It took 8.30 sec on hexacore now when I tried it.
- kryps 5y agoNope, pure compile time on a Core i7-10750H with Windows and Rust 1.52.1, antivirus disabled. WSL did not make much of a difference though (29 seconds).
- Filligree 5y agoThe Windows filesystem is extremely slow, even without WSL. It can be mitigated to some extent by using completion ports, but I doubt the Rust compiler is architectured that way-- You should benchmark against Linux as well.
- kryps 5y agocargo install on WSL2 uses the non-mapped home directory, which is on an ext4 virtual disk. That is probably one reason why it is six seconds faster.
- otabdeveloper4 5y ago> Windows There's your problem. Even Microsoft concedes that Windows is legacy technology now.
- sinsterizme 5y agoYou must be joking? If not, provide us with a source
- josephg 5y agoI did a side-by-side comparing with my friends' M1 macbook and my (more expensive, nearly brand new) ryzen 5800x workstation compiling rust. The ryzen was faster - but it was really close. And the macbook beats my ryzen chip in single threaded performance. For reference, the ryzen compiles ripgrep in 19.7 seconds. The comparison is way too close given the ryzen workstation guzzles power, and the macbook is cheaper, portable and lasts 22 hours on a single charge. If Apple can keep their momentum going year over year with CPU improvements, they'll be unstoppable. For now it looks like its not a question of if I'll get one, but when.
- postalrat 5y agoHow long is the battery life on both if compiling non-stop? Assuming both keep similar compile from start of battery to end it would be interesting to see if the ryzen is truly guzzling batteries.
- omegabravo 5y agoI've done a side by side with my Ryzen 3700x compiling a Go project. 6 seconds on the Ryzen, vs 9 seconds on the M1 air. `time go build -a`, so not very scientific. Could be attributed to the multicore performance of the Ryzen. Starting applications on the M1 seems to have significant delays too, but I'm not sure if that's a Mac OSX thing. Overall it's very impressive, I just don't see the same lunch eating performance as everyone else. The battery life and lack of fans is wonderful. edit: Updated with the arm build on OSX. 16s -> 9 seconds.
- deleted 5y ago
- blinkingled 5y agoWhat OS are you running on the Dell though? Windows is notoriously slower for file system operations even without AV and the default there is to prefer foreground apps vs something like compile tasks.
- kryps 5y agoYep, see below. With WSL and an ext4 virtual disk it takes only 29 seconds. Still quite a bit more than the 22 seconds on the Macbook.
- blinkingled 5y agoWSL2 right? Given the virtualization overhead for IO I would expect native Linux to be faster.
- kryps 5y agoWSL2, correct.
- elcomet 5y agoIs 22 seconds insetad of 34 seconds so much faster ? The difference does not feel huge to me
- leetcrew 5y agoyes, it compiled the project in 35% less time. doesn't really matter much for such a small project, but imagine if on a larger project the intel part took an hour and the m1 did it in 39 minutes. that's a substantial speedup. of course, we might see different results after leaving the turbo window.
- cptskippy 5y agoYou're assuming that the scaling is linear though. What if there's a fixed 10 second ding on x86? That 39 minute compile on the m1 would only be 39:10 on the x86.
- coder543 5y ago> What if there's a fixed 10 second ding on x86? There isn't.
- jfrunyon 5y agoAnd yet it is extremely unlikely that it's linear or anywhere near it.
- coder543 5y agoWhat is "linear" in this context? If the Y-axis is performance, what is the X-axis? That statement doesn't seem to make much sense without any additional explanation. If I run a benchmark for a program on the M1, that's a single data point. It's hard to call a single data point "linear", "quadratic", or anything else... and you can't really put multiple benchmarks on the X-axis, because they're measuring different things. What would even make it (whatever "it" is) "extremely unlikely"? People have had over 6 months to run benchmarks on the M1. Surely you can find a concrete answer to your question that doesn't involve random speculation on internet forums? Based on my own experiences, I have no reason to believe that the M1's performance starts tanking if you run it for longer than a few seconds, in case you're implying that the other processors will "catch up" if they have longer to get up to speed... why would they? That makes no sense either. Longer compilations are faster on M1 too, relative to my Intel hexacore MBP, from what I've seen in the past. I mean, obviously, right? Why wouldn't they be? Intel's processors change frequencies in milliseconds... it doesn't take them minutes to warm up. The M1 isn't a silver bullet. AMD makes laptop processors that are more powerful. But the M1 is still really good for what it is, and those AMD processors consume notably more power than the M1 to achieve their performance.
- tobyhinloopen 5y agoHow long does it take on a Ryzen 9 5950X
- Synaesthesia 5y agoNote that's a 16 core CPU with 105W TDP compared to a quad core < 10W M1
- jbverschoor 5y agoYup, and the new macbook pro will probably be twice as fast
- ChuckNorris89 5y agoSource?
- jbverschoor 5y agoGut feeling ;-)
- cbsmith 5y ago5850U is an 8 core CPU with a TDP that is adjustable between 10-25w. If you want to keep it to 4 cores just so it is a fair fight, there's the 5400U/5450U. AMD does pretty well...
- Synaesthesia 5y agoYeah I'd say the M1 and latest AMD CPUs are virtually tied for fastest single threaded performance, edging out the best by Intel. But for something like compilation which is multithreaded obviously the higher core count will win.
- deleted 5y ago[deleted]
- 5y ago
- jfrunyon 5y agoOkay, compiling is faster. But you compile once and run many times. What about running it?
- pedrocr 5y agoIn previous discussions about this it was pointed out that LLVM may be significantly faster at producing ARM code versus x86. The comparison may still be the one that actually matters to you but at least in part be an advantage of ARM in general and not just the M1. rust is very good at cross-compiling so compiling to ARM on Dell and to x86 on the M1 may add some interesting comparisons.
- mumblemumble 5y agoSo then the next question is, is this really an apples-to-apples comparison? It wouldn't surprise me at all if the x86 back-end takes more time to run because it implements more optimizations.
- adriancr 5y agoI just did a test on my old Lenovo laptop... Intel i7-8565U CPU @ 1.80GHz # git clone https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep && cd ripgrep # cargo clean # time cargo build real 0m23,805s user 1m11,260s sys 0m3,806s How is my crappy laptop on par with your M1? :)
- kryps 5y agoYou are not doing a release build.
- adriancr 5y agothanks, problem solved - now it's 1 minute...
- bscphil 5y agoWow. The fact that my Sandy Bridge laptop from 2011 does it in only 1:41 is pretty indicative of how badly processor improvements stalled out last decade. My processor (like yours, 4c8t): https://ark.intel.com/content/www/us/en/ark/products/52219/intel-core-i7-2630qm-processor-6m-cache-up-to-2-90-ghz.html https://ark.intel.com/content/www/us/en/ark/products/52219/i...
- fomine3 5y agoYou compare TDP 45W CPU vs 15W. I think this is great improvement. (But latter one is also 25W cTDP and turbo boost provides more power, many factors depends on how the laptop implemented)
- adriancr 5y agoI think the point is even a laptop from 2011 is acceptable for development. I wouldn't mind the power draw since its plugged in, the compile time either, cold compile 20s-2min is much the same for me, recompile where it counts is much faster
- alkonaut 5y agoAre you compiling for ARM in both cases (or x86 in both cases)? Otherwise you are building 2 completely different programs, one is ripgrep for ARM and the other is ripgrep for Intel.
- saagarjha 5y agoThe programs would be pretty much identical until they are lowered, which is generally not a bottleneck for Rust compiles…
- hawski 5y agoAnd here I thought that having a desktop CPU like Ryzen 5 2400G with loads of RAM would take me somewhere. It took the machine around 71 seconds. EDIT: could you measure C compilation. For example: git clone --depth 1 --branch v5.12.4 "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git" cd linux make defconfig time make -j$(getconf _NPROCESSORS_ONLN) For me it's slightly below 5 minutes.
- danieldk 5y agoIt took the machine around 71 seconds. Are you including download time? On my Ryzen 7 3700X, it's done in 17 seconds.
- hawski 5y agoSpecifically I did it two times to not see the download/syncing time. Also to a fresh home. 3700X has 16 threads, 2400G has 8, that probably makes up for the most of the difference. But M1 has 8 cores (4× high-performance + 4× high-efficiency. Maybe rust version also counts? I'm on rust 1.48. EDIT: I checked on 1.52.1, which is latest stable and it went down to 54 seconds. So that also makes up a significant difference.
- vetinari 5y agoFor me, it takes 34 seconds on M1 (MBP13): Finished release [optimized + debuginfo] target(s) in 34.50s ... cargo install -f ripgrep 137,66s user 13,00s system 435% cpu 34,632 total For comparison TR1900x (yeah, desktop, power-guzzler, but also several years old), Fedora 34: Finished release [optimized + debuginfo] target(s) in 25.15s ... real 0m25,271s user 4m41,553s sys 0m7,216s
- Fergusonb 5y agoThank you for the perspective. Here's r7 4800HS (35w) on linux: Finished release [optimized + debuginfo] target(s) in 24.98s real 0m25.151s user 4m54.987s sys 0m6.764s
- mousepilot 5y agoI'd gladly spend 14 seconds if it helps me avoid Apple products!
- chmod775 5y agoOS matters for this comparison. If your Dell XPS was running Windows, that might explain the discrepancy. For instance Windows on NTFS etc. is notoriously slow at operations that involve a lot of small files compared to Linux or whatever on ext4. Unless your Dell was also running OSX, you're probably not comparing hardware here.
- thefourthchime 5y agoIt's been amazing for me.... EXCEPT for when resuming from sleep, for some reason it would be very slow for a minute. I have since FIXED THIS! The solution is to just not let it sleep. I'm using Amphetamine and since then it has been amazingly fast all the time.
- RankingMember 5y ago> I'm using Amphetamine and since then it has been amazingly fast all the time. I think these app makers might need to start focus grouping some of these app names. Not only is it going to be harder to search for this app, but it'll inevitably also lead to some humorous misunderstandings.
- sgerenser 5y agoThey already got pulled from the App Store (although Apple reversed course after significant badgering): https://news.ycombinator.com/item?id=25605880 https://news.ycombinator.com/item?id=25605880