Apples new M1 microprocessor - Page 1
Forum section: electronics / general

author: joseph nicholas
author_rank: Frequent Contributor
timestamp: November 12, 2020, 06:48:09 pm
content: As quoted from the Wall Street Journal.Apple’s M1 and the A14 chipsfor the latest iPhones and iPadswill be built on TSMC’s 5-nanome-ter manufacturing process. Intel’smost advanced chips are built on a10-nanometer process and delayswith its transition to 7-nanometerhave shaken up the chip maker.These chips don't require a fan in the new Apple laptop computers.

author: tom66
author_rank: Super Contributor
timestamp: November 12, 2020, 10:31:47 pm
content: Apple has already made fanless laptops in the past. It's not impossible, but the real question is how well does it hold up under heavy workloads.All well and good making claims like "3.5x faster" but if it can only run a benchmark like that for 10 seconds before thermally throttling...

author: Cerebus
author_rank: Super Contributor
timestamp: November 13, 2020, 01:32:52 am
content: Quote from: joseph nicholas on November 12, 2020, 06:48:09 pmNot quite so. In the two laptops released so far with this chip, one is fanless (the MacBook Air), the other has a fan (the MacBook Pro).

author: hans
author_rank: Super Contributor
timestamp: November 13, 2020, 07:21:05 am
content: Quote from: tom66 on November 12, 2020, 10:31:47 pmMy intuition: fanless designs only cool a couple of W. So max TDP sustained will probably throttle the CPU.So for the real picture on the M1, ignore the Macbook Air.I also find the 3.5x faster claim to be unfounded. They only showed 2 curves with no axis labels or anything. They probably compared it to their last-gen Intel devices though, so I would AMD to put a bit more resistance with their 4800U.. but even that chip isn't 3.5x faster than Intel alternatives. So if true, and Geekbench is accurate for once, that would be impressive.But I'm hard pressed that they actually built a CPU with single-core up there with desktop CPUs that need turbo's with 65W+ TDPs. Or perhaps x86 CISC is so outdated and bloated, that a RISC CPU is the way to go. Let's wait and see.. and with see I mean actual benchmarks, like ffmpeg x265 encoding, WAV>FLAC encoding, chromium compile, Blender renders, things like that.

author: Berni
author_rank: Super Contributor
timestamp: November 13, 2020, 07:52:21 am
content: Yep fanless computers are nothing new, even x86 machines do it, but they tend to be slow.Apple did some big claims there including "Worlds fastest CPU core" and "Worlds fastest integrated GPU". Doing that with a ARM core is very unlikely if you ask me. Those ARM cores are optimized for power and transistor count while x86 has constantly been pushing for more performance/MHz with power being only enough of a concern to make sure it doesn't melt at the high clock speeds. Apple is also famous for shitty cooling solutions that cook the CPU to death, but at least in that regard the ARM helpsSo in order to quality for both of those claims the M1 chip needs to have higher performance than for example the "Ryzen 9 4900H" with its intel matching performance/Mhz zipping along at 3.3GHz base 4.4GHz boost and Vega 8 graphics at 1.7GHz. But they never mentioned the word "mobile" in "Worlds fastest CPU core", so technically for that claim to be true they need to beat the current single threaded performance world champion that is the recently released "Ryzen 9 5950X" desktop CPU that combines the significant performance/MHz improvements of 3rd generation Zen architecture with a 4.9 GHz boost clock. Getting that from an ARM? Hah no way in hell.However i do think they might be able to go for "Worlds fastest ARM core" or "Worlds highest performance/watt" processor since the new TSMC process node is sure to give a great advantage there. But then just say so apple! Id be plenty impressed if you pull that off, no need to lie and oversell the performance that is most likely not there.So as usual Apples claims are as usual baseless marketing bullshit that don't provide any meaningful numbers or specs.

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 07:52:31 am
content: Apparently this coordinated release is now officially a shit show. There is no virtualisation support at API level so software devs are shot. On top of that macOS now calls home to check binary signing on app startup. The cluster that handled this fell over yesterday and locked up huge numbers of people’s kit entirely. This drew attention to the fact that it can be used for surveillance. Also iMessage end to end encryption is apparently no longer appearing in documentation. On top of that people are braking NDAs and the performance is definitely exaggerated outside of synthetic benchmarks.Also i note that to upgrade to 16Gb of RAM from 8Gb will cost you £200 here and you have to do this up front. I paid £248 for the 64Gb in my desktop PC.Even as a long term Apple user I’m out. They can go to hell. This is a ridiculous proposition.

author: Zucca
author_rank: Unknown
timestamp: November 13, 2020, 08:06:05 am
content: Quote from: bd139 on November 13, 2020, 07:52:31 am

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 08:19:32 am
content: LMAO half the software dev team at work have broken Macs this morning thanks to Big Turd as wellFriday the 13th is going to be an interesting day.

author: JPortici
author_rank: Super Contributor
timestamp: November 13, 2020, 09:39:33 am
content: Quote from: Berni on November 13, 2020, 07:52:21 amDon't worry, 'cause this time they have ACTIVE COOLING (Damn i can't find that ridiculous photo from the presentation)

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 09:41:43 am
content: Do you have to blow on it like your dinner?

author: Berni
author_rank: Super Contributor
timestamp: November 13, 2020, 09:49:05 am
content: Quote from: JPortici on November 13, 2020, 09:39:33 amMhm... just like the active cooling in the iMacs that lets the CPU get to >80 °C where it thermal throttles to protect itself to the point of loosing 1/3 of the performance, yet the fans still don't get to 100% speed because the users don't like loud fans. And this is a desktop PC, not a laptop.So are they going to stick these silly little ARMs into desktops too in order to solve cooling issues.

author: tom66
author_rank: Super Contributor
timestamp: November 13, 2020, 10:08:38 am
content: Many of these benchmarks are multithreaded benchmarks. Which is great if your workload is multithreaded but so much is not multithreadable.I have a 2019 Ryzen 3800X and its single-thread performance was only 50% faster than my 2010 Core i5. But multithread almost 600% faster.It looks like Apple are using big.LITTLE which is a common ARM architecture but it doesn't make a true octo-core CPU as only the big or LITTLE core in a core set can be active (presumably because they have some shared resources.) Maybe Apple has unlocked that for specific workloads that aren't data dependent.I also note Apple are shy about the clock rate of their CPU - now this isn't a useful benchmark between different architectures but might indicate how far behind Apple are. It takes a lot of knowledge to be able to get an x86 up to 4GHz. I'd be surprised if they're cracking 2GHz. Which will mean M1 will be exclusively for silly laptops, no one will use it in a proper workstation.

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 10:26:55 am
content: On benchmarks it's a little more disingenuous on Apple's part as well. It reports around the same as a Ryzen 5950X single threaded on Geekbench, not the most reliable synthetic benchmark either. But that's a pretty crap comparison because as mentioned the M1 only has 4 equal fast cores (versus 16 on the 5950X) and 4 shitty ones. The Ryzen has 16 equal cores, much larger unified caches and also when you take TDP into account, the M1 efficiency per core is still only 40% lower than the Ryzen and AMD are making reliable 20% gains per generation at the moment on performance at the same TDP and apparently are already testing parts on TSMC 5nm process.Also the M1 is clocking 3.2GHz base frequency. And it is 100% thermal throttled so like hell it'll be able to sustain the workloads they say it will.I get the feeling what is going to happen is this opens up a whole new benchmarking dick swinging competition rather than looking at the actual gains which so far apparently to really be a loss of privacy, decrease in overall flexibility, increase in cost and general bad story for the end user. Your computer is turned from a general purpose computer into an Apple Toaster.

author: madires
author_rank: Super Contributor
timestamp: November 13, 2020, 10:42:48 am
content: I doubt that Apple will sell the M1 to other manufacturers. It's meant to help Apple to increase profit and to entice more users to enter Apple's walled garden. Hence the aggressive marketing.

author: Berni
author_rank: Super Contributor
timestamp: November 13, 2020, 10:52:43 am
content: Quite a few benchmarks out there have an option to run in single threaded mode.The large steps that AMD has been taking in architecture improvements has closed the performance/MHz advantage that Intel. Combined with the high clock speeds means that the new Ryzen 5000 series beats intel in both multithreaded and singlethreaded benchmarks. This was pretty much the last advantage that Intel had, so they better do something quick.For Apple to swoop in out of nowhere and makes a ARM that beats both is pretty much science fiction.And since they are going to use this in the MacBook Pro means they intend this M1 chip to do heavy workloads like video editing or rendering (so also multithreaded) since the previous generation of MacBooks offers hefty high clock speed i7 processors (That thermal throttle due to overheating anyway but that's besides the point).

author: george.b
author_rank: Frequent Contributor
timestamp: November 13, 2020, 10:59:40 am
content: I found this to be an interesting read:https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive

author: hans
author_rank: Super Contributor
timestamp: November 13, 2020, 11:15:47 am
content: Let's also not forget that Apple really profits if they can show huge performance benefits of their own Macbooks vs their previous. They must have had plans for this M1 chip underway for years, so I don't think the cynical narrative of "planned cooling woes" in Intel designs of recent years isn't that unreal. I mean, who designs a freaking laptop with barely any heatsink contact on the CPU, and then adds a fan on the other side of the laptop? Yes, Apple:So in my opinion, any trumpet blown by Apple will be misleading, even in an Apple-to-Apple comparison (pun intended). I don't think they will show a honest comparison of silicon. I believe LinusTechTips was able to boost the i3 Macbook Air performance by about 13% just by "fixing" the cooling design. What if, magically, they know how to build cooling designs again?I'm undecided about the ARM cores coming out of nowhere. Recent ARM Cortex A7x designs are showing more/wider execution units, but I don't think they have both surpassed Zen 3's width nor clockspeed. So in that regard, it sounds like science fiction. The perf/MHz would almost suggest that even a Zen 3 core is stalled half of it's clock cycles. Then again, if you look at individual Geekbench scores, it does suggest that a single core can offer the performance in most tests...

author: madires
author_rank: Super Contributor
timestamp: November 13, 2020, 11:49:59 am
content: IMHO, Apple is comparing a sports car (customized ARM for mobile applications) with an SUV (x86). You can't transport a fridge with the sports cars, but it will fit perfectly into the SUV.

author: Cerebus
author_rank: Super Contributor
timestamp: November 13, 2020, 12:41:00 pm
content: Quote from: bd139 on November 13, 2020, 07:52:31 amThis needs to be tempered with a little bit of detail. It's just an OCSP certificate check. Most people reading this whatever their browser and operating system are suffering from the same security leak every time they visit a website using TLS if that website isn't serving a stapled OCSP certificate along with the standard X.509 certificate. The difference is that the OCSP check is going to go to the issuer of the site's X.509 certificate, and it's them that get the opportunity to surveil you should they choose to. In this case the OCSP check is being done as part of checking the signature of a binary, and Apple have their own PKI so the OCSP request goes to Apple servers. MacOS, like most others, does some OCSP certificate caching so the apparent 'phone home' only happens when cached certificates expire or are first seen.Yes, it looks like someone at Apple didn't account for the huge number of OCSP requests that would be caused by a whole bunch of people installing Big Sur* and starting off with empty OCSP caches and so, for a while, Apple's PKI servers choked on the load. It's not like they are the only large scale provider to get their sums wrong and stuff it up.* What kind of idiot scrambles to install a major OS upgrade on the first day of its release? If we've corporately learned anything, it's "Don't be the first totestrun a new operating system release in the wild".

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 01:58:19 pm
content: Quote from: Cerebus on November 13, 2020, 12:41:00 pmCorrect but I think it has some ramifications past that which are what need to be considered when you look at the fact that it doesn't actually land on Apple's servers but Akamai's CDN (massively untrusted company) and is apparently transmitted in plain text (I haven't got it on wireshark yet). Also if the network is not available it runs any old binary which is not exactly a winner for the security posture. Thus I can only conclude this is used to revoke developer certs which is, well, basically a vendor trust issue. On top of that with Big Sur, some system applications are given network privileges above the user (and Little Snitch / pf) including OCSP validation. Hmm beacon possibility?From a security perspective, my conclusion is that Bob's a imperialist wanker, Alice is making baaa'ing sounds while humping the device. The only winner is Mallory who can sit there and collect a lot of who, where and when.Quote from: Cerebus on November 13, 2020, 12:41:00 pmWell and interesting one there. A corporate engine forced this one. Someone sets a policy of "your operating system can be only N days out of date". Eventually everyone who isn't regularly updating gets fed up of the SSO solution refusing to let them in unless the node is updated. So they do. Eventually this just turns into a mindless process of "log in, oh look an update which I'm not going to be able to do anything until I upgrade". This is of course faulty but so are most humans and processes.

author: ConKbot
author_rank: Super Contributor
timestamp: November 13, 2020, 02:11:48 pm
content: Dont blindly buy into any "x nm process" hype blindly.From the derbauer video series where he took some processors in to a place with FIB/SEM to get cut them up and actually look at the transistors themselves.Proof in the pudding is in the eating, whatever mips/MHz/watt capability is demonstrated on a process, that is the thing to be interested in. Otherwise its just a process name that happens to have a nebulous number attached to it.

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 02:17:47 pm
content: Spot on. The important bit is not the size but the efficiency gain of the process. It just happens to be labelled with a size.

author: Cerebus
author_rank: Super Contributor
timestamp: November 13, 2020, 02:44:39 pm
content: Quote from: bd139 on November 13, 2020, 01:58:19 pmNot sure about that, and here's why. Although Apple do rely on Akamai for a CDN they also have their own which isn't exactly visible and is only, afaik, going to affect their mobile users. Apple have alotof kit colocated with mobile phone providers to serve a lot of the iPhone<->Apple traffic. What it looks like in standard IP terms may give a misleading picture, and you can only see the full truth if you have access to those networks at the SDN control plane level. This isn't generally well known, not a secret, but not generally well known. I know about it because I saw the infrastructure plan in one huge mobile provider's Confluence while I was consulting there.

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 02:53:29 pm
content: Yeah aware of that. Some if it was even on Azure a few months back. Apple own 17.0.0.0/8. You can BYOIP to CDN/cloud providers hence why we bought a /24 recently. YMMV but occasionally stuff in there is referred to edgesuite.net due to misconfiguration (fucking CloudKit wank shit)

author: Cerebus
author_rank: Super Contributor
timestamp: November 13, 2020, 03:15:25 pm
content: Quote from: bd139 on November 13, 2020, 02:53:29 pmThat may even be the beast of a telco that I'm talking about; when I last left them they were gearing up for a poorly planned and rushed network extension that would have brought Azure on-net for them and virtually pushed part of the local network out onto Azure via a horribly mis-thought-out addition of yet another overlay network onto their international backbone. Basically they were going to stretch their VMWare SDWAN o-u-t to commingle with Azure. What could possibly go wrong?

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 03:35:13 pm
content: Oh that sounds like one of those design by committee ideas that works on paper but the moment you hand it over to the NOC team they all start crying and leaping out of windows.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 13, 2020, 04:13:43 pm
content: Quote from: bd139 on November 13, 2020, 07:52:31 amThere is an element of this behaviour in Android too. E.g., I have an older Android tablet in my car for looking at the CAN bus. Every few months, I get an error message when I try to start the app, "App not owned!". Riiight. The cure is to take the tablet inside and let it connect to the Internet for a quick chat with the mother ship, after which the app is suddenly "owned" again.The result is that Android is dead to me - I simply don't want to waste any time on it, at all.Quote from: bd139 on November 13, 2020, 07:52:31 amApple and the other computer manufacturers are now just producing appliances and fashion accessories that you are expected to rent with monthly payments - you don't own anything, only the right to use it, in many cases on the condition that you accept being tracked and traced for someone else's commercial gain.Recently, I have been testing some open source software graphics software - specifically, Inkscape, and the Gimp. I was gobsmacked by how good they are compared to when I looked a decade ago. And they have portable versions too, just put them on your computer and run... - It seems to me that open source may have come of age, finally. - Just in time, it seems...

author: Cerebus
author_rank: Super Contributor
timestamp: November 13, 2020, 05:05:26 pm
content: Quote from: bd139 on November 13, 2020, 03:35:13 pmI accidentally got involved in a Skype meeting about this that centred around the single, highly intransigent, person who controls IP address allocations for the entire 100,000 employee enterprise who couldn't get their head around having IP allocations that 'belonged' to more than one country's operating groups. Add the security people, also not exactly known for their flexible attitude, into the equation and the conversation got fun, not. Meantime the poor ops guys in the meeting were just trying to find a way to make the thing work at all without getting their arses fried by management who'd set an arbitrary go-live date and then made contracts on that basis. Oh, and we were all working in different 'self managing' AglileTM*teams. My suspicion is that every single member of the ops team that was muted was probably audibly sobbing.I was in the meeting because the data in their IPAM is so rotten that we couldn't use it for network automation/orchestration so my team, tasked with designing/writing network orchestration stuff, also had to forcibly head up an effort to clean up the IPAM database that nobody else gave a flying one about and was thereby forced to get involved in lot of things like this that were theoretically 'Not my problem, John.'.*Twat Mark

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 05:12:11 pm
content: Bwuhahahaha that's about right./me goes and stares at the Netbox install full oflies.You want to see our AWS route tables - have one that is 98 lines long now to work around all the overlapping class B's from acqusitionsNot my problem very soon!

author: Marco
author_rank: Super Contributor
timestamp: November 13, 2020, 06:14:04 pm
content: Intel hasn't entirely been sitting still while this was coming BTW. Project Athena is producing somepretty spectacularbattery life in ultra-portables too.Of course PR wise Windows laptops are dragged down by the lowest common denominator, the unfortunate side effect of an open platform.

author: Marco
author_rank: Super Contributor
timestamp: November 13, 2020, 06:17:13 pm
content: Quote from: SilverSolder on November 13, 2020, 04:13:43 pmI expect it out of Android ... I find it strange Apple is letting this fester though, there is no real reason to check apps on startup. You can just get updated blacklists while online and check it against that, without leaking information.Deals with the US federal government they can't get out under from?

author: Mr. Scram
author_rank: Super Contributor
timestamp: November 13, 2020, 06:40:56 pm
content: Quote from: tom66 on November 12, 2020, 10:31:47 pmI've heard reports that the big numbers come from hardware acceleration. Let's see what real life benchmarks and experience are like.

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 07:00:22 pm
content: Best way to speed up your Mac:https://youtu.be/gFm3brOdxcw

author: Cerebus
author_rank: Super Contributor
timestamp: November 13, 2020, 07:03:38 pm
content: Before I watch it, what's the betting that that video is of a ballistic nature?

author: bd139
author_rank: Super Contributor
timestamp: November 13, 2020, 07:05:31 pm
content: Eventually maybe. Actually no much worse.

author: Cerebus
author_rank: Super Contributor
timestamp: November 13, 2020, 07:06:52 pm
content: I was disappointed. I was expecting something along the lines of a trebuchet.

author: tooki
author_rank: Super Contributor
timestamp: November 13, 2020, 07:32:40 pm
content: Quote from: tom66 on November 12, 2020, 10:31:47 pmIn the presentation, they somewhat hint at that in the Air, because with the MacBook Pro, they mentioned sustained performance for extended number crunching.For what it’s worth,analysis of and benchmarks on the latest iPads’ A14 SOC(which is without doubt less powerful than M1) are very, very impressive.

author: magic
author_rank: Super Contributor
timestamp: November 13, 2020, 08:28:25 pm
content: Quote from: bd139 on November 13, 2020, 07:52:31 amWas end to end peer authentication ever in there or could The Cloud set you up for a very private and secure session with the NSA?My familiarity with "secure communications" stuff kinda ends on protocols like PGP and SSH and the resulting conclusion that you can have security or convenience but not both. And Apple users surely demand the latter, so hmm...

author: tooki
author_rank: Super Contributor
timestamp: November 15, 2020, 03:03:18 pm
content: Quote from: magic on November 13, 2020, 08:28:25 pmDoes it not get exhausting, thinking people are always lying and/or out to get you?!?Anyhow, when it comes to Apple’s security, they document it pretty well. Attached is the current edition of their platform security guide. Page 99 is where iMessage’s architecture begins.As for whether iMessage isn’t end-to-end encrypted any more: aside from it being absurd to assume IMHO, the only real proof would be a comparison to the next edition of the platform security guide, with it showing a totally different architecture.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 15, 2020, 03:35:34 pm
content: Quote from: tooki on November 15, 2020, 03:03:18 pmAu contraire, it makes me feel WANTED!

author: bd139
author_rank: Super Contributor
timestamp: November 15, 2020, 03:45:52 pm
content: More trouble...https://twitter.com/patrickwardle/status/1327726496203476992

author: magic
author_rank: Super Contributor
timestamp: November 15, 2020, 04:08:54 pm
content: Quote from: tooki on November 15, 2020, 03:03:18 pmFTFYSo to save Dave's bandwidth bills and other people's time:On the receiving side, each user account on each iDevice generates a keypair and the public key is uploaded to Apple.On the sending side, all public keys of the addressee are downloaded from Apple and the message is separately encrypted with each of them so that any device can read it.Apple can generate a rogue keypair, add the public key to the list requested by the sender and decrypt the message. Meanwhile Apple users are getting excited over whether the protocol uses end to end encryption or notQuote from: tooki on November 15, 2020, 03:03:18 pmFor the record...We know that FBI already tried to get Apple to decrypt user data for them.We know that Twitter accounts have been pwned by social engineering attacks on the employees.We know that NSA had their wiretaps installed at a major US ISP.

author: bd139
author_rank: Super Contributor
timestamp: November 15, 2020, 04:30:07 pm
content: That's why I keep all my terrorist activity on pen and paper

author: Marco
author_rank: Super Contributor
timestamp: November 15, 2020, 04:54:01 pm
content: Quote from: magic on November 15, 2020, 04:08:54 pmThat's no different thant whatsapp, just because system which has integrated key distribution can set up a MitM attack doesn't mean the fact they say they won't is somehow invalid. Not too many people do physical key exchange and pinning with the apps which support it.

author: tooki
author_rank: Super Contributor
timestamp: November 15, 2020, 04:58:52 pm
content: Quote from: magic on November 15, 2020, 04:08:54 pmAnd how do any of those things justify your unfounded claims of Apple products being insecure? Apple refused to break its security to help the FBI. Twitter is unrelated. Apple isn’t an ISP.

author: bd139
author_rank: Super Contributor
timestamp: November 15, 2020, 06:10:12 pm
content: Our security guys just pulled the entire company’s macOS deployment (200 seats) this afternoon over the firewall drama. Turns out you can use it to exfiltrate data through NSUrlSession bypassing mandated corporate VPN. This is because Apple sees fit that their own software doesn’t have to live with the same rules as everyone else’s and bypasses it entirely opening a side channel. That’s a terrible security decision.Fortunately not my funeral.

author: magic
author_rank: Super Contributor
timestamp: November 15, 2020, 07:44:49 pm
content: Quote from: Marco on November 15, 2020, 04:54:01 pmI'm not comparing iMessage with competitors. I'm not even familiar with those products and don't use them.Just stating the obvious: if a consumer vendor tells you they can't read your data, they usually are bullshitting you. As shown above, you often don't even need to dig very deep to reach the "just trust me dude" parts.There are systems which try to actually be resilient against vendor compromise, but they are niche and harder to use.Quote from: tooki on November 15, 2020, 04:58:52 pmWell, they say they can't read your messages. I shown that they almost certainly can. Their system fails to meet their own security specification, I guess that would be deserving of a CVE if anyone actually took such things seriously in the first placeQuote from: bd139 on November 15, 2020, 04:30:07 pmYou may keep your terrorist activity on paper, but if there are other less savvy terrorists in the UK, one day you may find all your messages exfiltrated to some spooks for "threat monitoring". I hope you trust Her Majesty's IT department

author: tooki
author_rank: Super Contributor
timestamp: November 15, 2020, 08:27:41 pm
content: Quote from: magic on November 15, 2020, 07:44:49 pmExcept that you haven’tshownthat at all, you’ve onlyclaimedit. There are now billions of iMessage-capable devices in the wild. Logic dictates that if it were as trivial to crack as you claim, someone would have done it by now and claimed a bounty from Apple and respect from the infosec community.If iMessage were insecure, never mind trivially insecure, there would be rampant abuse of said vulnerabilities. But there isn’t, which certainly lends credence to Apple’s claims. Apple has been making privacy a major pillar of its product advertisement. Don’t you think that is nothing short of an invitation for security researchers to bang on it long and hard? And yet, still no cracks have been found.

author: Halcyon
author_rank: Unknown
timestamp: November 15, 2020, 10:49:44 pm
content: It'll be interesting to see what happens and how Apple decide to implement it.Apple's desktop/laptop market share has held steady for many years now, hovering somewhere between 9.5-10.0%. There hasn't really been any significant growth and anecdotally, I'm seeing and hearing of more people dropping Apple products than there are people switching to them.They need to stop this cycle of pissing their loyal fan base off, because they are slowly dwindling.Quote from: tooki on November 15, 2020, 08:27:41 pmI will say this from an actual security researchers point of view: Apple devices are among the easiest to extract data from. I'm not just talking about iMessage, but the entire contents of the device. This historically hasn't been the case but with research came some pretty novel solutions (ones which have existed for years and Apple has barely bothered to do anything about). I suspect the reason why these "vulnerabilities" haven't been patched by Apple is that the tools required are generally reserved for government agencies, law enforcement, and private firms with enough money to spend. It's not something a kid with a laptop can do, so the impact is fairly low to the general population. Secondly, some of these work arounds can't be patched for a variety of reasons, one being that Apple use it themselves for manufacturing and diagnostics.

author: magic
author_rank: Super Contributor
timestamp: November 15, 2020, 11:04:58 pm
content: If you don't want to believe you never willMeanwhile, here's an actual professional cryptographer discussing this exact flaw. A flaw that literal nobody like me expected to exist,obviously. This may give you an idea of how little prestige there is to earn in "researching" it. And of course Apple themselves would never brag about ability to spy on their customers for obvious reasons.https://www.schneier.com/blog/archives/2015/08/nicholas_weaver_1.html

author: Halcyon
author_rank: Unknown
timestamp: November 15, 2020, 11:13:48 pm
content: Quote from: magic on November 15, 2020, 11:04:58 pmInteresting article. Unfortunately, you won't find too many details out in the wild. Those in the know are bound by various NDAs and subject to their own Government's secrecy laws.The subject of warrants is interesting. There are various mechanisms to extract data from companies (not just Apple) and they don't necessarily need a warrant from a court to enact. Most of these cloud companies currently have a Mutual Legal Assistance Treaty (MLAT) in place to enable a Government agency in one country to seek information from a company operating in another country. These are about to be strengthened through new legislation being approved in several countries. Google has a whole help section on how these things work in a broad sense:https://support.google.com/transparencyreport/answer/9713961?hl=en

author: Cerebus
author_rank: Super Contributor
timestamp: November 16, 2020, 12:19:25 am
content: Subject for this topic: "Apples new M1 microprocessor"Most of the content: Nothing to do with the processor, just the usual quibbling about how bad/good Apple are from the usual suspects with their usual prejudices on the subject.For those quibbling over whether iMessage is secure, it's not particularly secure (depending on your threat model*), but it is much more secure than the thing it sought to replace - SMS. Anybody who wants actual message security, again depending on one's threat model, uses Signal.*The giveaway that you're in a poorly informed discussion of security is the failure to define a threat model before making an unqualified assertion that something is 'secure' or 'insecure'.Quote from: Halcyon on November 15, 2020, 10:49:44 pmBelying your prejudices again. The average person's PC -still a device- requires a crosshead screwdriver and something that can read a hard disk or SSD to extract all the data from it, the average iPhone user's data is much better protected.

author: Halcyon
author_rank: Unknown
timestamp: November 16, 2020, 01:55:19 am
content: Quote from: Cerebus on November 16, 2020, 12:19:25 amYou're asserting that I have been prejudicial in the past. How about sticking with the facts?Feel free to re-read what I wrote. I did say from the outset that it was unlikely to be a significant issue for most users. BUT, it's an issue that might worry some users. Just because you don't care, doesn't mean other people share the same opinion.Your argument is the equivalent of a kid getting into trouble then blaming it on someone else because they also did something wrong. It's not a tit-for-tat competition.The other point I'll make is what might not be possible today, could be possible tomorrow. It wasn't long ago that researchers and experts in the field had to send phones away overseas at great expense to have them unlocked. Now they can do it themselves with a laptop and an interface box. You're also forgetting that many low-end PCs and laptops now come with self-encrypting SSDs and/or TPM devices. The days of simply pulling a hard disk out and reading the data off are dwindling.

author: brucehoult
author_rank: Super Contributor
timestamp: November 16, 2020, 04:32:25 am
content: Quote from: Berni on November 13, 2020, 07:52:21 amApple isn't using ARM cores. It's using specially designed *Apple* cores that just happen to use the same Aarch64 instruction set as ARM cores. Apple could have used the POWER9 instruction set or the MIPS instruction set or the RISC-V instruction set and the performance of the same core design would be much the same.

author: Berni
author_rank: Super Contributor
timestamp: November 16, 2020, 07:43:49 am
content: Quote from: brucehoult on November 16, 2020, 04:32:25 amWell yes they might not be just taking ARMs core design and directly slapping it onto a chunk of silicon, but the design goals of the design are very similar. Its running the same RISC flavored ARM instruction set and trying to do it with low transistor count and power efficiency so one might expect to see performance somewhere within the same ballpark. Its running ARM code so it is an "ARM processor". Might even be the fastest ARM processor in the world (and i would certainly find that an impressive feat of engineering) but i find it very unlikely that such a core would suddenly surpass the performance of x86 cores that have been constantly developed and optimized for speed over the last 25 years. Right now these x86 are the fastest cores so being the "worlds fastest CPU core" would require being faster than those.It is debatable if the x86 instruction set is actually better than ARM. The CISC approach of x86 certainly made sense in the past, maybe it doesn't make so much sense these days, especially with all the legacy baggage it is dragging behind (I don't design CPUs so i wouldn't know if CISC still helps any, but the x86 set looks pretty messy by now)

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 07:56:40 am
content: If you have a look at the output of ARM compilers versus x86 there are some clear advantages to ARM in that space. I’ve seen up to 50% less instructions per task being executed on ARM due to the conditionals and orthogonality. Per clock they are more efficient execution wiser, power wise and scalability wise.The only issue is no one has made a 12 core desktop class ARM CPU with 4.7GHz peak clock that runs windows. Yet. It’s is possible.If someone started selling socketed ARM cores, chipsets and boards then x86 would be dead overnight. Apple doesn’t cut it as its toaster appliances so far.

author: brucehoult
author_rank: Super Contributor
timestamp: November 16, 2020, 08:07:17 am
content: Quote from: Berni on November 16, 2020, 07:43:49 amNot only did Apple not take ARM's core design and slap it onto a chunk of silicon, they also didn't take ARM's core design and tweak it a littleARM published the ARMv8-A instruction set specification in October 2011. The first things shipping with ARM-designed cores were in March 2015.Meanwhile, Apple shipped an ARMx8-A core entirely of their own design in the iPhone 5s in September 2013, a full 1 1/2 years earlier.It's not physically possible for Apple to have modified one of ARM's cores. Apple were first, by ages.

author: Berni
author_rank: Super Contributor
timestamp: November 16, 2020, 08:58:07 am
content: Quote from: brucehoult on November 16, 2020, 08:07:17 amI never said that Apple just used the stock ARM design like a lot of other vendors. What i was saying that the design goals for there chip are very similar to the design goals of the stock ARM designs. Both the "higher end stock ARM cores" and "Apple homecooked core" are going for getting a good deal of performance out of a low power, not so high transistor count core design while running the ARM instruction set in the low GHz figures. I'm calling it an ARM processor because it runs the ARM instruction set, not because it would be an designed by ARM chip. Yet still, im sure the stock ARM designs still have a good deal of room for improvement, but in the push for performance the guys at ARM would have already taken all the easy optimization tricks. So Apples chip is probably somewhere near the ballpark unless they came up with some really revolutionary cpu design trick.Getting the core to run at 5GHz is also part of the cpu design and optimization, long windy convoluted pipelines are the penalty to pay for that. Just going to a fancy new fab process node doesn't just magically it run at in high GHz digits. Tho x86 is these days mostly limited by how much power can be pumped in without the thing melting.

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 09:25:33 am
content: Yeah 5GHz things get interesting. It's really not trivial getting anything to even work up that end of the scale. If you consider the typical pulse can barely transition a the CPU die up there then things get even more hairy in the physics and design department. I think we're going to hit a wall. The 40% or so gain from ARM won't buy us much in that space. The computer scientists will however. I get the feeling that migrating processes and algorithms to many-core systems is going to be the winner and that's ARM's domain which is showing core scalability to 100+ cores whereas x86 seems to drop out around 50 or so at the moment.

author: madires
author_rank: Super Contributor
timestamp: November 16, 2020, 10:08:12 am
content: Since the x86 architecture isn't great anyway and it carries tons of legacy stuff, it's not hard to design something more efficient, smaller and more powerful.

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 10:11:45 am
content: Precisely. It's a 1970s design which has been hacked and hacked and hacked.ARM however is a 1980s design which has been hacked and hacked and hacked.Humans at their best

author: tszaboo
author_rank: Super Contributor
timestamp: November 16, 2020, 10:54:02 am
content: I estimated few years ago, that ARM could reach x86 performance and surpass it. I dont think it is quite there yet, but I dont think raw computing performance actually matters. What matters for most users, is how smooth scrolling is, and how much time it takes to start an application, or how fast animations are. That has little to do with the CPU performance, and these things are already faster on a ipad than on a low end laptop.Apple was in the perfect position to change to ARM, and they had a huge incentive to do this. Majority of their income is coming from the appstore, selling third party applications, that require little to no investment on their side. They are building the same walled garden with their macs now, and they expect similar income. In fact probably the only reason that they are not selling their phones and macs for a nominal fee, because they want to appear premium, and that is easier, if you sell your device for 999 than for 500.And one thing to get straight: Intel's nodes are better than TSMC's or Samsungs interms of transistor density. Meaning that they have better densities on 10 nm, than others on 7, they are just measuring it differently.

author: borjam
author_rank: Unknown
timestamp: November 16, 2020, 11:33:34 am
content: Quote from: bd139 on November 16, 2020, 10:11:45 amWell, maybe it was better designed in the first place and not really “hacked”.I remember Sun’s SBus, designed in the 80’s. They got it right and later they released a 64 bit version of SBus while the peecee wold had been struggling with appalling hacks such as ISA/EISA/VLBus/AGP until, finally, PCI came out.When was 64 bit SBus discontinued?

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 11:44:17 am
content: Oh yes ARM was definitely better designed in the first place.SBus/MBus were rather nice. I miss those machines, particularly my Ultra 2 desktop I had and the 1000E I stupidly used as a desktop for a bit. PCI came in with Ultra 30 if I remember. Hell I even miss SPARC. RIP

author: Berni
author_rank: Super Contributor
timestamp: November 16, 2020, 11:53:36 am
content: Yep i do agree x86 will get buried at some point, but it will take some time to gradually move everything away to something else, most likely ARM or RISC-V or something along those lines. Perhaps something that also includes a bit of hardware acceleration for x86 emulation because its hard to just throw away so much software.But yes good point that CPUs have gotten so fast these days that they are more than fast enough for everyday tasks. So the average mac user probably wouldn't be bothered even if these laptops are suddenly 50% slower according to benchmarks. The facebook page would still load up just as fast, a spreadsheet opens just as fast and they can listen to music in iTunes just as well. So yeah i think its mostly about creating the same iPhone walled garden on MacOS to pocket the 30% of all mac app sales and conveniently also flipping intel the bird as a bonus side effect. The users wouldn't be bothered since they are used to this app store kind of thing, but the app developers would certainly be bothered.Microsoft was trying to pull the same thing with the Microsoft Store thing on Win 10, but nobody liked it cause that's not how PC users want to get apps, while they could not just make win10 not run classical win32 apps as then nobody would want to use there OS anymore.

author: borjam
author_rank: Unknown
timestamp: November 16, 2020, 12:03:55 pm
content: Quote from: bd139 on November 16, 2020, 11:44:17 amI still have an Enterprise 450 doing its duty!(Although it’s a heretic Sun using PCI)

author: tszaboo
author_rank: Super Contributor
timestamp: November 16, 2020, 12:33:11 pm
content: Quote from: Berni on November 16, 2020, 11:53:36 amProbably not, and that's fine. If you look at computing, software is a lot more expensive than hardware. There are a lot of legacy applications that you need to use, there are parts of the Windows system, that nobody touched in the last 10 years. They dont want to rewrite it, and that's fine. If you look at what Intel is doing, they started to produce cores with different architectures. In the past, every CPU core had the same instruction set, the same extensions, the same amount of cache, otherwise the operating system gets confused. Now they started adding Atom cores coupled with high performance cores. Once the OS can handle it, you can do whatever you want. An ATOM core is what, 50 million transistors? The new nVidia GPUs are 50 Billion. The same way you left that ancient x86 core in your CPU, the same way they just going to leave that in, couple cores with a new instruction set, and leave it to the compilers.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 16, 2020, 01:48:34 pm
content: Quote from: NANDBlog on November 16, 2020, 12:33:11 pmThere have been attempts to get people off x86 code in the past (e.g. Itanium?) but these things flopped in the market for the reason you say - people's existing expensive code didn't work...so then the question becomes: what works better - a native x86 core or an emulation running on a different architecture? My money would be on the native core every time, all else being equal.

author: borjam
author_rank: Unknown
timestamp: November 16, 2020, 02:09:44 pm
content: Quote from: SilverSolder on November 16, 2020, 01:48:34 pmIt already happened. Which mobile devices use Intel CPUs?

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 02:11:50 pm
content: Quote from: SilverSolder on November 16, 2020, 01:48:34 pmTurns out transpiling it from x86 to ARM actually might end up fasterhttps://wccftech.com/m1-macbook-air-x86-emulation-faster-all-mac-models/Note that includes i9 and Xeon CPUs that are shipping.

author: tszaboo
author_rank: Super Contributor
timestamp: November 16, 2020, 02:27:25 pm
content: Quote from: bd139 on November 16, 2020, 02:11:50 pmEven Microsoft had x86 for 2 years now, but they dont have x86-64. Does apple have that? What about AVX? What about the doens of other instruction sets that were bolted on?

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 02:40:25 pm
content: Apple only does x86-64.Details here:https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environmentNo AVX, AVX2, AVX512. They are only one, potentially poor if it's AVX512, way to skin a cat. See:https://extensa.tech/blog/avx-throttling-part1/Again, burst performance is good but anything persistent, narp. The same may be true for the M1 ARM CPUs. Let's see what happens. Battles coming for the next year or so on this front I reckon.

author: Cerebus
author_rank: Super Contributor
timestamp: November 16, 2020, 02:55:42 pm
content: Quote from: Halcyon on November 16, 2020, 01:55:19 amWell, I've noticed you taking a rather biased approach to Apple in the past, so I think my assertion is justified particularly as it shows here. Your assertion that"Apple devices are among the easiest [of all devices] to extract data from" seems to add evidence to that, as you make a sweeping statement that isn't supported by the facts or by presenting any evidence. e.g. That the average PC has a data extraction barrier of near zero, much lower than, for example, an iPhone. You don't address theonepoint I made, wandering off to address points I didn't make, which to me at least is suggestive of dodging the point.Anyway, I seem to have achieved my objective of getting the thread back on track, so let's not flog the dead donkey eh?

author: SilverSolder
author_rank: Super Contributor
timestamp: November 16, 2020, 02:56:41 pm
content: Quote from: borjam on November 16, 2020, 02:09:44 pmWhich mobile devices use or run x86 code? x86 is pretty much a desktop thing, right?

author: SilverSolder
author_rank: Super Contributor
timestamp: November 16, 2020, 02:58:16 pm
content: Quote from: bd139 on November 16, 2020, 02:11:50 pmIn that case, all else is not equal! An emulation running on a brilliant processor will beat a slow native processor... but if we are talking about two equally brilliant processors... ? My money is on native!

author: brucehoult
author_rank: Super Contributor
timestamp: November 16, 2020, 03:08:24 pm
content: Quote from: bd139 on November 16, 2020, 10:11:45 amAarch64, which is what Apple's chips run exclusively, is nearly totally different to the 1980s 32 bit ARM design. It is very much a clean sheet post-2000 design, having learned things (good and bad) from PowerPC and Alpha and Itanium. It is much closer to Alpha and to RISC-V than to 1980s ARM.

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 03:09:11 pm
content: Quote from: SilverSolder on November 16, 2020, 02:58:16 pmIt’s not an emulation. It is directly recompiling the x86 code as ARM at startup. It treats x86 as a compiler IL.Quote from: brucehoult on November 16, 2020, 03:08:24 pmI was mostly referring to RISC CPUs in general there.

author: Cerebus
author_rank: Super Contributor
timestamp: November 16, 2020, 03:10:41 pm
content: Quote from: SilverSolder on November 16, 2020, 02:58:16 pmtranspiling \$\neq\$ emulating

author: SilverSolder
author_rank: Super Contributor
timestamp: November 16, 2020, 03:40:46 pm
content: Quote from: bd139 on November 16, 2020, 03:09:11 pmAh, I missed that, so the "hit" is taken on startup? - or is it perhaps only done once, and the resulting binary stored for later use?In order to be faster than an x86 hardware implementation, the target processor has to be faster at running its transpiled object code than the x86 processor is at running its native code...That just doesn't sound right, unless the hardware x86 implementation is really handicapped and unfixable... and nothing is unfixable, given clever enough engineers!

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 03:54:51 pm
content: It's done once at first startup.Converting x86 to ARM is interesting. x86 instructions are actually heavily microcoded so it's possible if you understand the semantics further than just the instructions but what side effects are, to produce more efficient code than the original architecture. On top of that some of the ARM instructions are super powerful. Nice example is CSEL, so to do a "max" function, you can:CMP w0, w1 # compare w0, w1CSEL w0, w0, w1, ge # if w0 > w1 then store w0 in w0 else w1That takes more instructions and more cycles in the x86 version. If you're calling that stuff thousands of times then you're on to a winner. But if you can reason about the compare and select function using an optimiser (peephole optimisers used to be used for this but I'm sure they have better ways) then you can shave off a feck load of microinstructions.Fine example of this is the objective C dispatch stuff in macOS which is easy to reason about and heavily optimised per architecture so probably has a huge gain.

author: Berni
author_rank: Super Contributor
timestamp: November 16, 2020, 03:58:08 pm
content: Quote from: SilverSolder on November 16, 2020, 03:40:46 pmIts proabobly the same as JIT compiling that has gotten so popular these days in the form of .Net and JavaScript. It crunches a block of code into native machine language and places a jump back into the compiler at the end of it, once the block of code gets to the end the JIT compiler takes over and compiles more of it. So code only gets compiled once its first executed. When it executes again its already native machine code, if it never executes then little/no work is wasted compiling it because it never gets there.This was already used back in 2000 in the form of so called "High level emulation" where a Nintendo 64 emulator called UltraHLE used this aproach to get a massive performance boost in emulating the console on x86. Back then PCs ware generaly not fast enugh to emulate consoles this powerful, especialy something like the N64 with its very different 64bit instruction set, weird float math, proprietary GPU etc..The issue with this on the fly translation aproach is that it can be very sensitive to the kind of code you want it to run. Some things translate really well and you get unbelevably good performance, while some code it just falls on its face and ends up running so slow to border on being unusable. If the code pulls some funky tricks the translator might really get confused about what it is trying to do and cause the resulting translated code to crash when run. So the results can varry wldly from app to app.

author: tszaboo
author_rank: Super Contributor
timestamp: November 16, 2020, 04:11:10 pm
content: Quote from: bd139 on November 16, 2020, 02:11:50 pmIn geekbench. It has been proved several times, that apple get points on geekbench that are completely bogus and manipulated. For example the Samsung whatever became faster than the iphone in geekbench x version, than x+1 came out and apple was again faster.But you dont have to believe me, there is this guy's opinion, ha has an operating system named after him(although this was a few years ago.):https://www.realworldtech.com/forum/?threadid=136526&curpostid=136666

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 04:14:44 pm
content: Geekbench is a load of shit for sure. The key thing though is measured compute performance. It appears that the answers are now in with Cinebench coming in...I'm going to fluffle my shitty little Ryzen T495s laptop (3500U) which turns up 876 on single thread on R23, 3544 on multiple core and cost 470 quid new. I'm not even going to try it on my big boy desktop

author: magic
author_rank: Super Contributor
timestamp: November 16, 2020, 04:23:17 pm
content: Quote from: bd139 on November 16, 2020, 03:54:51 pmYou need to catch up with Pentium 4 ISA extensionsCode:00000000 <max>:0: 8b 54 24 04 mov 0x4(%esp),%edx4: 8b 44 24 08 mov 0x8(%esp),%eax8: 39 d0 cmp %edx,%eaxa: 0f 4c c2 cmovl %edx,%eaxd: c3 retBTW, I'm not sure if the jmp/mov version isn't faster when the outcome of comparison is repetitive and can be evaded by branch prediction.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 16, 2020, 04:24:31 pm
content: Quote from: bd139 on November 16, 2020, 03:54:51 pmThe MAX example is interesting. The transpiler would have to recognize the string of multiple x86 instructions in the source code that are implementing a "MAX" function, and reduce those instructions to a single instruction on the target - Sounds difficult and prone to problems, since various source files could implement this in many different ways?But what's to stop an x86 engineer from using similar tactics in a native x86? - including adding an extra MAX instruction, if that makes a big difference in real world applications?Basically what I'm struggling with is the idea that one Turing machine architecture is intrinsically faster than another. Basically, for this to be true, one of the two machines would have to be doing unnecessary work, essentially wasting time instead of executing the programmed instructions? (given that they are equally fast!)

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 04:25:52 pm
content: Quote from: magic on November 16, 2020, 04:23:17 pmI get this with clang and optimiser doing its thing...Code:mov eax, esicmp edi, esicmovge eax, edi

author: borjam
author_rank: Unknown
timestamp: November 16, 2020, 04:29:41 pm
content: Quote from: SilverSolder on November 16, 2020, 04:24:31 pmNowadays it's harder to fathom because all people are seeing are the same CPUs from a single family: Intel.In the past, when there was cutthroat competition between the Alpha, MIPS, SPARC, PA/RISC and POWER architectures you saw the crown jumping from one to the next every few months. And yes, I haven't mentioned Intel. They were producing mostly overpriced toys.Have CPUs become perfect so that they can't improve anymore? I don't think so. Moreover, efficiency is really important as well.

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 04:33:11 pm
content: Quote from: SilverSolder on November 16, 2020, 04:24:31 pmYes they could which is the point of having generic instruction sets and multi-pass optimisers and the like. They compile to something fairly generic (intermediate language - LLVM IR) and then specialist translators and optimisers translate that to ARM code and optimise it. I suspect Rosetta 2 just turns x86 back into LLVM IR and then recompiles it using the existing optimisers and translators. Well that's how I'd do it. Apple contribute a lot to LLVM so it makes sense to leverage that. The key advantage is all your optimisation decisions are applicable to all code that is to be run whether it be from clang, rosetta or swift etc. If you come up with a speed hack one day or manage to compress a certain idiom into one instruction (common with ARM) then you can write an optimiser and everyone benefits instantly.Regarding instructions, that's exactly why there are bazillions of instructions in x86-64 and the semantics around edge cases on some weird ones is how we get nice security holes.Regarding different architectural speeds, turing completeness does not necessarily define something being efficient. In fact the original Universal Turing machine is horribly inefficent. Doesn't mean it's not useful or fast.

author: bd139
author_rank: Super Contributor
timestamp: November 16, 2020, 04:53:46 pm
content: Quote from: borjam on November 16, 2020, 04:29:41 pmThat's where AMD are winning now.As for Intel vs others, they mostly died because of hardware capital cost. Intel were far far far cheaper, the performance was largely better. I remember the company I worked for paying over £10k for one 360MHz PA-RISC CPU for an HP N-class whereas a 600MHz Pentium III Katmai was about the same speed for only £550. Buy two of them, a pile of ECC RAM, disks and windows NT and you had change left over from just the HP CPU. And only two years later they had 1.4GHz Tualatin parts that were 5x as fast (!).

author: Cerebus
author_rank: Super Contributor
timestamp: November 16, 2020, 04:59:57 pm
content: Quote from: SilverSolder on November 16, 2020, 04:24:31 pmIt's easier than you might think. You scan the input instructions and build a tree structure based on theirintent, you treat this exactly like you would treat the intermediate output of a compiler. At this point you have all the tricks of optimization and code generation in your hands. You can do dataflow analysis, you can reallocate registers and so on. Once you've done that you match the target instruction set to theintentssignalled by the intermediate tree representation using pattern matching (or as Aho, Ganapathi and Tjang called it "Code Generation Using Tree Matching and Dynamic Programming"*). There's a good chance that theintent"find the larger of two values and store it" will be represented the same in the tree however the original source program represented it, if you have a pattern for a target instruction that matches that it will get generated.You need to read the Ahoet alpaper and have a passing grasp of what compiler intermediate forms look like to really get a good feel for the method but it is both elegant and simple.*ACM Transactions on Programming Languages and Systems, Vol. 11, No. 4, October 1989, Pages 491-516.

author: magic
author_rank: Super Contributor
timestamp: November 16, 2020, 05:20:24 pm
content: Quote from: bd139 on November 16, 2020, 04:25:52 pmOkay, that's where ARM wins.You no longer compare two words and maybe overwrite one of them, but now you pick one of two words and move it to a third register. This can't be done with CMOV because it's a two argument instruction like most of x86.The reason those registers are allocated as they are is because of calling convention. The problem would go away if the function is inlined, assuming that code can be generated in such way that one of the inputs enters through the output register.Good example how minor differences in implementations of almost the same instruction can make or break real world code.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 16, 2020, 05:28:20 pm
content: Quote from: Cerebus on November 16, 2020, 04:59:57 pmI think I get it - the "footprints in the snow" look the same no matter which order the steps were taken?

author: SilverSolder
author_rank: Super Contributor
timestamp: November 16, 2020, 05:30:23 pm
content: Quote from: magic on November 16, 2020, 05:20:24 pmIs this an example of where x86 is, essentially, "wasting time" compared to ARM - by doing unnecessary stuff?

author: Cerebus
author_rank: Super Contributor
timestamp: November 16, 2020, 05:34:42 pm
content: Quote from: SilverSolder on November 16, 2020, 05:28:20 pmYeah, pretty much like that. I see it as a visual thing, and frankly am far too lazy to do the scribbling of diagrams necessary to do the explanation justice.

author: tooki
author_rank: Super Contributor
timestamp: November 16, 2020, 07:33:52 pm
content: Quote from: Halcyon on November 15, 2020, 10:49:44 pmBut Apple has, repeatedly, fixed the vulnerabilities used by those programs. They then find new ones, which Apple then fixes. The classic ongoing cat and mouse.

author: tooki
author_rank: Super Contributor
timestamp: November 16, 2020, 07:34:31 pm
content: Quote from: magic on November 15, 2020, 11:04:58 pmThat’s just more unsubstantiated speculation.

author: magic
author_rank: Super Contributor
timestamp: November 16, 2020, 07:41:02 pm
content: Quote from: SilverSolder on November 16, 2020, 05:30:23 pmWell, it surely needs to decode one instruction more. Whether it will run slower is hard to say, the first two instructions can be decoded in parallel and executed in parallel and only the CMOV needs to wait for them before executing. The MOV will use some resources while it is in progress, perhaps those could be spent on other instructions, if there are other things that could be done. Thanks to register renaming logic, the MOV probably will not create a pointless copy of ESI value, but it will flip a bunch of transistors in the renaming logic and use some power.I have almost zero experience with ARM, but off the top of my head there are several differences between the two which may affect performance:ARM has three operand instructions - the result can be written to a third register which is neither of the source registersX86 has two operand instructions - the result typically overwrites one of the inputsX86 can encode memory load and arithmetic in one instruction, ARM needs two instructions for thatX86 has variable length instructions and some common ones are very shortARM64 doesn't have variable length instructions and is easier to decodeI don't know how real world code density (bytes per actual work done) compares between these architectures, and this too can affect performance because of more or less "work" fitting in instruction cache.Turing completeness doesn't buy you much. Brainfuck is a Turing complete programming language with only two arithmetic operations - increment and decrement. If you try to make a CPU that way, good luck.The ultimate proof is in the pudding. Which laptop will be the fastest to compile a million lines of C++ code and to do so without catching on fire?Quote from: tooki on November 16, 2020, 07:34:31 pmIt's very substantiated, by Apple's own documentation. The protocol is easily backdoorable. If you trust Apple, and Orange Fascist's government and its spooks and the secret courts and gag orders, and Apples employees, and their internal procedures to prevent abuse by said employees, and the foreign spies working there, good for you. As far as I'm concerned, it's a gimmick and a marginal improvement over any other system like that. By far the biggest real world threat is passive network interception and plain old TLS takes care of that.

author: Twoflower
author_rank: Frequent Contributor
timestamp: November 16, 2020, 08:06:36 pm
content: Quote from: SilverSolder on November 16, 2020, 05:30:23 pmIt's not that simple anymore. Processors do some magic calledmacro-op fusion. The processor identifies some common instruction groups and fuses them to one internal operation that will be executed in one clock cycle and only uses only a single execution unit. You can probably argue that this causes unnecessary memory fetches (consumes power and takes place in memory/caches) and this additional effort for this translation.

author: Berni
author_rank: Super Contributor
timestamp: November 16, 2020, 09:12:59 pm
content: Quote from: SilverSolder on November 16, 2020, 05:30:23 pmIts more that modern CPU architectures constain so many optimizations that you can't simply count instructions.These CPUs have ways of executing more than 1 instruction per cycle, but it only happens when certain conditions are met. In cases where the next instruction requires the result of the previous instruction this can't happen, but when two or more consecutive instructions are unrelated and all use different subsystems in the CPU they might be executed simultaniusly. Similar for branch prediction and speculative execution, there are areas of the CPU that are already gearing up to execute a branch that is coming up, doing the calculations that only affect internal registers up front so when the branch happens the time taken to flush the pipeline and take the branch is minimised. The branch predictor sometimes gets it wrong too. Compilers tend to know about some of these subtelties and do some work of rearanging non critical instructions to best fill the CPUs pipeline.So even if one architecutre might use more instructions to do the same thing, its still possible it is faster if the CPU can really pack them into its pipeline efficiently.You can also see certain workloads be a lot slower on a certain processor just because the code works with too much data to fit into the cache. As soon as you have tight fast loops that try to access too scatered of a memory area that doesn't fit into cache the whole thing slows down by a lot as the core is twidling its fingers and waiting for data to arrive from RAM, while a CPU with a larger cache might be able to fit it in, barely needing to wait at all.

author: brucehoult
author_rank: Super Contributor
timestamp: November 16, 2020, 09:30:03 pm
content: Quote from: bd139 on November 16, 2020, 03:09:11 pmIf you find the length of time ago an idea was first proposed / tried some kind of argument against it, I'll just point out that recognizably modern RISC ideas date back to at least 1974 with the IBM 801 and even to 1964 with Seymour Cray's CDC 6600.RISC-V is also bringing back some other of Cray's brilliant 1970s ideas in a modern setting.

author: brucehoult
author_rank: Super Contributor
timestamp: November 16, 2020, 09:50:44 pm
content: Quote from: Berni on November 16, 2020, 03:58:08 pmThat's not what .NET does. It compiles the entire program from bytecode to native before running any of it.QuoteThere are plenty of examples before that.- java Hotspot 1999- VMware 1998. JITed x86 to x86 while replacing non-virtualizable code with safe code. This became unnecessary in 2005 once Intel added VT-x- MAME 1996. Slow CPUs (mostly 8 bit) are emulated interpretively, but later CPUs such as PowerPC, MIPS, SH4 are JITed.- Connectix Speed Doubler 1995 dynamically compiled m68k code to PowerPC. Apple's m68k emulator at the time was an interpreter.- IBM System/38, AS/400 1979. Programs are compiled to "MI" (renamed "TIMI" in AS/400) then compiled on first execution to the actual instruction set of the machine.

author: brucehoult
author_rank: Super Contributor
timestamp: November 16, 2020, 11:36:20 pm
content: Quote from: magic on November 16, 2020, 07:41:02 pmA lot of these things cancel out. Two instructions vs two uops on a complex instruction makes very little difference. Complex addressing modes might as well be instructions as they need their own "opcode-like" instruction bytes. The only thing complex addressing modes gains you is not having to specifically find and name a temporary register for the thing you loaded from memory -- which admittedly can be important if you only have 8 programmer-visible registers, but doesn't matter at all when you have 32.Let me just concentrate on x86's variable length instructions, which are not at all designed optimally for code size. Bear in mind there are a total of 256 possible 1-byte opcodes.- "X86 has variable length instructions and some common ones are very short"- yes, some of them. But x86_64 got rid of the very handy and commonly-used 1 byte 0x40-0x4f INC/DEC A/C/D/B/SP/BP/SI/DI and makes you use 2 byte add/sub instructions instead- there are a ton of 1 byte instructions which are 1 byte because, apparently, they only need one opcode, and not because they are common. For example 6 Add-with-carry and 6 subtract-with-borrow instructions. Sure, you need them (kinda) sometimes, but they are very very rare, especially in 32 bit or 64 bit code. AAA, DAA, DAS, XLAT, AAM, AAD, IN, OUT, HLT, LES, LDS (at least LSS, LFS, LGS were hidden away in longer opcodes), CMC, CLC, CLD, CLI, STC, STD, STI.- many common, or at least not unusual or weird, things are quite long. For example (omitting the return instruction in each case)...int64_t foo(int64_t n){return n + 128;}x86_64: 48 8d 87 80 00 00 00 lea 0x80(%rdi),%raxAarch64: 91020000 add x0, x0, #0x80RV64: 08050513 addi a0,a0,128PowerPC64: 38 63 00 80 addi r3,r3,128Everything is 4 bytes except x86_64 which is 7 bytes. And it doesn't even use an ADD instruction, but uses an addressing mode instead! If it used an add instruction it would be:48 89 f8 mov %rdi,%rax48 05 80 00 00 00 add $0x80,%raxThe actual add is a little shorter at 6 bytes, but in total 9 bytes are needed.As a bonus, 32 bit ARM (Thumb2):Thumb2:3080 adds r0, #128f141 0100 adc.w r1, r1, #0Two instructions and 6 bytes, but it's still shorter than x86_64. If it was a 32 bit value then only the first, 2 byte, instruction would be needed.QuoteAarch64 and x86_64 tend to overall work out to very very similar overall code size and overall uops executed.In 64-bit land, RISC-V 64 is the code size winner by quite a long way -- and the number of uops is again very very similar.Here's a four year old presentation on this subject by Chris Celio who did the OOO RISC-V "BOOM" CPU core and now works designing x86 CPUs at Intel:QuoteDefinitely.My AS Mac Mini has cleared customs in Auckland and has another 300 km to come. I'll have it in 2-3 days maximum and let everyone know my results building binutils, gcc, llvm firefox and other things like that.

author: Berni
author_rank: Super Contributor
timestamp: November 17, 2020, 06:39:52 am
content: Quote from: brucehoult on November 16, 2020, 09:50:44 pmhttps://www.geeksforgeeks.org/what-is-just-in-time-jit-compiler-in-dot-net/The whole thing gets compiled from C#/VB.net/F#...etc text source files into byte code all at once at compile time. Then when the exe is run it pulls in the .net libraries that start JITing the contained bytecode into machine code for the particular platform. Hence there is no long pause at startup of large multi megabyte .net apps.But there are tools to turn .net code into machine code up front in a additional recompilation step, this is mostly used to get .net code running on platforms that don't support .net framework, mono ..etcQuote from: brucehoult on November 16, 2020, 09:50:44 pmYep i was just using early N64 emulators one example that i could remember off the top of my head, showing a widespread use of JITing a foreign weird instruction set machine code into native machine code with impressive speed. The MAME dev history also shows the bigger 32bit CPUs getting supported around the same time.Point was about how that this approach to emulation is very much viable and can be impressively fast.

author: andersm
author_rank: Super Contributor
timestamp: November 17, 2020, 08:26:40 am
content: Just a sidenote, but UltraHLE's claim to fame wasn't JIT, but rather detecting and intercepting library calls, and executing native reimplementations instead, like eg. Rosetta.

author: DiTBho
author_rank: Super Contributor
timestamp: November 17, 2020, 11:54:17 am
content: Quote from: brucehoult on November 16, 2020, 09:30:03 pmWhich ideas, in details? That's super interesting

author: brucehoult
author_rank: Super Contributor
timestamp: November 17, 2020, 12:50:15 pm
content: Quote from: DiTBho on November 17, 2020, 11:54:17 amFor example, two ideas from the Cray 1:- shortening vector registers for small vectors or the last part of vectors longer than vector registers, avoiding the need for a scalar loop to process the "tail" as well as the main vector loop.- chaining of operations. RISC-V vector operations don't require a chaining implementation, but they permit onehttp://homepages.inf.ed.ac.uk/cgi/rni/comp-arch.pl?Vect/cray1-ch.html,Vect/cray1-ch-f.html,Vect/menu-cr1.htmlIn addition, while the Cray 1 had vector registers with 64 elements and the program had to know that, with RISC-V vectors the vector registers can be any length, and the program doesn't have to know the length.For example with the following C code:Code:void saxpy(float s, float *x, float *y, float *res, int len){for (int i=0; i<len; ++i)res = s * x + y;}Cray 1 code will look like (each of the functions starting with vec_ is actually an intrinsic function that translates to a single machine code instruction):Code:void saxpy(float s, float *x, float *y, float *res, int len){vector v1, v2, v3, v4;while (len > 0){int vl = len > 64 ? 64 : len;vec_set_len(vl);vec_load(v1, x);vec_load(v2, y);vec_mul_scalar(v3, v1, s);vec_add(v4, v2, v3);vec_store(v4, res);x += vl;y += vl;res += vl;len -= vl;}RISC-V vector code will look like:Code:void saxpy(float s, float *x, float *y, float *res, int len){vector v1, v2, v3, v4;while (len > 0){int vl = vec_set_len(len);vec_load(v1, x);vec_load(v2, y);vec_mul_scalar(v3, v1, s);vec_add(v4, v2, v3);vec_store(v4, res);x += vl;y += vl;res += vl;len -= vl;}The difference is the code for the Cray has to know there are exactly 64 elements in a vector register, but the RISC-V code automatically adjusts to hardware with vector registers holding anywhere from 1 element to 2^31 elements.

author: DiTBho
author_rank: Super Contributor
timestamp: November 18, 2020, 10:34:42 am
content: What is the "Neural Engine" core ?

author: tszaboo
author_rank: Super Contributor
timestamp: November 18, 2020, 11:23:15 am
content: Quote from: DiTBho on November 18, 2020, 10:34:42 amProbably a special part of the CPU, doing parallelized FP32 computations. Similar to Google TPU for example.Third party tests are coming in.https://www.anandtech.com/show/16252/mac-mini-apple-m1-testedAnandtech sad it's impressive, and they know what they are doing. Particularly impressive this Rosetta2, performance is 70-80% of native. And these are first generation chips, with low power design goals.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 18, 2020, 01:58:51 pm
content: Quote from: AnandtechThe only remaining question is - what are the downsides? Are there any?Remember, amateurs worry about how things work... professionals worry about how they fail!

author: bd139
author_rank: Super Contributor
timestamp: November 18, 2020, 02:05:15 pm
content: Quote from: SilverSolder on November 18, 2020, 01:58:51 pmVery true and exactly why I'm not buying one.OCSP validation of binaries meaning rights to run software you purchased can be arbitrarily revoked, Linux probably will never work on the hardware apparently due to signed boot and no documentation so it's landfill immediately when macOS is dumped, half the dev tools out there aren't even compiled for ARM, docker doesn't work, firewall can be entirely bypassed trivially from unprivileged applications and finally the gaping hole I'd leave in my wallet. It might be a decent bit of hardware but the stewardship is border-line incompetent imperialism.I'll just buy a 5900X and an RTX 3070 for my PC and still be up £100Edit: the bit I really can't get over is they're charging £200 here for 8Gb more RAM. I paid £240 for the entire 64Gb of stuff in my desktop...

author: borjam
author_rank: Unknown
timestamp: November 18, 2020, 02:07:12 pm
content: Quote from: SilverSolder on November 18, 2020, 01:58:51 pmMany Mac users work on technical fields, especially on ISPs, and they rely heavily on virtualization of Intel based Linux and FreeBSD systems. Those users also need a lot of memory, more than 16 GB.So these machines won't work for them.QuoteAnd what do worshippers in denial worry about?

author: SilverSolder
author_rank: Super Contributor
timestamp: November 18, 2020, 02:32:58 pm
content: Quote from: borjam on November 18, 2020, 02:07:12 pmSo, can we think of these things as decently performing but closed appliances, suitable for not-too-challenging applications by "aspirational" users that are not too price sensitive?If so, it sounds like Apple's strategy over the last decade or more is still alive and well - and there is no reason why they won't sell like hot cakes?

author: Cerebus
author_rank: Super Contributor
timestamp: November 18, 2020, 02:45:37 pm
content: Quote from: bd139 on November 18, 2020, 02:05:15 pmIt looks like Apple have already quietly indirectly acknowledged that they've fucked up there.Quote from:https://www.theregister.com/2020/11/17/apple_big_sur_privacy/The certificate checks are already in place in earlier versions of MacOS. The difference with BigSur, as I understand it, is that there aren't the same options as exist in earlier versions to say, "I know it's not signed to Apple's satisfaction, run it anyway" or those options are harder to access. Although Apple are one of the most arrogant vendors out there, to their credit they've done the turn around bloody quickly.QuoteRather early to say that, many versions of Apple hardware have been poorly supported or even unsupported by Linux when they first came out, and became perfectly tractable a few weeks/months down the line.

author: Cerebus
author_rank: Super Contributor
timestamp: November 18, 2020, 03:05:26 pm
content: Quote from: borjam on November 18, 2020, 02:07:12 pmVMWare have had a preview of Fusion for ARM on the Mac available for a while, they are also running one of their public previews of ESXi for ARM based servers. So it cuts the other way too, an ARM based Mac may become the only option for developers who want to play with virtualised ARM on the desktop to support playing with ARM server farms.Much of what's being said along the "it won't work" lines about the switch to ARM was being said back in 2006 when Apple did the PPC->Intel switch. I'd wait a bit for the world to catch up before I draw any final conclusions. Apple have done this before with the 2006 PPC->Intel shift, if any vendor knows how to do this without shooting themselves in the foot then it's Apple (assuming that they have a functioning corporate memory).Don't forget that Apple still have Intel processor based machines in their line up, so for anyone who can't play "wait and see" andneedsan Intel processor there's still the 16" laptop with up to 64Gb of memory and all the desktop and deskside systems (up to 28 cores, up to 1.5TB memory).

author: Marco
author_rank: Super Contributor
timestamp: November 18, 2020, 03:12:12 pm
content: Quote from: Cerebus on November 18, 2020, 02:45:37 pmOCSP was a giant mistake for the web before stapling, but stapling obviously doesn't work for apps. It will never stop being stupid for apps. There aren't that many app certificates, there's no good reason to pull the revocations. Just push them.I shouldn't need to opt out of the revocation mechanism to prevent leaking private data, it should just not leak private data.

author: bd139
author_rank: Super Contributor
timestamp: November 18, 2020, 03:15:06 pm
content: Quote from: Cerebus on November 18, 2020, 02:45:37 pmOn the last point it used the same signing infrastructure as iOS and we’ve seen how many iOS devices are running Linux kernels. It has got to “why bother” territory now.Quote from: Marco on November 18, 2020, 03:12:12 pmIt’s about controlling the App Store so they can pull Epic games type customers off etc. Nothing to do with signing. This is about authorisation not authenticity. If it was about authenticity then a delta CRL would scale fine particularly at the pace and size of macOS updates or interim ones.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 18, 2020, 03:15:41 pm
content: Quote from: Marco on November 18, 2020, 03:12:12 pmWhat is "stapling" in this context?

author: Marco
author_rank: Super Contributor
timestamp: November 18, 2020, 03:30:37 pm
content: Quote from: bd139 on November 18, 2020, 03:15:06 pmIf they push a revocation for Epic's certificate OSX can still just refuse to run it, push vs pull is irrelevant in that respect.

author: Marco
author_rank: Super Contributor
timestamp: November 18, 2020, 03:33:47 pm
content: Quote from: SilverSolder on November 18, 2020, 03:15:41 pmThe website request proof that the certificate is still valid on your behalf and then staples it to the reply of your request to the website, so you're not leaking private usage data all over the place.

author: borjam
author_rank: Unknown
timestamp: November 18, 2020, 04:36:15 pm
content: QuoteThe Apple obsession thinking that all Apple products are iPhones is really too much.No, it's an outstanding portable Unix workstation with the development toolchain and what you would expect on a Unix system (unless you are a lobotomized systemd worshipper) that happens not to run amd64 software. So in a way it's coming back in time to the old days when the workstationn processors were not Intel nor they were capable of running Windows.

author: borjam
author_rank: Unknown
timestamp: November 18, 2020, 04:39:42 pm
content: Quote from: Cerebus on November 18, 2020, 03:05:26 pmDon't point fingers at me, I am likely to get one!I very seldom use virtualization, running stuff on my servers instead. So the lack of Intel virtualization is not an issue for me.I was just pointing out that many of my friends are skeptical because of that single issue. Maybe in a month or two we will see a workableIntel virtualization solution based on emulation? Certainly it won't run games but it will be enough when testing server software, the purpose for which lots of developers run FreeBSD or Linux virtual machines.

author: Cerebus
author_rank: Super Contributor
timestamp: November 18, 2020, 05:52:35 pm
content: Quote from: Marco on November 18, 2020, 03:12:12 pmYeah, OCSP was created to solve the CRL problem - which is only really a problem when there are many different roots of trust you need to get CRLs from. In Apple's ecosystem Apple are a single source of trust for signing certificates, so a CRL, delivered incrementally, would have worked fine.

author: Cerebus
author_rank: Super Contributor
timestamp: November 18, 2020, 05:57:01 pm
content: Quote from: borjam on November 18, 2020, 04:39:42 pmWhy do you think fingers are being pointed? It's just continuing the discussion.

author: borjam
author_rank: Unknown
timestamp: November 18, 2020, 07:24:22 pm
content: Quote from: Cerebus on November 18, 2020, 05:57:01 pmSorry, poorly wordedI wanted to point out that I wasn't claiming "it doesn't work, won't work", but for now it is not ideal for certain users.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 18, 2020, 07:52:10 pm
content: Quote from: borjam on November 18, 2020, 04:39:42 pmI wouldn't be able to fit all the computers in the space available if I had to go physical with all my VMs - They really are God's gift to computing kind, in my view!

author: brucehoult
author_rank: Super Contributor
timestamp: November 18, 2020, 09:28:03 pm
content: Quote from: bd139 on November 18, 2020, 02:05:15 pmAs things are now, things will forever be.

author: brucehoult
author_rank: Super Contributor
timestamp: November 18, 2020, 09:29:05 pm
content: Quote from: borjam on November 18, 2020, 02:07:12 pmThere will never ever be a new Apple Silicon chip with more cores, more RAM.

author: brucehoult
author_rank: Super Contributor
timestamp: November 18, 2020, 09:32:51 pm
content: Quote from: Cerebus on November 18, 2020, 02:45:37 pmExactly.Production machines just started landing in user's hands this week.There are a lot of very clever people who would love to see Linux, docker and other things running on these. Gentlemen, start your engines.

author: brucehoult
author_rank: Super Contributor
timestamp: November 18, 2020, 09:35:53 pm
content: Quote from: Cerebus on November 18, 2020, 03:05:26 pmVMWare dude has ESXi running on a Pi 4, wants to get it working on ARM Macs...https://twitter.com/BruceHoult/status/1327540805947461632

author: tooki
author_rank: Super Contributor
timestamp: November 18, 2020, 11:10:57 pm
content: Quote from: SilverSolder on November 18, 2020, 02:32:58 pmNo, they're quite high-performing (for most tasks) semi-closed appliances suitable for lots and lots of challenging applications for both consumers and professionals who are willing to spend a little bit more up-front on a computer in exchange for reduced hassle during its lifespan.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 19, 2020, 02:07:36 am
content: Quote from: tooki on November 18, 2020, 11:10:57 pmI thought this thread (including the Anandtech link earlier) has established that the new Apple SoC is primarily efficient, rather than being the ultimate in absolute performance - i.e. the Intel and AMD processors it is being compared with are able to draw much more power if needed, at which point they blow the new Apple chip away?I'm glad there are choices available from Apple, Microsoft, and the open source community. As soon as you give up on the idea that one PC has to do everything, life becomes much simpler (but more cluttered)!

author: Marco
author_rank: Super Contributor
timestamp: November 19, 2020, 03:01:10 am
content: Quote from: SilverSolder on November 19, 2020, 02:07:36 amFor now.Apple sucks up massive amounts of margins from the market though and now PCs won't be able to get at least some of that back through the CPU/GPU vendors. Also Microsoft has been floundering for a long time and even if they weren't the ever impossible task for Microsoft to truly provide a stable platform over millions of different PC configurations is a constant drag on their competitiveness relative to Apple.On top of that Apple is getting in on finance in a big way and that will make using a Mac together with your iPhone even more of a package deal.The M1 isn't more choice, it's a big part of the impending doom for "open" PCs. Microsoft needs to make huge changes to regain it's competitiveness in the consumer space and it needs to do it soon ... processor performance is the least of their problems (as long as they stop wasting time with ARM, Qualcomm ain't Apple).

author: brucehoult
author_rank: Super Contributor
timestamp: November 19, 2020, 03:36:20 am
content: Quote from: SilverSolder on November 19, 2020, 02:07:36 amNope.The M1 is right up there, core for core, against the biggest baddest hot running desktop 125W i9 10900K, 105W AMD Ryzen 9 5950X etc.It's got fewer cores, of course.

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 07:37:08 am
content: Quote from: Marco on November 19, 2020, 03:01:10 amI don’t see this changing any time soon. There’s very little penetration of macOS outside the US and almost no corporate users in Europe. Anywhere with a strong security posture has windows as well due to GP and management infrastructure. The open PC runs the world.The open PC probably also runs Altium or Zukon which design the Macs

author: magic
author_rank: Super Contributor
timestamp: November 19, 2020, 07:47:31 am
content: Up against 5GHz turbo, tens of megs of L3 and AVX2?

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 07:48:43 am
content: Also against “affordable performance”

author: borjam
author_rank: Unknown
timestamp: November 19, 2020, 10:33:00 am
content: Quote from: bd139 on November 19, 2020, 07:37:08 amThe funny thing about "open" is that it may have so many meanings!I remember when Intel, while embroiled in antitrust troubles, boasted that their processors were "open" while others such as SPARC were "proprietary".Notably, SPARC was an architecture specification and anyone was able to purchase a license, design SPARC compliant processors and have them certified. The very definition of proprietary!

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 10:59:12 am
content: Indeed.PC platform and ISA is very open and well standardised. Intel are just sharecroppers on the land with everyone else at this point. They don't own it. The spiritual owner is IBM in theory.Not that any of this matters as the only thing people care about is the software and that is portable in theory.On that note, this is interesting:https://www.opengroup.org/openbrand/certificates/1212p.pdfmacOS on ARM is officially "a Unix".

author: borjam
author_rank: Unknown
timestamp: November 19, 2020, 11:10:14 am
content: Quote from: bd139 on November 19, 2020, 10:59:12 amYep, macOS has been Unix compliant for a long time.So, is an OS with an open source kernel (and other open source bits) open or not?Now imagine Apple adopting Motif!! That would be funny.

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 11:14:16 am
content: Exactly my pointAt least Motif is consistent over time(Nightmares of Cadence coming back now)

author: borjam
author_rank: Unknown
timestamp: November 19, 2020, 11:34:35 am
content: Quote from: bd139 on November 19, 2020, 11:14:16 amYou're not even wrong.Open Look!(I remember I used Open Look on FreeBSD for a while)

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 11:38:41 am
content: Ugh I never got on with that one. I had a SPARCstation 5 as a workstation with it for about 6 months. Annoyingly my home directory was network mounted and they had a script that rewrote everyone's X sessions overnight. I had a locally compiled FVWM available fortunately.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 19, 2020, 12:44:34 pm
content: Quote from: brucehoult on November 19, 2020, 03:36:20 amSo in the same sense that a 4 cylinder engine is just as powerful as a V-8, cylinder per cylinder?

author: DiTBho
author_rank: Super Contributor
timestamp: November 19, 2020, 01:25:07 pm
content: why Apple didn't choose RISV-V?

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 01:26:55 pm
content: Because it doesn't really exist yet in the real world. And they have a long history of ARM usage and experience.This is interesting:https://www.avantek.co.uk/arm-server-h270-t70/

author: brucehoult
author_rank: Super Contributor
timestamp: November 19, 2020, 07:32:46 pm
content: Quote from: SilverSolder on November 19, 2020, 12:44:34 pmThat comparison would make a lot more sense if cars ran on 1 cylinder most of the time.My 4-cylinder car with turbo embarrasses most V-8s ever made, while using much less fuel on average.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 19, 2020, 07:54:10 pm
content: Quote from: brucehoult on November 19, 2020, 07:32:46 pmI can absolutely live with a 4 cylinder turbo instead of a naturally aspirated V8, but if all else is equal (i.e. put a turbo on the V8 as well)... the v8 will be twice as powerful.I don't know about you, but the workload on my PC is "lumpy"... long periods of light load, and then suddenly a massively intensive task that the user (me!) wants completed by yesterday!If you are not the kind of user that ever causes intensive loads, then you don't need a V8 or a turbo 4... you are a non-challenging use case. I think that is the target market, initially, because most users fit that profile (most people don't have V8 or turbo 4 cars either).

author: brucehoult
author_rank: Super Contributor
timestamp: November 19, 2020, 09:53:05 pm
content: Quote from: SilverSolder on November 19, 2020, 07:54:10 pmFor the intensive massively parallel loads, I have a 32 core Threadripper.For anything that uses four threads or fewer my M1 Mac Mini is faster than the Threadripper.I've updated my trivial little primes numbers benchmark results to include the M1, both native and using Rosetta. It kills on this task.http://hoult.org/primes.txtCode:// 2.735 sec i7 8650U @ 4.2 GHz 242 bytes 11.5 billion clocks// 2.795 sec Mac Mini M1 @ 3.2 GHz (?) 212 bytes 8.9 billion clocks// 2.872 sec i7 6700K @ 4.2 GHz 240 bytes 12.1 billion clocks// 2.925 sec Mac Mini M1 @ 3.2 GHz Rosetta 208 bytes 9.4 billion clocks// 3.448 sec Ryzen 5 4500U @ 4.0 GHz 242 bytes 13.8 billion clocks// 3.515 sec Threadripper 2990WX @ 4.2 GHz 242 bytes 14.8 billion clocksI have other larger tests in progress, such as building a RISC-V cross-compile toolchain with bunutils, gcc, gdb, newlib. I'll report back soon.

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 10:10:26 pm
content: Interesting comparison....Ryzen 3600 / gcc 9.3.0:Code:3713160 primes found in 3238 ms276 bytes of code in countPrimes()Ryzen 3600 / clang 10.0.0Code:3713160 primes found in 3517 ms240 bytes of code in countPrimes()DISCLAIMER: these are run inside virtualbox not on native hardware.Will have native hardware and a 5900X to compare to if anyone ever get some fucking stock inEdit: slightly disappointed in clang if I'm honest.Edit 2: Xeon Platinum 8151 @ 3.4GHz (AWS z1d) / CentOS 7 gcc 7.3.1Code:3713160 primes found in 3505 ms244 bytes of code in countPrimes()Edit 3: "AArch64 Processor " AWS g6g graviton 2 / AWS Linux gcc 7.3.1 (think its centos recompiled)Code:3713160 primes found in 6377 ms276 bytes of code in countPrimes()Slooow.M1 = exceptionally good.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 19, 2020, 10:39:58 pm
content: Quote from: brucehoult on November 19, 2020, 09:53:05 pmI don't normally switch between different PCs depending on the load... I have one workstation, it does many jobs at the same time by running many VMs, and therefore benefits from many cores. This is probably a heavier than average workload, but that's why processors with more cores exist.I also use applications like video editors and others that can make use of parallel processing - even if this is not used all the time, it is nice that it is available when it is.Your benchmark is interesting and definitely shows the M1 core itself is no slouch, in the right circumstances.

author: Marco
author_rank: Super Contributor
timestamp: November 19, 2020, 10:47:18 pm
content: Quote from: bd139 on November 19, 2020, 07:37:08 amIt's a tower of sand, offices are going to go back to dumb terminals and a windows computer is an even more terrible terminal than a desktop environment ... it requires an incredible amount of management infrastructure to deal with just how terrible a terminal it is.But I said Microsoft would lose the consumer space. Inertia is much less of a factor there ... and all that management infrastructure protecting fools from the insufficiency of Windows at the office fails to protect them at home. System administration for windows is a terrible job and consumers are going to rid themselves of it.QuoteUntil one of them ports.

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 11:12:34 pm
content: Yeah the company I just landed a job at today is doing exactly that. Another SaaS provider destined to move an entire meta function onto the web. But it’s a long struggle that change. Windows admin is big money. There are MSPs by the million taking a cut because of the management costs.I bet we won’t see either on native Mac for at least ten years. Big chunks of rancid win32 don’t move well.

author: brucehoult
author_rank: Super Contributor
timestamp: November 19, 2020, 11:14:59 pm
content: Quote from: bd139 on November 19, 2020, 10:10:26 pmI'd definitely be interested in Zen 3 (5900X) numbers!I'm not sure if it's worth adding the others. Maybe the Xeon .. oh and the graviton you just added while I was composing.Hmm .. I should note in my results the Zen 2 4500U is in WSL2.

author: brucehoult
author_rank: Super Contributor
timestamp: November 19, 2020, 11:20:40 pm
content: Quote from: SilverSolder on November 19, 2020, 10:39:58 pmSure, and that's why I have a monitor on the Threadripper and use it as my main machine for almost everything, even though I have three other boxes with 15% or 20% better single-core speeds (8650U NUC, Zen 2 Thinkpad, M1 Mac Mini). 20% isn't usually enough to make me care single core, and when something is parallelizable the TR just rocks. And I can run background tasks on it that use a bunch of cores and don't even affect normal use at all.But I do things with other ISAs including ARM and RISC-V and it's nice to have real hardware that is faster than QEMU on the x86. Having ARM hardware that is JUST AS FAST (or even faster) than the x86 is super.

author: brucehoult
author_rank: Super Contributor
timestamp: November 19, 2020, 11:24:02 pm
content: Quote from: bd139 on November 19, 2020, 10:10:26 pmThat's "M6g", yes? Does /proc/cpuinfo (or otherwise) give a clock speed? Or lscpu when under load?

author: bd139
author_rank: Super Contributor
timestamp: November 19, 2020, 11:59:12 pm
content: C6g which is compute optimised apparently. No MHz in cpuinfo. I’ll fire up another instance tomorrow and try lscpu.

author: brucehoult
author_rank: Super Contributor
timestamp: November 20, 2020, 12:04:46 am
content: Quote from: bd139 on November 19, 2020, 11:59:12 pmInternet says Graviton 2 is 2.5 GHz. Would be good to have a cross check.I've added that and the Xeon 8151 to my file. I've put the Xeon as 4.0 GHz as that's the turbo speed.

author: Berni
author_rank: Super Contributor
timestamp: November 20, 2020, 06:59:15 am
content: Those are some impressive numbers there. Certainly faster than i was expecting from it.Here are some Cinebench R23 scores against some of the other popular mobile CPUs:https://wccftech.com/intel-and-amd-x86-mobility-cpus-destroy-apples-m1-in-cinebench-r23-benchmark-results/In terms of latest Ryzen chips one datapoint is a Ryzen 5 5600X with 6 cores doing 3.7GHz base clock and 4.6GHz single core boost clock it gets a scores:single tread: 1572multithreaded: 11268So yes still not living up to the bullshit claim of "Worlds fastest CPU core". Still this is being compared to a desktop CPU with a 65W TDP while the M1 is a mobile CPU with 15W TDP. This is a very impressive amount of speed and looks like it does take the title of "Worlds fastest ARM core" and also "Worlds highest performance/watt CPU core" as i was predicting. But i do admit i was underestimating just how much speed they can get out of it. Good work apple engineers, even if the marketing department sort of buries the achievement under marketing bullshit.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 20, 2020, 02:30:43 pm
content: Quote from: Berni on November 20, 2020, 06:59:15 amEngineering team makes it to Mars - marketing claims they reached Pluto. It was ever thus...

author: Cerebus
author_rank: Super Contributor
timestamp: November 20, 2020, 02:50:14 pm
content: Quote from: SilverSolder on November 20, 2020, 02:30:43 pm

author: brucehoult
author_rank: Super Contributor
timestamp: November 21, 2020, 07:54:28 pm
content: I got arm64 Ubuntu running in a VM on the M1 Mac Mini.Just off the live CD image so far. I've done an install onto another virtual disk but can't get that to boot :-(

author: brucehoult
author_rank: Super Contributor
timestamp: November 21, 2020, 09:17:49 pm
content: Quote from: bd139 on November 13, 2020, 07:52:31 amThere are no NDAs now.In real use performance is as good as the best Windows or Linux x86 machines. No problems. Even emulated x86 apps feel absolutely normal and snappy.As for VMs, that's just wrong. I've been running arm64 Ubuntu in a VM on mine. Performance is just a hair from native -- I guarantee you've never seen such arm64 Linux performance elsewhere.

author: brucehoult
author_rank: Super Contributor
timestamp: November 21, 2020, 09:24:03 pm
content: Quote from: tom66 on November 13, 2020, 10:08:38 amAll 8 cores operate at the same time if there are more than 4 active threads.To a first approximation the small cores seem pretty much as useful (or not) as hyperthreading on Intel/AMD i.e. it's like 4 cores plus HT.QuoteI don't really know the true clock rate. Some things report 3.2 GHz. In any case it performs like any i7 or Zen with a 4 GHz turbo, so maybe 3.2 is just the base speed, or maybe that's the 8-wide dispatch at work. I dunno.I plan to do some serially-dependent benchmark to figure out the true clock speed e.g. a a few billion adds in a row with each depending on the previous one.

author: bd139
author_rank: Super Contributor
timestamp: November 21, 2020, 09:33:11 pm
content: Excellent news all round. So do I buy a 5900X and a 3070 RTX or a Mac MiniMy new employer has ordered me an i9 dell laptop and I get a hefty AWS budget every month to piss up the wall so I don't need the Ryzen at home now.

author: brucehoult
author_rank: Super Contributor
timestamp: November 21, 2020, 09:34:10 pm
content: Quote from: bd139 on November 13, 2020, 10:26:55 amThe M1 isn't competing against the 5950x, it's competing against the four core 3100, 3300X, 4300G, 4350G, 3700U and to a large extent against the 6 core non HT such as the 4500U also.There will be other chips with more cores later.QuoteI'm seeing *zero* signs of thermal throttling on my M1 Mac Mini, even after hours. It doesn't get either warm or noisy.QuoteI really don't know where you're getting any of this from.I'm compiling and running my own code (and open source code) as usual. Everything runs great, whether compiled for arm64 or amd64. I'm running the standard Ubuntu arm64 ISO in a VM, with performance just a percent or two below native.

author: brucehoult
author_rank: Super Contributor
timestamp: November 21, 2020, 09:36:37 pm
content: Quote from: bd139 on November 21, 2020, 09:33:11 pmIt's obviously not going to compete with a 12 core 4.8 GHz 5900X. You'd better get that or wait six or twelve months.

author: tooki
author_rank: Super Contributor
timestamp: November 21, 2020, 09:49:56 pm
content: Quote from: SilverSolder on November 19, 2020, 02:07:36 amApple has at no time claimed it’s the most powerful CPU out there. But what they are claiming is that it beats the fastestlaptopCPUs while using a fraction of the power:https://www.apple.com/mac/m1/They expressly say that it outperforms the (unspecified) laptop chip at all power levels. The footnote says “Comparison made against latest‑generation high‑performance notebooks commercially available at the time of testing.”So yes, it’s incredibly efficient. But it’s not efficiency at the expense of performance, it’s efficiency leveraged to provide outstanding performance since it’s not constantly running into thermal limits or battery life considerations, like (for example) my 2012 i7 MacBook Air.

author: brucehoult
author_rank: Super Contributor
timestamp: November 21, 2020, 09:52:58 pm
content: Quote from: Berni on November 13, 2020, 10:52:43 amThe M1 beats the previous Intel chips Apple was shipping.It doesn't beat the very latest Intel and AMD chips (with comparable core count), or at least not by much, and wins some benchmarks and loses some -- but not by a lot either way.The M1 is *competitive* with the latest Intel and AMD 4 core + HT or 6 core without HT offerings. For example it's faster single-threaded and competitive multi-threaded with the 6 core Zen 2 4500U in my Thinkpad E14 Gen 2.

author: tooki
author_rank: Super Contributor
timestamp: November 21, 2020, 09:54:18 pm
content: Quote from: SilverSolder on November 19, 2020, 12:44:34 pmThere is far, far, FAR more to an engine’s performance than the number of cylinders.Similarly, there is far, far, FAR more to CPU performance than the number of cores and the clock speed.

author: tooki
author_rank: Super Contributor
timestamp: November 21, 2020, 09:56:24 pm
content: Quote from: brucehoult on November 21, 2020, 09:52:58 pmThat’s not what Apple is saying with regards to laptops, where they’re expressly comparing it to “latest‑generation high‑performance notebooks commercially available at the time of testing.”

author: brucehoult
author_rank: Super Contributor
timestamp: November 21, 2020, 10:02:15 pm
content: Quote from: bd139 on November 16, 2020, 04:14:44 pmI have no idea why people obsess over Cinebench. Rendering video is something I use my computer to do .. basically never.Linux kernels builds are at least somewhat relevant to what I do with a computer that is performance-critical -- I watch a lot of youtube (or VLC) but once you're not dropping frames extra performance is irrelevant.

author: bd139
author_rank: Super Contributor
timestamp: November 21, 2020, 10:10:37 pm
content: I do a hell of a lot of transcoding on mine.As for my earlier requirement, the compute requirements of my desktop are now very low thanks to new role. 5900X would be a pointless purchase for me now.

author: brucehoult
author_rank: Super Contributor
timestamp: November 21, 2020, 10:14:33 pm
content: Quote from: borjam on November 18, 2020, 02:07:12 pmVirtualization of arm64 OSes works fine. I'm doing it. Look back a couple of posts. I'm running arm64 Ubuntu on my M1.Emulation of x86 works fine, at mostly 70 to 80% of native speed. I've seen cases of up to 95% of native e.g. my primes benchmark.Of course some people need more than 16 GB of RAM. So wait a few months.Personally, my big Threadripper has 128 GB, but that's mainly so each of the 32 cores has 4 GB to work with. On an effectively 4 core machine 16 GB is fine for most purposes.

author: Cerebus
author_rank: Super Contributor
timestamp: November 21, 2020, 10:16:55 pm
content: Quote from: brucehoult on November 21, 2020, 10:02:15 pmI think the general public would put those two the other way around, possibly in exactly the same terms.

author: tooki
author_rank: Super Contributor
timestamp: November 21, 2020, 10:29:16 pm
content: Quote from: brucehoult on November 21, 2020, 10:02:15 pmProbably because video encoding is one of the most demanding CPU tasks. When not hardware-accelerated, it’s incredibly taxing on a system, as it involves gargantuan amounts of data and processing. (We use compressed formats that have staggering compression ratios. The raw data the encoder needs is huge, and the amount of processing needed to achieve high compression is insane.)The typical things most people do most of the time (web browsing, watching videos, creating documents, etc) simply aren’t demanding enough to tease out meaningful performance comparisons.I remember back in the early 90s, when computer benchmarks ran massive scripted suites of real-world software, that one common benchmark item was how long it took a spreadsheet (originally Lotus 1-2-3, later Excel) to recalculate a spreadsheet with a couple of thousand cells. (Not lines. Cells.) They had to increase the size of the spreadsheets to keep up with performance improvements, before eventually abandoning that test because all computers got fast enough that recalculating a spreadsheet became instant, so they just made it automatic as we know it today. (IIRC, we got to the point in those tests that they couldn’t even increase the test spreadsheets, as they’d reached the limits at the time of how many columns and rows you could have; that is, limits written into the code, not computing resource limits.)

author: dr.diesel
author_rank: Super Contributor
timestamp: November 21, 2020, 11:35:02 pm
content: Sure wish this hardware could be had for us Linux guys.Any rumors of higher performance ARM laptops on the horizon?

author: bd139
author_rank: Super Contributor
timestamp: November 21, 2020, 11:41:04 pm
content: Nope.This is interesting though:https://info.crunchydata.com/blog/postgresql-benchmarks-apple-arm-m1-macbook-pro-2020

author: Berni
author_rank: Super Contributor
timestamp: November 22, 2020, 09:03:34 am
content: Quote from: tooki on November 21, 2020, 10:29:16 pmWell, i was recently using Excel to quickly plot some CSV data and once you get to >100k rows things start to really slow down. I had cases where excel would lock up for >30 seconds at a time after pressing a button to munch away at data. Admittedly this was like a >30MB CSV file but still, modern computers should handle that (There are now CPUs that could fit the whole file in cache even). Most of the reason is just that excel is not very well optimized for dealing with large amounts of data and is bogged down by 30 years of legacy code under the hood.But yes every synthetic benchmark has a bias towards something. Not everyone uses a computer to do the same thing. There is nothing that makes Cinebench particularly superior to other benchmarks, but its workload of raytracing on CPU is still a pretty well-balanced load that stresses all of the modern CPUs functionality. It involves a good deal of math computation for all those vectors, it involves heavily branching code that tests the pipelines agility, it consumes a fair bit of RAM bandwidth due to the size of data, it's easily parallelizable so that it can make use of pretty much any number of cores... etc So this means it includes most things that CPU heavy applications would need and so the resulting score number is a reasonably good indicator of overall performance.These benchmarks are very useful when you are deciding to buy your next CPU. It is an easily comparable number to let you find the best CPU for your available budget. It also lets you see how viable upgrading your computer might be. Sure Intel has been cranking out generation after generation of improved CPUs, but when looking at the benchmarks you can see that i7 made some big leaps in performance from Gen 1 2 3 4 but then AMD disappeared and generations 5 6 7 8 9 10 barely made small improvements. So one would expect going from 4th gen to 10th gen would be a massive jump, but its actually not really when looking at benchmarks, so you might decide to stick with the trusty 4th gen until something better comes around to make the investment into a new PC worth while.

author: tooki
author_rank: Super Contributor
timestamp: November 22, 2020, 10:36:44 am
content: Quote from: Berni on November 22, 2020, 09:03:34 amFor sure. Over the years they've increased the sizes of data sets it can work with, but it definitely doesn't mean it's optimized for them. (This is also the one area where 64-bit Office actually makes a difference, supposedly.)Since I really only use Excel to do things like BOMs and other such non-number-crunchy data, it's not something I've ever had to wrestle with!Quote from: Berni on November 22, 2020, 09:03:34 amExactly!There isn't one benchmark that can make everyone happy, since that's literally impossible, given people's competing needs. But few everyday tasks can actually push a modern system anywhere close to its limits.As for parallelization: this is a point I think most people don't really understand. I don't think most people realize that for most tasks, it's single-core performance that matters, since a) not all things can be parallelized, and b) parallelizing code isfucking hardto get right. (I think it's actually something most developers are not capable of doing well.) For everyday things, going from a single core to dual core made a big difference, since the second core could handle OS housekeeping while leaving a whole CPU core to the user app. But every core beyond two delivers only insignificant performance increases for everyday apps whose performance is ultimately bound by one thread, even if some things are offloaded to separate threads (like video playback, or indexing, etc).

author: bd139
author_rank: Super Contributor
timestamp: November 22, 2020, 10:40:42 am
content: Using excel as a hammer is not recommended

author: SilverSolder
author_rank: Super Contributor
timestamp: November 22, 2020, 01:28:19 pm
content: Quote from: tooki on November 22, 2020, 10:36:44 amIn general, I would agree that 4 cores is probably plenty for most people's workloads.For those apps that do benefit from multi-threading (e.g. circuit sims, heavy Photoshop filters, video editing, compression/backup, and so on) I think developers generally do understand what they are doing, and they do make good use of whatever cores you have. So there is a significant subset of people for whom more cores (and speed too - both at the same time!) makes a big difference.

author: DiTBho
author_rank: Super Contributor
timestamp: November 22, 2020, 01:29:15 pm
content: how do these cores operates regarding the bus to the GPU and other units? is there a shared -Three-state logic- bus, or a cross-matrix based bus? or something different?

author: bd139
author_rank: Super Contributor
timestamp: November 22, 2020, 01:34:36 pm
content: Don’t think there’s any info on that yet. Either way the GPU and CPU are in competition for memory access so you’re never going to get anywhere near half decent performance out of this architecture.

author: Cerebus
author_rank: Super Contributor
timestamp: November 22, 2020, 02:49:57 pm
content: Quote from: DiTBho on November 22, 2020, 01:29:15 pmApple's own, very sketchy, marketing diagram shows a switch fabric connecting all the subsystems:

author: tooki
author_rank: Super Contributor
timestamp: November 22, 2020, 06:59:23 pm
content: Quote from: SilverSolder on November 22, 2020, 01:28:19 pmThose are all things that are trivial to parallelize, which is why people are used to seeing things like that be multithreaded.But scores of apps thatwouldbenefit from multithreading end up being CPU-bound by a single thread that gets bogged down running the show, because so many developersdon'tknow how to architect software that doesn't get held up in the main thread somewhere. (Note that I'm not a developer. I studied IT, and so I am well familiar with requirements engineering, software development life cycles, etc., but actual coding isn't my thing. So I'm expresslynotclaiming to know how to do advanced multithreading myself.)Anyhow, it takes rare talent to be able to really break down complex, interactive applications into threads that can run without waiting for each other, while ensuring data concurrency (one of the big reasons devs avoid multithreading). Unsurprisingly, another area where data concurrency is central is also one most developers plain and simply suck at: data synchronization. I suspect another reason devs love cloud-based software is because it avoids them having to worry about syncing desktop clients later.

author: brucehoult
author_rank: Super Contributor
timestamp: November 22, 2020, 09:59:35 pm
content: I promised some results of my M1 Mac testing so here you go.Early days yet, but very different (open-source programmer oriented) tests than you'll find elsewhere. Includes building serious open-source software (binutils, gcc, gdb, newlib). Includes arm64 Ubuntu in a VM.http://hoult.org/arm64_mini.htmlOngoing. Not everything works with the combination of MacOS AND arm64 yet. Will add more tests. Suggestions welcome if not too difficult to do.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 22, 2020, 10:00:59 pm
content: Quote from: tooki on November 22, 2020, 06:59:23 pmI'm sure they exist, but I'm struggling to think of an example of an application that could use multithreading, where it hasn't already been done?

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 23, 2020, 09:02:07 am
content: Quote from: brucehoult on November 21, 2020, 09:17:49 pmWhat do you use for x86 VM on Mini M1?Looks like Wine support M1 , but not yet VMware Fusionhttps://www.codeweavers.com/blog/jwhite/2020/11/18/okay-im-on-the-bandwagon-apple-silicon-is-officially-coolI'm keen to update my 7 years old 13" retina to M1, but Windows VM is must be

author: DiTBho
author_rank: Super Contributor
timestamp: November 23, 2020, 09:52:47 am
content: I'd like to buy a MBP/M1 for Finalcut, but I am not sure about this choice

author: tszaboo
author_rank: Super Contributor
timestamp: November 23, 2020, 10:20:13 am
content: Quote from: tooki on November 22, 2020, 06:59:23 pm(at least a few years ago) One of these problems was FPGA implementation (No, it is not called compiling), that has so many branches in the code, that they are single threaded. And the code is pretty complicated, and the companies are much more concerned about using the FPGA resources optimally, that the time and money of implementation is not worth it.

author: brucehoult
author_rank: Super Contributor
timestamp: November 23, 2020, 10:30:49 am
content: Quote from: olkipukki on November 23, 2020, 09:02:07 amJust the built in Rosetta, emulating x86_64 MacOS apps.

author: brucehoult
author_rank: Super Contributor
timestamp: November 24, 2020, 02:02:15 am
content: Does anyone have any tests they'd like run on the M1, and in particular source code? MacOS or Ubuntu code ...

author: Berni
author_rank: Super Contributor
timestamp: November 24, 2020, 06:04:49 am
content: Well apple has also been making claims of "Worlds fastest integrated GPU"So it might be interesting to run some OpenGL and OpenCL benchmarks and see how it compares to Intel and AMDs integrated GPU solutions. Perhaps also while running a RAM bandwidth stress test at the same time to see what effect the shared CPU/GPU RAM has.

author: brucehoult
author_rank: Super Contributor
timestamp: November 24, 2020, 07:13:15 am
content: Quote from: Berni on November 24, 2020, 06:04:49 amIf you want something then you need to give me a ready prepared project not a general suggestion in something I have no interest in :-)Also, the machine is headless and I'm using it via mostly ssh, with a little VNC when necessary.*Every* review site in the world is covering video and gaming performance. That's not my thing. At all.I'm currently playing around with the hypervisor framework, with a view to making a sandboxed environment that runs apps, and maybe the whole OS, for a non-ARM non-x86 ISA using dynamic code translation of my own design.

author: borjam
author_rank: Unknown
timestamp: November 24, 2020, 07:34:12 am
content: Quote from: tooki on November 21, 2020, 10:29:16 pmYou mean peecee benchmarks on the typical glossy magazines.Peecees are computers, not all computers are peecees.

author: borjam
author_rank: Unknown
timestamp: November 24, 2020, 07:35:58 am
content: Quote from: Berni on November 24, 2020, 06:04:49 amSomething like this?https://barefeats.com/m1-macbook-pro-versus-intel-egpu.htmlhttps://barefeats.com/m1-macbook-pro-versus-intel-version.html

author: bd139
author_rank: Super Contributor
timestamp: November 24, 2020, 07:49:53 am
content: Interesting anecdata point to add. A friend of mine bought a bottom end 8gb M1 mini to replace his 8th gen i5 mini with 16gb ram. Side by side it’s faster, more responsive and runs cold unlike the i5. I had an i3 one myself and that thing ran burning hot all the time. So there’s a longevity improvement there in theory but bang goes the coffee warmerI’m tempted to buy one and play with it. Apple stuff depreciates so little that it’s not much of a risk.

author: borjam
author_rank: Unknown
timestamp: November 24, 2020, 10:36:31 am
content: And what's the memory bandwidth? Seems it has a huge SoC with CPU, GPU and RAM.

author: brucehoult
author_rank: Super Contributor
timestamp: November 24, 2020, 11:10:51 am
content: Quote from: borjam on November 24, 2020, 10:36:31 amNovabench give 41975 MB/sec running as an x86 app under Rosetta.

author: JPortici
author_rank: Super Contributor
timestamp: November 24, 2020, 11:16:43 am
content: Quote from: bd139 on November 24, 2020, 07:49:53 amMe too, i'll seriously consider one when my current NUC will kaput (corrupted bios on the previous one right after warranty epxired, but intel was kind enough to replace it anyway)Performance is the same, price is more or less the same once you add the SSD and RAM.I'll lose native windowsfor now, but hey by that time there will probably be a build, or parallels fully working

author: tszaboo
author_rank: Super Contributor
timestamp: November 24, 2020, 11:26:21 am
content: https://www.techpowerup.com/275102/alleged-apple-m1x-processor-specifications-surfaceQuoteWell, if that's true, it should be quite fast.

author: bd139
author_rank: Super Contributor
timestamp: November 24, 2020, 11:37:01 am
content: Saw this. The leaker is not well respected and generally throws shit at the wall and some of it sticks because it's logical not because it's correct information. It is feasible though.Regarding the earlier network leak issues, I've seen a full review on Big Sur now and the pf firewall and system-wide VPNs are still effective. The issue is the filter API they added (NEFilterDataProvider) is bypassed by Apple applications as there is a genuine mistake in the policy for these which is apparently going to be fixed in the next Big Sur release. Apparently under MDM control you can specify per-application VPNs but the policy is incorrectly set by default. The issue may or may not be intentional and is feasible that it missed testing or they thought it was sensible (to some degree - think MITM apple services) but they got buggered hard for it.

author: DiTBho
author_rank: Super Contributor
timestamp: November 24, 2020, 12:15:49 pm
content: According to some random benchmarks on the web, it seems the new M1 is getting some gain (4X? really?) with Final Cut, which definitely sounds a good point to buy a new MAC-M1 for January 2021; there is and there will never be anything like BootCamp, but Parallels is getting ready with a new release for the new year able to "run" Windows 10 in a (x86 emulated) "Fusion Box" (that's amazing!), Microsoft is thinking about releasing a Windows10/M1 version (will it happen? won't it happen? who knows ...(1)), and yesterday Linus Torvalds said he wants an Apple-M1 laptop running Linux (will it happen with kernel v6? I wonder).edit:(1) Microsoft has *already* released a Universal build, containing x86_64 and ARM64 binaries, of its Mac Office 2019 beta, but there's not yet an M1-native general release of Office, and the code editor Visual Studio Code has an experimental ARM64 build, with a Universal build planned for the end of this month.Will Microsoft just provide "applications" for Apple/M1, or will they also release an OS for M1? That's precisely what I wonder.

author: bd139
author_rank: Super Contributor
timestamp: November 24, 2020, 12:19:49 pm
content: Linux port is likely going to be blocked on peripherals, particularly GPU driver I reckon. I bet we'll see a headless box with ethernet up fairly quickly and then it'll stall.The final cut performance is because it has dedicated encoder / decoder hardware. That's a good thing!

author: DiTBho
author_rank: Super Contributor
timestamp: November 24, 2020, 12:35:39 pm
content: Quote from: bd139 on November 24, 2020, 12:19:49 pmProbably. However, what makes me thinking, is that Apple has already made it clear they won’t be blocking you from installing other OSs.So ... Sweet dreams are made of this, who am I to disagree?

author: dr.diesel
author_rank: Super Contributor
timestamp: November 24, 2020, 12:39:51 pm
content: Quote from: DiTBho on November 24, 2020, 12:35:39 pmWow really? I expected Apple to lock it down hard, very interesting... Hope this holds true with the up and coming higher performance chips.

author: bd139
author_rank: Super Contributor
timestamp: November 24, 2020, 12:42:05 pm
content: Yeah it's true. They aren't blocking third party OS installations. Confirmed already. In fact they said "it's entire up to microsoft if they want to run windows on it" (while Craig is going bwuhahahaha while taking off his human skin suit)It's a matter of motivation and time now. I wonder if anything useful will appear in:https://opensource.apple.com/

author: bd139
author_rank: Super Contributor
timestamp: November 24, 2020, 02:42:48 pm
content: Well I bought an ass end M1 mac mini. Arriving Thursday from Amazon. Have someone lined up to buy it off me for £650 if I'm not happy with it already

author: Mr. Scram
author_rank: Super Contributor
timestamp: November 24, 2020, 05:21:58 pm
content: Quote from: bd139 on November 24, 2020, 02:42:48 pmMake up your mind!

author: tooki
author_rank: Super Contributor
timestamp: November 24, 2020, 05:27:58 pm
content: Quote from: dr.diesel on November 24, 2020, 12:39:51 pmIt’s not surprising to people who actually know Apple, rather than “know” the stereotype of Apple from sensationalist media or from people who haven’t actually given Apple a fair chance. :/

author: bd139
author_rank: Super Contributor
timestamp: November 24, 2020, 05:32:55 pm
content: Quote from: Mr. Scram on November 24, 2020, 05:21:58 pmI have nothing else to do at the moment so need something to piss around with

author: bd139
author_rank: Super Contributor
timestamp: November 24, 2020, 05:33:29 pm
content: Quote from: tooki on November 24, 2020, 05:27:58 pmTo be fair this does blur the lines between their iOS SoC's and desktops so it was a perfectly valid concern.

author: tooki
author_rank: Super Contributor
timestamp: November 24, 2020, 07:05:19 pm
content: Quote from: bd139 on November 24, 2020, 05:33:29 pmBut being locked down (or not) has nothing to do with the choice of CPU/SoC. If Apple had wanted Macs to be locked down like iPhones and iPads, they could have done so with Intel CPUs. Conversely, iPhones have been locked down right from day 1, and they weren’t using custom Apple SoCs back then.

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 24, 2020, 07:47:27 pm
content: Quote from: brucehoult on November 22, 2020, 09:59:35 pmA bit of exotic with default and tuned(SME/SEV/SMT=off, BOOST=On, Determinism Slider=Performance)settingscat /proc/cpuinfomodel name : AMD EPYC 7551P 32-Core Processor1. Perl Summing Numbers Benchmarkdefault / tunedreal 0m0.083s / 0m0.075suser 0m0.078s / 0m0.074ssys 0m0.004s / 0m0.001s2. Primes Benchmarkgcc -O -o primes primes.c./primesdefault result:Starting run3713160 primes found in 4553 ms244 bytes of code in countPrimes()tuned result:Starting run3713160 primes found in 4536 ms244 bytes of code in countPrimes()3. Building the RISC-V toolchaindefault / tunedreal 14m44.759s / 11m55.438suser 103m4.967s / 73m23.795ssys 15m40.658s / 9m1.816sOS: SUSE SLED 15 SP2

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 24, 2020, 07:53:42 pm
content: Quote from: bd139 on November 24, 2020, 02:42:48 pmA bit early to open an champagnie, make sure they didn't send i3

author: bd139
author_rank: Super Contributor
timestamp: November 24, 2020, 08:22:01 pm
content: I actually used an i3 mini as my main desktop for a bit. Not as slow as i thought it was going to be but it ran stupid hot.

author: brucehoult
author_rank: Super Contributor
timestamp: November 24, 2020, 09:14:16 pm
content: Quote from: NANDBlog on November 24, 2020, 11:26:21 amI guarantee this guy knows nothing.Everyone in the world with a brain knows the M1 isn't the last or the best chip Apple will make. They've *said* they're transitioning the entire Mac line to their own chips over the next two years. They wouldn't say that if they didn't have chips suitable for them in the works. QED

author: brucehoult
author_rank: Super Contributor
timestamp: November 24, 2020, 09:32:00 pm
content: Quote from: olkipukki on November 24, 2020, 07:47:27 pmCool!Interesting the gains they made from one year extra development from 7551P to 2990wx.It's really close on the perl test, but significantly slower on the others, even after the tuning.What annoys me is the 12 and 16 core 5900X / 5950X now match or blow away my 1st gen Threadripper at much lower cost. My consolation is I got a couple of years use out of it first. And it's dependable. Even if it's 20% slower than the latest thing on some test, you can just keep throwing more and more stuff at it.Thanks for your effort!

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 24, 2020, 10:07:30 pm
content: Quote from: brucehoult on November 24, 2020, 09:32:00 pmHow come? epyc-tuned and your ripper is really close to each other on the build test, that's surprised me... or am I'm looking 'wrong' numbers?Don't forget this EPYC max 2.55GHz only for all cores (and a single up to 3GHz)Quote from: brucehoult on November 24, 2020, 09:32:00 pmMy desktop Ryzen 3600X easily beat this EPYC on single-threads/user interactive apps... and I don't need to look on passmark single thread performance benchmarks, although a ratio between is almost true there.If I paid RRP for 7551P, I pulled all my hair out by nowTBH, glad to see that Apple M1 performs quite well

author: brucehoult
author_rank: Super Contributor
timestamp: November 24, 2020, 11:27:12 pm
content: Quote from: olkipukki on November 24, 2020, 10:07:30 pmIt's still 10% slower10m51s vs 11m55s.The 2990wx is 3.0 GHz base. lscpu gives readings all over the place for it. When it's running the ./configure parts it's around 2.1-2.2 (IO limited I guess), When there are a lot of cc1's running it seems to be about 3.2.I think the EPYC may have a better RAM system?QuoteBetween AMD's latest and Apple, we're in for some interesting times in desktop/server land in the next few years.

author: AntiProtonBoy
author_rank: Frequent Contributor
timestamp: November 25, 2020, 06:46:31 am
content: Quote from: brucehoult on November 24, 2020, 11:27:12 pmI reckon AMD is going to pull a few tricks out of the hat. Meanwhile Intel is shitting its bed.

author: bd139
author_rank: Super Contributor
timestamp: November 25, 2020, 07:29:31 am
content: I don’t think Intel are crapping themselves yet. They’re still the only major supplier which hasn’t got supply problems and can fulfil orders for the large OEM builders. Can’t sell Ryzen if you can’t make them quick enough and M1 cores are not offered to other OEMs.

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 25, 2020, 09:16:34 am
content: Quote from: brucehoult on November 24, 2020, 11:27:12 pm10% diff is nothing... EPYC 7551P has 2GHz baseI guess if you turn off HT and Virtualisation settings in BIOS, your ripper might perform better than nowQuote from: brucehoult on November 24, 2020, 11:27:12 pmYes, indeed, 2x memory bandwidth compare to the ripper and the system fully filled with 2666 DIMMs, but imho - irrelevant/nonsignificant for the current test cases, you can see above results before and after tunning.Not sure if you can apply on non-epyc cpushttp://developer.amd.com/wp-content/resources/56420.pdfQuote from: brucehoult on November 24, 2020, 11:27:12 pmIf keep same analogy, M1 like Ryzen 1.Hopefully Apple will figure out how to increase a screen to 14" in the 13" macbookpro case in the next iterationor introduce something like Mac Pro Lite with M2+

author: wizard69
author_rank: Super Contributor
timestamp: November 26, 2020, 05:26:49 am
content: Thanks for the post & performance benchmarks. I just got a MBA and have been installing from Mac Ports. So far it has been a mixed bag (kinda expected) with some stuff not compiling.I'm actually very pleased with this machine, it literally performs better than any laptop that I've owned personally or at work. After just reading a good portion of this thread I suspect that many are woefully underestimating just what Apple has achieved with M1.Quote from: brucehoult on November 22, 2020, 09:59:35 pm

author: wizard69
author_rank: Super Contributor
timestamp: November 26, 2020, 06:01:14 am
content: Hi Guys; Just started reading this thread about an hour ago. I picked up a Mac Book Air a couple of days ago and hope to have a lot of free time with it on the holiday! So far though this MBA has really impressed me and for the most part is living up to my expectations.For those not familiar the MBA series is Apples LOWEST end laptop and thus has never been a performance champ. With the M1 chip in this machine that is an entirely different story as the machine is snappy from the users stand point. I don't think Apple is being dishonest when they compare these machines to higher end solutions. This is a passively cooled machine that can compete with machines that could never run passively cooled.A little background, between work and home I've used or owned a number of laptops over the years. The last one I personally owned died over a year an a half ago and frankly I got pissed off with the high cost of laptops (to get decent performance) and the short life spans, this resulted in a new Linux desktop build. Ever since that HP died I've been looking for an ARM based laptop done right. Why ARM - long battery life, a laptop with an advertised 4 hours of life on battery that dies after 2 is useless to me.So whom decides to lead the industry to ARM, good old Apple. This is not a crap low performance machine even if it is Apples introductory model. It also meets my #1 criteria which is good life on battery plus it can run Python no problem so I have no issue there. I already have a desktop so travel is an important element in this machines usage, considering that it can run off USB-C charging it anywhere should not be an issue. For me it is a much better solution for travel than a tablet, that mainly due to having a real file browser and access to the file structure.I hope that this doesn't sound too much like an advertisement but I'm trying to get across why I went out and purchased this machine. I haven't tried to do much benchmarking yet as that has never been my thing.If any one has questions please ask. I'm by no means an expert when it comes to a Mac so take that into mind.

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 26, 2020, 08:20:39 am
content: As per below test, M1 performs quite well taking into account these apps not yet optimized!https://www.pugetsystems.com/labs/articles/Apple-M1-MacBook-vs-PC-Desktop-Workstation-for-Adobe-Creative-Cloud-1975/P.S.Not sure why they compared high-end Ryzens and didn't include Intel macbooks into the comparison...

author: bd139
author_rank: Super Contributor
timestamp: November 26, 2020, 08:29:58 am
content: Probably because it’s embarrassing.My M1 mini is out for delivery today. Decided to avoid apple keyboards this time so grabbed some mac key caps for my existing one.

author: Berni
author_rank: Super Contributor
timestamp: November 26, 2020, 08:39:16 am
content: Well Pudget Systems is in the business of selling PCs so they probably wanted to make there prebuilt PC look good, so they used latest gen Ryzen since those are the fastest x86 out there right now.But they do also point out in the article that both Macs perform about the same as a Intel Core i5 8600 or Intel Core i7 6700khttps://www.pugetsystems.com/benchmarks/view.php?id=16278None the less these are comparisons to desktop CPUs that have massive TDPs at there disposal so its not quite a completely fair comparison.

author: Zucca
author_rank: Unknown
timestamp: November 26, 2020, 12:55:05 pm
content: Quote from: bd139 on November 26, 2020, 08:29:58 amdoes it run FreeBSD on it?

author: bd139
author_rank: Super Contributor
timestamp: November 26, 2020, 01:05:24 pm
content: Notyet

author: DiTBho
author_rank: Super Contributor
timestamp: November 26, 2020, 02:01:39 pm
content: Personally, I would like to see and use Haiku (~BeOS) on a Bookair/M1! It's my secret dream

author: bd139
author_rank: Super Contributor
timestamp: November 26, 2020, 04:22:17 pm
content: It arrived. Not going to get to play with it for a couple of hours yet

author: Cerebus
author_rank: Super Contributor
timestamp: November 26, 2020, 05:34:04 pm
content: Quote from: bd139 on November 26, 2020, 04:22:17 pm020 8744 2211 and damn balanced nutrition for the kids.

author: bd139
author_rank: Super Contributor
timestamp: November 26, 2020, 05:35:44 pm
content: Hahaha. In preparation I already had a kebab for lunch and they're self serving oven pizzasProblem is a conference call which I'm still on now

author: Mr. Scram
author_rank: Super Contributor
timestamp: November 26, 2020, 07:36:53 pm
content: Quote from: Berni on November 26, 2020, 08:39:16 amThe same could be said for comparing the tightly knit Apple ecosystem and technology to more generic computers. By controlling both hardware and software you can optimise and integrate a lot more. It's never going to be a fair comparison either way.

author: Mr. Scram
author_rank: Super Contributor
timestamp: November 26, 2020, 07:38:10 pm
content: Quote from: bd139 on November 26, 2020, 05:35:44 pmI thought you of all people would have a loopable sound file with roughly appropriate ahs and ums.

author: bd139
author_rank: Super Contributor
timestamp: November 26, 2020, 10:12:01 pm
content: Well that call overran until nearly 7pm. And it was mostly complaining loudly about a gigantic shit show!I'm using it now and it's notably faster than the i3 Mac mini I had before, which I expect. Also it's always cold to the touch unlike the i3 which was actually uncomfortable if you annoyed it. I haven't done any benchmarks or compilation yet. Mostly been arguing with keyboard setup, turning all the shit bits of macOS off and getting the important bits working (Apple Music etc).So far so good. It's nice to be using a Mac with proper keyboard though. The Mac chiclet keyboards are quite frankly dire things.I'll do some more objective tests and comparisons to my other desktop over the next few days. I have a couple of mega sized C# things to throw at them both and it looks like there is CoreCLR runtime preview for native machine architecture is sort of working.It's currently installing Xcode / compiler tools.

author: brucehoult
author_rank: Super Contributor
timestamp: November 26, 2020, 11:10:11 pm
content: Quote from: Zucca on November 26, 2020, 12:55:05 pmIn a VM, sure.Apple seems to be saying it's ok to run other OSes on them -- they said "it's up to Microsoft" whether Windows will run on it -- but at the same time there doesn't seem to be documentation of how to do it and no one has figured it out independently.On the other hand Apple provides as standard a hypervisor framework (low level -- you just get a memory range and EL0 and EL0 privs for code, and handle EL2 calls in your driver loop) and a Virtual Machine framework (high level, with virtio already implemented for you).

author: bd139
author_rank: Super Contributor
timestamp: November 26, 2020, 11:20:46 pm
content: Ok a few hours in now and the UI latency is definitely down compared to any Intel Mac I've used. Their assertion is that this is due to higher performance of retain/release operations in their reference counter. I can believe that. I think so far that the majority of the observable rather than measurable performance improvements may come from that."zippy" is the word I'm giving it now. Also it has been running ffmpeg for 10 minutes (I haven't compared it to my Ryzen on this file yet) and it is still freezing cold to the touch.

author: borjam
author_rank: Unknown
timestamp: November 27, 2020, 06:50:37 am
content: Quote from: brucehoult on November 26, 2020, 11:10:11 pmDocumentation, that long lost art!I guess they will still be open sourcing Darwin.

author: bd139
author_rank: Super Contributor
timestamp: November 27, 2020, 08:28:04 am
content: Ok so first Rosetta 2 application installed this morning: MS Remote Desktop. No issues. Seems extremely quick.

author: Marco
author_rank: Super Contributor
timestamp: November 27, 2020, 05:09:31 pm
content: Ryzen 4800U is currently the fairest x86 to compare against and that is a node behind ...Apple's huge volume and margins make it kinda hard for anyone to compete for fab space.

author: bd139
author_rank: Super Contributor
timestamp: November 27, 2020, 05:38:53 pm
content: Ok just signed out. Did a full day of work on it. Mostly RDP / zoomSo far no hard figures but some points:1. I noticed absolutely no lag or performance issues. It's smooth as butter.2. Runs ice cold. I just stuffed 75 gig of stuff into Photos app. On the old i3 minis they got burning hot doing this. This isn't even warm to the touch.3. Runs silent. Despite being actively cooled it's not audible at all even under heavy load.4. Zoom and MS RDP client were used most of the day, both x86 so Rosetta dependent. No issues.5. Idle power is 5W. Peak under load was 20W (!)I've got mine plugged into a 27" 4k screen so it feels like you're using an i9 + SSD equipped 27" iMac with a crap ton of RAM in it. But it's literally bottom end hardware.xcode + toolchain currently installing.The only bad bit I have found is the HDMI connector is a bit dicky. If you nudge it, it drops out. I've used two different cables and it is repeatable across both. That's being replaced with a USB-C to displayport cable tomorrow when it turns up so I'm not that bothered about it. HDMI has always been complete ballsack of a standard and connectors.Edit: plus it's rather nice looking, better than the old space grey ones.

author: nfmax
author_rank: Super Contributor
timestamp: November 27, 2020, 05:57:00 pm
content: Quote from: bd139 on November 27, 2020, 05:38:53 pmI would make a warranty claim to Apple about it. That way:You get a new computer with a connector that won't drive you crazy each time you forget why you weren't using itApple are made aware of a build quality issueYour M1 mini will eventually make its way into the refurb store, where cheapskates like me will be able to pick it up in few month's timeTying this on arefurb2018 Mini (3.2GHz 6-Core i7, 32GB RAM, 1TB SSD), which is actually not bad at all

author: brucehoult
author_rank: Super Contributor
timestamp: November 27, 2020, 10:04:37 pm
content: Quote from: Marco on November 27, 2020, 05:09:31 pmThe 4800U has effectively twice the number of cores. The small cores on the M1 are worth about the same for performance as HT is worth on Intel/AMD. I felt bad enough pitting my 4500U machine against the M1 -- which won by 31% on the software build benchmark anyway without even using the small cores.QuoteThis is of course not the customer's concern.Benchmark sites show the M1 beating the 4500U on Cinebench R23 multi-core by 7760 to 5620, but losing to the 4800U's 10156.From a customer's perspective, if you can buy a machine with a 4800U for the same price as a machine with an M1 and you mostly care about multi-threaded tasks and you are OS-agnostic then you should get the 4800U. If your tasks are more single-threaded then the M1 is still faster.

author: magic
author_rank: Super Contributor
timestamp: November 28, 2020, 08:43:33 am
content: This chip is surprisingly decent and it looks like it could spell trouble for x86 if it can be scaled to higher TDP - crank up the clocks, double / quadruple the cores, etc.You mentioned it's supposed to have peak throughput of 8 IPC. Are there any tools on OSX to measure it and see if it really makes a difference? From your experience designing CPUs / optimizing software / whatever you did (I suppose), where do you think may be the point of diminishing returns where going to a wider core just ceases making sense anymore?

author: nfmax
author_rank: Super Contributor
timestamp: November 28, 2020, 09:19:07 am
content: Perhaps the most interesting thing is that the new M1 Macs arecheaperthan the corresponding Intel-based machines they replace, as well as outperforming them and being lower-powered. I suspect part of Apple's motivation was to avoid paying the 'Intel tax'.Hopefully this will persuade Intel to up their game. They seem to have lapsed into the 'Soviet Weightlifter Syndrome' - breaking new (speed) records every year, but never by too much, as there is no percentage in that. Well there is now.

author: bd139
author_rank: Super Contributor
timestamp: November 28, 2020, 10:20:41 am
content: Yeah they are pretty cheap. I got discount and cash back on this mini so I paid £630 for it in the end. A comparable NUC is actually £70 more and not half as good.

author: brucehoult
author_rank: Super Contributor
timestamp: November 28, 2020, 11:10:33 am
content: Quote from: magic on November 28, 2020, 08:43:33 am8 IPC is not achievable on typical software, even with perfect branch predition.I think it's useful on "inefficient" software such as that generated by JIT compilers, or languages which are doing bounds checking or reference count updating in parallel with the actual useful instructions.

author: SilverSolder
author_rank: Super Contributor
timestamp: November 28, 2020, 01:34:30 pm
content: Quote from: nfmax on November 28, 2020, 09:19:07 amAs consumers, I guess we now have a wider choice... Intel tax, Apple tax, or AMD tax!

author: bd139
author_rank: Super Contributor
timestamp: November 28, 2020, 01:44:13 pm
content: Don’t forget the Google tax where they sell you a substandard product and fail to support it too!Quick compiler update. Working on getting .net core CLR compiled on it. Looks like Microsoft are way behind the curve. Nowhere near ready even under RosettaEdit: golang works under Rosetta and seems about the same speed as my ryzen single threaded on compiler performance.

author: nfmax
author_rank: Super Contributor
timestamp: November 28, 2020, 03:23:14 pm
content: Quote from: brucehoult on November 28, 2020, 11:10:33 amWhere did you get 8IPC from? I read it can (most likely) decode 8 instructions simultaneously, increasing the number of options available to the instruction reordering unit to dispatch to the various execution pipelines. This is not the same as dispatching 8 instructions per clock cycle

author: magic
author_rank: Super Contributor
timestamp: November 28, 2020, 05:56:23 pm
content: High performance CPUs have plenty of execution resources, I suppose a machine with 8-wide decode should be able to get close to that on the backend too.According to AMD, Zen can dispatch up to 10 µops in one cycle, and these are similar to RISC instructions. Of course they cannot be completely arbitrary µops, there isn't enough execution unit duplication for that, but an appropriate mix of pending instructions of different kinds could execute like that.

author: Marco
author_rank: Super Contributor
timestamp: November 28, 2020, 06:09:25 pm
content: Quote from: brucehoult on November 27, 2020, 10:04:37 pmRoughly the same size though, taking into account the node difference. Also IPC being such an enormously diminishing returns game, those little cores are far from useless if they aren't clock restricted.

author: magic
author_rank: Super Contributor
timestamp: November 28, 2020, 09:10:34 pm
content: Here's some details about (apparently - I'm not familiar with ARM stuff) the most advanced core publicly unveiled by ARM to date:https://fuse.wikichip.org/news/3543/arm-cortex-x1-the-first-from-the-cortex-x-custom-program/It looks very similar to x86 stuff, even with pre-decoding into macro-ops and a dedicated macro-op cache. They say it can optimistically issue and retire up to 8 instructions in one cycle when running from the MOP cache.

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 28, 2020, 11:03:06 pm
content: Nobody yet mentioned a storage controller and SSD performanceHow it looks compare to 'old' world?

author: bd139
author_rank: Super Contributor
timestamp: November 28, 2020, 11:18:08 pm
content: About the same to be honest. 2100MB/s write, 2706MB/s read

author: tooki
author_rank: Super Contributor
timestamp: November 29, 2020, 05:01:20 pm
content: Quote from: bd139 on November 28, 2020, 11:18:08 pmDepends on what you're comparing.Arstechnica's reviewof the M1 MacBook Air (tested with 1TB SSD), as tested with Blackmagic disk speed test, shows the M1 Macbook Air having R/W of 3101/2707 MB/sec, vs. 2265/2024 for a 2020 Intel MacBook Pro and 1262/1281 for a 2020 Intel MacBook Air.

author: bd139
author_rank: Super Contributor
timestamp: November 29, 2020, 05:27:13 pm
content: Have attached my actual measurements this time.

author: DiTBho
author_rank: Super Contributor
timestamp: November 29, 2020, 05:30:15 pm
content: Quote from: bd139 on November 28, 2020, 11:18:08 pmWhen people says "old", well ... "old" for me means 60Mbyte/sec, two order of magnitudes slower, hence I would for sure appreciate the speedup

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 29, 2020, 09:30:58 pm
content: 60Mbyte is in a vintage categorywhen you are not in the rush and appreciate Sound of Hard Drive

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 29, 2020, 09:42:59 pm
content: Quote from: bd139 on November 29, 2020, 05:27:13 pmIs yours one 256GB?P.S.I'm expecting to triple your measurements when 980 Pro 1TB will come into a house

author: olkipukki
author_rank: Frequent Contributor
timestamp: November 29, 2020, 09:46:56 pm
content: Quote from: tooki on November 29, 2020, 05:01:20 pmIndeed, Air M1 is a real winner here.Not sure what is a reason to buy M1 pro 13" right now, a bit better screen?!

author: tooki
author_rank: Super Contributor
timestamp: November 29, 2020, 09:57:00 pm
content: Quote from: olkipukki on November 29, 2020, 09:46:56 pmThe Air has no fan, so will begin to thermally throttle under sustained high load. Macbook Pro and Mac mini have a small fan and can sustain maximum performance indefinitely.

author: bd139
author_rank: Super Contributor
timestamp: November 29, 2020, 10:35:42 pm
content: Quote from: olkipukki on November 29, 2020, 09:42:59 pmYeah. I’ve got a 1TB 970 pro here in my Windows box. Will test that tomorrow.

author: NiHaoMike
author_rank: Super Contributor
timestamp: November 30, 2020, 12:20:26 am
content: Quote from: DiTBho on November 29, 2020, 05:30:15 pmThe only HDDs 1TB and above I'm aware of with a sequential speed less than 60MB/s are the SMR "cost optimized" ones.

author: Berni
author_rank: Super Contributor
timestamp: November 30, 2020, 06:55:20 am
content: 2GB/s and up sequential speeds are pretty much the norm thee days for decent NVME SSDs. The more difficult numbers to keep up is random access with a single queue, these are also what makes a SSD so snappy. You can get 2 GB/s sequential speeds out of a big enough array of spinning rust, but the random access speeds are going to be in the few MB/s and booting an OS off it will take forever just like one expects from a classical HDD. But once you get to the random access speeds the fastest SSDs are capable of even the driver overhead can have a significant effect.CrystalDiskMark is a good tool that tests both sequential and random access, but its a Windows only thing. I remember getting similar sequential figures running a Windows 7 VM inside KVM on my NAS that keeps the disk image on a M.2 SSD (I think its a Samsung 970 Pro but not sure)

author: magic
author_rank: Super Contributor
timestamp: November 30, 2020, 11:16:18 am
content: Quote from: brucehoult on November 24, 2020, 02:02:15 amCould you try the attached C++ file?It runs several Fibonacci sequences in parallel to 20 million iterations (overflows, I know).It should be compiled with GCC≥8.0 to respect the unroll pragma, which reduces loop counting overhead.My older AMD system with GCC 10 scales linearly to 3 "gigainops"/GHz and then plateaus until it runs out of architectural registers at N=8 and progressively slows down to 1G/GHz (or worse for 16bit).Skylake seems to hit 3~4G/GHz, but I'm not sure how much exactly because of turbo.I tried it on a Cortex A15 too and got 1G/GHz at N=1 and 1.75 at N≥2. It probably could be 2 exactly, but the old-ass GCC 4.5 doesn't unroll the outer loop so some cycles are wasted counting iterations. For whatever reason it also starts to spills registers at N≥4, meh, I hope the 64bit Mac / Ubuntu will be better

author: brucehoult
author_rank: Super Contributor
timestamp: November 30, 2020, 02:29:16 pm
content: ThreadRipper 2990wx (4.2 GHz turbo)Seems to hit 3.33 G/GHz, then plummets==================== 16bit ====================ff1b0mark 10000000*2 iterations 7 paralell... result 3486210.291881 milliseconds 140000000 additions 13.602956 gigainopsf1b0mark 10000000*2 iterations 8 paralell... result 3048020.060230 milliseconds 160000000 additions 7.975980 gigainops==================== 32bit ====================f1b0mark 10000000*2 iterations 7 paralell... result 6473339349.965147 milliseconds 140000000 additions 14.048965 gigainopsf1b0mark 10000000*2 iterations 8 paralell... result 258051048020.051023 milliseconds 160000000 additions 7.979643 gigainops==================== 64bit ====================f1b0mark 10000000*2 iterations 7 paralell... result 24386291221820559829.980738 milliseconds 140000000 additions 14.027019 gigainopsf1b0mark 10000000*2 iterations 8 paralell... result 1596325047800060084819.879080 milliseconds 160000000 additions 8.048662 gigainopsM1 Mac Mini, native ("gcc" is aliased to Apple LLVM), "3.2 GHz".Scales somewhat sublinearly to 18.08 = 5.65 G/GHz at N=8, then continues to increase to 18.51 = 5.75 at N=14, then dropsNo difference 16/32/64 bit so I'll just show 64 bit.==================== 64bit ====================f1b0mark 10000000*2 iterations 1 paralell... result 135246213558185448666.493208 milliseconds 20000000 additions 3.080142 gigainopsf1b0mark 10000000*2 iterations 2 paralell... result 86024986379275381166.491041 milliseconds 40000000 additions 6.162340 gigainopsf1b0mark 10000000*2 iterations 3 paralell... result 36803759200365313666.990208 milliseconds 60000000 additions 8.583436 gigainopsf1b0mark 10000000*2 iterations 4 paralell... result 172049972758550762327.247458 milliseconds 80000000 additions 11.038353 gigainopsf1b0mark 10000000*2 iterations 5 paralell... result 122828745579640694827.923459 milliseconds 100000000 additions 12.620751 gigainopsf1b0mark 10000000*2 iterations 6 paralell... result 73607518400730627328.440000 milliseconds 120000000 additions 14.218009 gigainopsf1b0mark 10000000*2 iterations 7 paralell... result 24386291221820559829.547209 milliseconds 140000000 additions 14.663971 gigainopsf1b0mark 10000000*2 iterations 8 paralell... result 159632504780006008488.864500 milliseconds 160000000 additions 18.049523 gigainopsf1b0mark 10000000*2 iterations 9 paralell... result 1104112776010959409810.047375 milliseconds 180000000 additions 17.915127 gigainopsf1b0mark 10000000*2 iterations 10 paralell... result 611900504221858734811.037625 milliseconds 200000000 additions 18.119840 gigainopsf1b0mark 10000000*2 iterations 11 paralell... result 119688232432758059812.031625 milliseconds 220000000 additions 18.285144 gigainopsf1b0mark 10000000*2 iterations 12 paralell... result 1472150368014612546413.026417 milliseconds 240000000 additions 18.424099 gigainopsf1b0mark 10000000*2 iterations 13 paralell... result 979938096225511871414.066792 milliseconds 260000000 additions 18.483248 gigainopsf1b0mark 10000000*2 iterations 14 paralell... result 487725824436411196415.126333 milliseconds 280000000 additions 18.510765 gigainopsf1b0mark 10000000*2 iterations 15 paralell... result 1840187960018265683036.436875 milliseconds 300000000 additions 8.233417 gigainopsf1b0mark 10000000*2 iterations 16 paralell... result 1347975688229165008038.526250 milliseconds 320000000 additions 8.306025 gigainopsf1b0mark 10000000*2 iterations 17 paralell... result 855763416440064333046.079083 milliseconds 340000000 additions 7.378619 gigainopsf1b0mark 10000000*2 iterations 18 paralell... result 363551144650963658047.268208 milliseconds 360000000 additions 7.616113 gigainopsf1b0mark 10000000*2 iterations 19 paralell... result 1716013280232818144653.159250 milliseconds 380000000 additions 7.148333 gigainopsf1b0mark 10000000*2 iterations 20 paralell... result 1223801008443717469665.569750 milliseconds 400000000 additions 6.100374 gigainopsf1b0mark 10000000*2 iterations 21 paralell... result 731588736654616794673.230417 milliseconds 420000000 additions 5.735322 gigainopsf1b0mark 10000000*2 iterations 22 paralell... result 239376464865516119692.353417 milliseconds 440000000 additions 4.764307 gigainopsf1b0mark 10000000*2 iterations 23 paralell... result 1591838600447370606292.848834 milliseconds 460000000 additions 4.954289 gigainopsf1b0mark 10000000*2 iterations 24 paralell... result 1099626328658269931292.442667 milliseconds 480000000 additions 5.192408 gigainopsf1b0mark 10000000*2 iterations 25 paralell... result 6074140568691692562105.902500 milliseconds 500000000 additions 4.721324 gigainopsf1b0mark 10000000*2 iterations 26 paralell... result 115201785080068581288.753916 milliseconds 520000000 additions 5.858896 gigainopsf1b0mark 10000000*2 iterations 27 paralell... result 1467663920661923067891.677458 milliseconds 540000000 additions 5.890216 gigainopsf1b0mark 10000000*2 iterations 28 paralell... result 975451648872822392892.091333 milliseconds 560000000 additions 6.080920 gigainopsf1b0mark 10000000*2 iterations 29 paralell... result 483239377083721717895.060708 milliseconds 580000000 additions 6.101364 gigainopsf1b0mark 10000000*2 iterations 30 paralell... result 18357015126655762044103.767250 milliseconds 600000000 additions 5.782171 gigainopsf1b0mark 10000000*2 iterations 31 paralell... result 13434892408764755294104.614792 milliseconds 620000000 additions 5.926504 gigainopsf1b0mark 10000000*2 iterations 32 paralell... result 8512769690873748544111.874417 milliseconds 640000000 additions 5.720700 gigainops

author: brucehoult
author_rank: Super Contributor
timestamp: November 30, 2020, 02:48:16 pm
content: Rosetta results are insane. The program actually runs slightly more quickly than native at 4.1 seconds overall vs 4.45 seconds, but the program-internal timings are crazy.Assuming that the clock_gettime() calls do actually work properly, the only explanation that seems to make sense is if Rosetta is compiling each function just in time (which takes a while) but is optimizing the basic blocks. The result values are the same.==================== 64bit ====================f1b0mark 10000000*2 iterations 1 paralell... result 135246213558185448660.152508 milliseconds 20000000 additions 131.140661 gigainopsf1b0mark 10000000*2 iterations 2 paralell... result 86024986379275381160.150378 milliseconds 40000000 additions 265.996356 gigainopsf1b0mark 10000000*2 iterations 3 paralell... result 36803759200365313660.168184 milliseconds 60000000 additions 356.752129 gigainopsf1b0mark 10000000*2 iterations 4 paralell... result 172049972758550762320.175210 milliseconds 80000000 additions 456.594943 gigainopsf1b0mark 10000000*2 iterations 5 paralell... result 122828745579640694820.192716 milliseconds 100000000 additions 518.898275 gigainopsf1b0mark 10000000*2 iterations 6 paralell... result 73607518400730627320.198756 milliseconds 120000000 additions 603.755358 gigainopsf1b0mark 10000000*2 iterations 7 paralell... result 24386291221820559820.485385 milliseconds 140000000 additions 288.430833 gigainopsf1b0mark 10000000*2 iterations 8 paralell... result 159632504780006008480.993580 milliseconds 160000000 additions 161.033837 gigainopsf1b0mark 10000000*2 iterations 9 paralell... result 110411277601095940980.856754 milliseconds 180000000 additions 210.095313 gigainopsf1b0mark 10000000*2 iterations 10 paralell... result 61190050422185873481.048722 milliseconds 200000000 additions 190.708310 gigainopsf1b0mark 10000000*2 iterations 11 paralell... result 11968823243275805981.126819 milliseconds 220000000 additions 195.239874 gigainopsf1b0mark 10000000*2 iterations 12 paralell... result 147215036801461254641.205832 milliseconds 240000000 additions 199.032701 gigainopsf1b0mark 10000000*2 iterations 13 paralell... result 97993809622551187141.190788 milliseconds 260000000 additions 218.342812 gigainopsf1b0mark 10000000*2 iterations 14 paralell... result 48772582443641119641.413808 milliseconds 280000000 additions 198.046694 gigainopsf1b0mark 10000000*2 iterations 15 paralell... result 184018796001826568301.527521 milliseconds 300000000 additions 196.396645 gigainopsf1b0mark 10000000*2 iterations 16 paralell... result 134797568822916500801.671119 milliseconds 320000000 additions 191.488458 gigainopsf1b0mark 10000000*2 iterations 17 paralell... result 85576341644006433301.832372 milliseconds 340000000 additions 185.551842 gigainopsf1b0mark 10000000*2 iterations 18 paralell... result 36355114465096365801.981824 milliseconds 360000000 additions 181.650843 gigainopsf1b0mark 10000000*2 iterations 19 paralell... result 171601328023281814462.217315 milliseconds 380000000 additions 171.378446 gigainopsf1b0mark 10000000*2 iterations 20 paralell... result 122380100844371746962.748137 milliseconds 400000000 additions 145.553151 gigainopsf1b0mark 10000000*2 iterations 21 paralell... result 73158873665461679462.935518 milliseconds 420000000 additions 143.075260 gigainopsf1b0mark 10000000*2 iterations 22 paralell... result 23937646486551611963.353458 milliseconds 440000000 additions 131.207846 gigainopsf1b0mark 10000000*2 iterations 23 paralell... result 159183860044737060622.991130 milliseconds 460000000 additions 153.788033 gigainopsf1b0mark 10000000*2 iterations 24 paralell... result 109962632865826993121.105848 milliseconds 480000000 additions 434.056037 gigainopsf1b0mark 10000000*2 iterations 25 paralell... result 60741405686916925621.373220 milliseconds 500000000 additions 364.107718 gigainopsf1b0mark 10000000*2 iterations 26 paralell... result 11520178508006858121.190110 milliseconds 520000000 additions 436.934401 gigainopsf1b0mark 10000000*2 iterations 27 paralell... result 146766392066192306781.425837 milliseconds 540000000 additions 378.724917 gigainopsf1b0mark 10000000*2 iterations 28 paralell... result 97545164887282239281.303101 milliseconds 560000000 additions 429.744126 gigainopsf1b0mark 10000000*2 iterations 29 paralell... result 48323937708372171781.649733 milliseconds 580000000 additions 351.572042 gigainopsf1b0mark 10000000*2 iterations 30 paralell... result 183570151266557620441.443503 milliseconds 600000000 additions 415.655527 gigainopsf1b0mark 10000000*2 iterations 31 paralell... result 134348924087647552941.630618 milliseconds 620000000 additions 380.223940 gigainopsf1b0mark 10000000*2 iterations 32 paralell... result 85127696908737485441.588216 milliseconds 640000000 additions 402.967858 gigainops

author: magic
author_rank: Super Contributor
timestamp: November 30, 2020, 03:32:39 pm
content: 10x speedup with Rosetta, haha, no way it's realSomething is not right with clocking or maybe it optimizes things away because it's not constrained by my bogusvolatileannotations. A sufficiently smart compiler could reduce this whole benchmark to a single run with N=1 and then easily deduce all other results.Quote from: brucehoult on November 30, 2020, 02:29:16 pmThis is more plausible and a very good result. Assuming 3.2GHz clock, this chip manages 6 additions per cycle most of the time. That's twice the throughput of previous decade's TOTL x86.Yes, it collapses after N=14 because it runs out of registers and starts to spill. Ditto with Amd64 after N=7 and x86 after N=3. Reportedly, some recent Zens feature a very fast store to load forwarding which should improve performance here, up to another limit.I have no explanation for the slow ramp-up. The first line clearly shows that additions have 1 cycle latency so more additions in parallel should just scale linearly until all ALUs are saturated.Maybe LLVM didn't unroll enough. Please try with this Makefile, it adds some command line options which significantly improve unrolling on old GCC - now it gets close to theoretical limits on x86 and Cortex A15. LLVM is supposed to be command-line compatible, so maybe it will help too.I also refactored the code a bit, so a new version is attached too. It is now trivial to run one individual benchmark configuration from main for testing with tools likeperf. Silly file extensions because of forum engine restrictions

author: brucehoult
author_rank: Super Contributor
timestamp: December 01, 2020, 12:53:16 am
content: Quote from: magic on November 30, 2020, 03:32:39 pmvolatilemeans nothing in machine language. It's entirely within its rights to optimize 100 adds in straight-line unrolled code to a "multiply by 100 and add" -- which is three "shift and add" instructions on arm64.The rosetta version *did* run 10% faster than the native version (wall clock time), even including translation overhead, and got the same printed results. There's no arguing against that.

author: magic
author_rank: Super Contributor
timestamp: December 01, 2020, 07:13:47 am
content: The cheating precluded byvolatileis to realize that the critical function is always called with {1,1,...} as its argument and cache the output between program executions. I think this wouldn't be entirely out of the realm of possibilities as far as JITs go, but if you say the program still takes 90% of native run time and only the internal timing reports are wrong, thenI think all other code transformations that Rosetta could perform would also be available to Apple's C++ compiler, so it's not clear how Rosetta could be faster. Here's two that come to my mind:1. add all x numbers together and run only one series of Fibonacci iterations on their sum - it's all linear, after all (I think?)2. replace the 10 million iterations of addition with an equivalent logarithmic time matrix multiplication loopBoth appear to be outside the reach of GCC/LLVM for nowand I anticipate that either would result in an order of magnitude difference, so that's not what happens. I suspect something boring like unrolling differences between your Aarch64 and Amd64 compilers.You can't replace those additions with multiplications, easily.editOkay, there is one "dumb" optimization which doesn't require any knowledge of maths: tiling the inner loops for data locality. It would almost eliminate memory accesses and maintain full GIGAINOPS throughput of the CPU into arbitrary numbers of parallel sequences.High end scientific compilers could pull it off. I would be surprised if Rosetta has this capability, and even more so if it does but Apple's compiler does not. And it's still more difference in total run time than 10%...

author: madires
author_rank: Super Contributor
timestamp: December 01, 2020, 03:38:08 pm
content: Thevolatilememory type declaration simply tells the C compiler that the variable can change any time, e.g. by an interrupt handler. So the compiler doesn't optimize the variable usage by keeping it in some register and fetches/stores the current value each time when accessed.

author: Cerebus
author_rank: Super Contributor
timestamp: December 01, 2020, 05:14:59 pm
content: Quote from: madires on December 01, 2020, 03:38:08 pmThe important bit there is the preservation of the reads and writes tostorage, producing the same externally visible series of storage events rather than merely producing the samevaluesin storage at the end.Just for fun I thought that I'd see what LLVM does in the presence ofvolatileat different optimisation levels. I stuck with the Intel version in the expectation that more folks can read Intel assembler than can read ARM assembler. I did actually run the same with-arch armand the optimisations are, unsurprisingly, exactly the same logically speaking. The only significant difference with the ARM code is that there are many more loads and stores, which you'd expect from a risc architecture versus a cisc architecture with 'add to memory' instructions.First up, the C code. Nothing clever, just two fixed length loops incrementing global variables one of which is labelledvolatile, one which is not:int bert;void fred(){for (int i = 0; i < 10; i++){bert++;}}volatile int harry;void charlie(){for (int i = 0; i < 10; i++){harry++;}}I've removed all the cruft, procedure preludes and postludes and the like from the assembly code to make it more legible.First up, no optimisation. As you can see, both procedures are compiled into identical code:_fred: ## @fredmovl $0, -4(%rbp)LBB0_1: ## =>This Inner Loop Header: Depth=1cmpl $10, -4(%rbp)jge LBB0_4## %bb.2: ## in Loop: Header=BB0_1 Depth=1movq _bert@GOTPCREL(%rip), %raxmovl (%rax), %ecxaddl $1, %ecxmovl %ecx, (%rax)## %bb.3: ## in Loop: Header=BB0_1 Depth=1movl -4(%rbp), %eaxaddl $1, %eaxmovl %eax, -4(%rbp)jmp LBB0_1retq_charlie: ## @charliemovl $0, -4(%rbp)LBB1_1: ## =>This Inner Loop Header: Depth=1cmpl $10, -4(%rbp)jge LBB1_4## %bb.2: ## in Loop: Header=BB1_1 Depth=1movq _harry@GOTPCREL(%rip), %raxmovl (%rax), %ecxaddl $1, %ecxmovl %ecx, (%rax)## %bb.3: ## in Loop: Header=BB1_1 Depth=1movl -4(%rbp), %eaxaddl $1, %eaxmovl %eax, -4(%rbp)jmp LBB1_1retqNow with-O1. For thenon-volatileversion it's optimised the loop away entirely and replaced the multiple additions by a single constant addition of 10. For thevolatileit's optimised the loop induction variable but kept individual additions to thevolatilevariable._fred: ## @fredmovq _bert@GOTPCREL(%rip), %raxaddl $10, (%rax)retq_charlie: ## @charliemovl $10, %eaxmovq _harry@GOTPCREL(%rip), %rcxLBB1_1: ## =>This Inner Loop Header: Depth=1incl (%rcx)decl %eaxjne LBB1_1retqNow with-O2. For thenon-volatileversion it produces identical code, not surprising as the-O1optimisation is, quite literally, as close to optimal as you can get without global optimization (where hopefully the compiler would work out that this loop produces a value that is never used anywhere else and elide all of this). Thevolatileversion has had the loop unrolled, but is still producing the same set of externally visible actions as the previous two versions._fred: ## @fredmovq _bert@GOTPCREL(%rip), %raxaddl $10, (%rax)retq## -- End function_charlie: ## @charliemovq _harry@GOTPCREL(%rip), %raxincl (%rax)incl (%rax)incl (%rax)incl (%rax)incl (%rax)incl (%rax)incl (%rax)incl (%rax)incl (%rax)incl (%rax)retqUsing-O3produces exactly the same code as-O2, so there's nothing new to show. So does-Ofast.-Osand-Ozproduce the same code as-O1

author: bd139
author_rank: Super Contributor
timestamp: December 01, 2020, 05:46:24 pm
content: I'm slightly disappointed -O3 didn't optimise it to a nop or something and then amble off with its chest puffed up like a pigeon. clang/llvm is definitely more predictable than GCC.

author: magic
author_rank: Super Contributor
timestamp: December 01, 2020, 06:14:37 pm
content: This junk will be removed if you mark itstaticso that it's inaccessible to any external code linked against the resulting object file.Otherwise such "optimization" would not be legal.Alternatively, add a main function, compile with -flto and do the final link.

author: bw2341
author_rank: Regular Contributor
timestamp: December 01, 2020, 06:25:46 pm
content: Quote from: brucehoult on December 01, 2020, 12:53:16 amThis is all far beyond my knowledge, but I did read of an Apple Silicon feature that may relate to this result.Intel processors have a strong memory ordering model that adds implicit memory barriers. ARM processors have a weaker memory ordering model to allow more reordering for better performance. This would make Rosetta performance terrible if it needed to emulate this behaviour with additional barrier instructions to accurately emulate an Intel processor.To solve this, Apple built a TSO (Total Store Ordering) mode that changes the processor’s memory ordering model to be similar to Intel’s. This allows Rosetta to translate x86-64 load and store instructions to ARM directly.It seems that TSO mode may only be available on the high performance Firestorm cores. Perhaps the ARM version started on the low power cores and was moved to the high performance cores. Is there a way to force the program to run on the high performance cores?If the Rosetta version can only run on the high performance cores, this may explain the speed discrepancy.

author: Cerebus
author_rank: Super Contributor
timestamp: December 01, 2020, 06:57:18 pm
content: Quote from: magic on December 01, 2020, 06:14:37 pm*ahem*Quote from: Cerebus on December 01, 2020, 05:14:59 pm

author: magic
author_rank: Super Contributor
timestamp: December 02, 2020, 07:54:01 am
content: Quote from: bw2341 on December 01, 2020, 06:25:46 pmThere is speculation that they needed to do something like that to achieve compatibility, but has it been confirmed with any sort of detail and accuracy?Quote from: Cerebus on December 01, 2020, 06:57:18 pmJust responding to bd139's disappointment

author: brucehoult
author_rank: Super Contributor
timestamp: December 02, 2020, 08:51:52 am
content: Quote from: bw2341 on December 01, 2020, 06:25:46 pmThis is a fairly obvious idea -- obvious enough that RISC-V started the process to add it as an option about 3 1/2 years ago and ratified it as a standard in July 2018.You can build compliant RISC-V cores that use RVWMO (RISC-V Weak Memory Ordering, which is actually somewhat stronger than ARM's, but still allows high performance) or RVTSO (RISC-V Total Store Ordering), or that are switchable between the two.Software written for RVWMO will run correctly on any CPU or mode, but may run somewhat slower is TSO is enabled. Software written for RVTSO must run on a CPU implementing RVTSO full-time on in RVTSO mode on a CPU that is switchable.RVWMO was designed by a panel of world experts on memory consistency after bugs were found in the original RISC-V memory consistency specification in 2016.Here's a discussion presentation from mid 2017, with a lot of background:https://www.bsc.es/sites/default/files/public/u1810/arvind_0.pdfAnd a status update at the end of 2017https://riscv.org/wp-content/uploads/2017/12/Tue0954-RISC-V_Memory_Model-Lustig.pdfQuoteI have no idea about a difference in the cores, but any program that runs CPU-bound for more than maybe 100mS (or even 1mS?) causes a transition to a high performance core.

author: bd139
author_rank: Super Contributor
timestamp: December 02, 2020, 09:49:07 am
content: Interesting with the core transition. I assume that's going to have some consequences on spikey loads. It'll get evicted off a low power core, blowing the cache closest to the CPU in time to stop doing what it was doing. Wonder if there is any affinity and core pinning support on macOS...Haven't had a lot of time over the last few days to play with this machine yet apart from as a luser

author: DiTBho
author_rank: Super Contributor
timestamp: December 02, 2020, 12:30:16 pm
content: Quote from: brucehoult on December 02, 2020, 08:51:52 amThanks for this, it's very useful for me.

author: Cerebus
author_rank: Super Contributor
timestamp: December 02, 2020, 01:54:21 pm
content: Quote from: bd139 on December 02, 2020, 09:49:07 am[Part of] the cache is shown hanging off the switch fabric. Quite which side of the fabric/CPU core interface which level of cache sits at is opaque, but it ought to gosomeway to alleviating the cache bashing cost of switching cores.

author: bd139
author_rank: Super Contributor
timestamp: December 02, 2020, 02:00:19 pm
content: Yeah it'll still have to blow away some L1 / I/D cache I imagine. Not sure what the cache topology is. I haven't taken the CPU to bits yet in my mind. There are big gains to be had keeping cache as local as possible and for as long as possible.Actually that last point reminds me how much I hate virtualization as a conceptEdit: found one defect. When I shut the M1 Mini down, it crashes on shutdown and reboots and then I have to shut it down again. Sure they will fix that in macOS 11.1.

author: nfmax
author_rank: Super Contributor
timestamp: December 02, 2020, 02:49:38 pm
content: Quote from: bd139 on December 02, 2020, 02:00:19 pm"They all do that sir" - specifically my 2018 Intel mini does, since a security update to Mojave. It got a lot less frequent when I finally upgraded to Catalina, and it is supposed to be *fixed* in BigSuckSur. Something to do with the BridgeOS code running on the secure enclave processor. It sounds like M1 minis may have this too

author: olkipukki
author_rank: Frequent Contributor
timestamp: December 02, 2020, 03:12:32 pm
content: Meanwhile, if you already missed Mac mini on Intel, you don't need to buy it anymore, just "rent" from AWS"Customers can connect to Mac instances via both SSH for Command Line Interface and active remote screen sharing using a VNC client for a graphical interface. "

author: bd139
author_rank: Super Contributor
timestamp: December 02, 2020, 03:51:51 pm
content: Quote from: nfmax on December 02, 2020, 02:49:38 pmYeah my 2018 i3 one did that as well so could be right there.Interestingly I just found another bloody bug in it. Safari 14 in 11.0.1 uses macOS 10.15.6 as the user agent. Have raised this with WebKit, was marked as a duplicate of an existing bug where they manually set it to 10.15.7 as a solution. This is apparently because user agent sniffing problems on some libraries or web sites. DoubleQuote from: olkipukki on December 02, 2020, 03:12:32 pmMinimum 24 hours rental on that which is ridiculous if you want to do a short compile run on it or some CI stuff and/or shut it down overnight to save some cash.

author: brucehoult
author_rank: Super Contributor
timestamp: December 02, 2020, 08:30:22 pm
content: Quote from: olkipukki on December 02, 2020, 03:12:32 pmYup, for around $780 a month.You could buy a new one every month! Or rent one at other colo places for a lot less e.g.https://www.macminivault.com/dedicated-sign-up/

author: bd139
author_rank: Super Contributor
timestamp: December 02, 2020, 08:35:18 pm
content: Exactly. They ripped the guys responsible for this a new asshole on hacker news about itEdit: fixed the crash in macOS. It was not macOS but after doing some googling it was Karabiner-Elements doing it. I removed that and worked out how to get it to behave with an ISO layout keyboard by default and it's sorted now. One less headache!

author: madires
author_rank: Super Contributor
timestamp: December 05, 2020, 11:05:35 am
content: New RISC-V CPU claims recordbreaking performance per watt:https://arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/200 mW at 4.25 GHz, and 69 mW at 3 GHz!

author: Marco
author_rank: Super Contributor
timestamp: December 05, 2020, 05:23:12 pm
content: I find the hemming and hawing about the M1 power consumption funny. Must not upset the fanboys.Not just here, but in general the performance and power efficiency of Zen2 laptop processors in parallel benchmarks really calls into question the supposed extra-ordinary performance of the M1 architecture. Apple is really good at scale and could afford to just outright buy 6 months of 5nm production at relatively high risk, architecturally ... well it's impressive they closed the gap this well, but with the node advantage talking about superiority is a bit presumptuous.

author: bd139
author_rank: Super Contributor
timestamp: December 05, 2020, 05:44:25 pm
content: I think the point is if you crank a zen2 laptop and an M1 up on the same workload then the job will probably finish about the same time but the Mac will not burn your dick off or need plugging in.

author: Marco
author_rank: Super Contributor
timestamp: December 05, 2020, 06:03:18 pm
content: My point is that that's wishful thinking rather than reality, or in other words ... inside the reality distortion fieldCheering Apple and helping them getting a computing monopoly is a bad idea for anyone who loves technology in the first place, but to also applaud their supposed massive architectural superiority is just ignorant. Microsoft is incompetent, Intel can't do EUV and AMD doesn't have the ability to compete with Apple for node access ... x86 processor architectures are currently clearly not the source of the problem with PCs though, it's everything else. Unfortunately, because the relative openness of the PC gave us a golden age. Now Apple is going to "correct" IBM's mistake and make it all boring.

author: bd139
author_rank: Super Contributor
timestamp: December 05, 2020, 06:50:47 pm
content: It’s not a computing monopoly at 15% market share...The reason the PC problems exist is because there is almost zero vertical integration. And the fact the entire industry has been a race to the bottom built on the ashes of a lot of really bad computing decisions (NT for example). As someone who came from the old workstation background (Sun in particular) all we’re doing is buying a nicely vendor integrated Unix here with a desktop that’s better than CDE. Which is what you do if you want something that works.All of this is moot though. The thing that is costly is my time and attention. Anything which gets the fuck out of my way and let’s me solve problems gets the job. That varies depending on what’s required at the time and what it is doesn’t really bother me.

author: Marco
author_rank: Super Contributor
timestamp: December 05, 2020, 07:05:11 pm
content: Quote from: bd139 on December 05, 2020, 06:50:47 pmIt's going to snowball.The openness of the PC always opened companies up a little more to competition, Intel/Microsoft could take leads but especially for Microsoft there was always a relatively low cost path for competition (which Apple massively benefited from). An Apple lead will now start taking away investment from PC hardware development, if they get sufficient mass it's all over and it will be infinitely harder to dislodge. Boring.

author: bd139
author_rank: Super Contributor
timestamp: December 05, 2020, 07:10:15 pm
content: ARM and RISC-V are open as well. This is just one variation of the arm64 platformNone of that matters though. The contract between your data and the system is where you should be concerned.

author: Marco
author_rank: Super Contributor
timestamp: December 05, 2020, 07:16:03 pm
content: Quote from: bd139 on December 05, 2020, 07:10:15 pmM1 architectural innovation don't cheaply stream into ARM/RISC-V from other companies.x86 architectural innovation streamed cheaply into Macs as long as Apple still needed it.

author: bd139
author_rank: Super Contributor
timestamp: December 05, 2020, 07:29:35 pm
content: Well it does really. It’s no secret what they did. Most of this thread is about it.x86 is dying. They pushed it to the limit already. Someone just put another option on the table, that’s all.

author: Marco
author_rank: Super Contributor
timestamp: December 05, 2020, 07:38:27 pm
content: Quote from: bd139 on December 05, 2020, 07:29:35 pmState of the art 8-way superscalar processors without running into a million patents are billion dollar endeavours, M1 does nothing to make this easier for ARM/RISC-V implementations from other companies ... it doesn't even help create a market for them, unlike how things happened on PCs. Boring.QuoteX86 is fine for PCs, if they were at the same node 4800U would almost certainly scale higher in performance within a 15 Watt envelope (and be the same die size as a M1). PCs, even laptops, don't scale low enough in power consumption for little cores to be truly necessary. That display is pushing out nits any way.PCs are dying because of everything else, M1 is nothing special architecturally compared to x86 ... just other ARM processors.

author: borjam
author_rank: Unknown
timestamp: December 05, 2020, 09:41:09 pm
content: Quote from: Marco on December 05, 2020, 07:05:11 pmOpenness?Do you mean Microsoft coercing manufacturers to sell only Windows, and Intel suing compatible processor manufacturers while "proprietary" (according to the Wintel Ministry of Truth) processors were in fact available from several manufacturers, in a similar fashion as ARM processors now?Orwell would have a good laugh!

author: magic
author_rank: Super Contributor
timestamp: December 05, 2020, 11:10:35 pm
content: They may be coercing and suing, but you can run a dozen operating systems on PC hardware and high performance x86 suppliers are "only" a duopoly. Add a few smaller players in embedded.Alternative software for ARM Macs (or just about any ARM board for that matter) may or may not materialize. Alternative hardware to run those software binaries almost surely will not.That's the difference. There is basically no "standard ARM platform" to speak of. It's all proprietary SoCs on propriety boards with proprietary builds of Linux or some proprietary OS.

author: brucehoult
author_rank: Super Contributor
timestamp: December 05, 2020, 11:17:39 pm
content: Quote from: Marco on December 05, 2020, 07:38:27 pmThere was a rush of superscalar Out-of-Order processors in the mid 90s.The Pentium Pro did 3-wide decode (generating up to 6 uOps total), 5 wide execution (in 6 units) in 1995.The DEC Alpha 21264 had 4-wide decode, 6-wide execute in 1996.Patents for those, and others, have expired by now.Decoding 8-wide instead of 4-wide on a simple fixed length 32 bit opcode instruction set such as Alpha or arm64 is just a parameter -- literally changing a "4" to an "8" in an RTL generator. Exactly the same (expired) patents will cover it.The hard part about it -- and more to the point having 600 reorder buffer entries as M1 does (192 or 224 are popular numbers on modern x86) -- is something I haven't seen *anyone* mention in any thread on any forum or media report. It's not that hard to change the parameters to do that, if you have enough transistors available on a die (i.e. a small process). The hard part is that most code has, on average, a branch instruction every five or six instructions. If you are going to have 600 instructions in flight at the same time then you have to be reasonably sure they are the RIGHT 600 instructions.That means you have to accurately predict up to about 100 conditional branches in sequence. If you get any one of them wrong then you have to throw away all the work you did on following instructions, wasting both time and energy.You can build as wide and deep a machine as you want -- it's straightforward -- but if you can't predict the branches accurately then it's totally wasted.Apple must have done something quite amazing and absolutely unpublicized about branch prediction.Branch prediction was also the most secret thing about the Pentium Pro back in 1995 -- and Pentium MMX got the same branch prediction technology and was what made it a big jump over earlier Pentiums (not the MMX).These days, microcontroller cores such as the SiFive FE310 (and probably ARM M3/M4, certainly M7) have the same branch prediction technology the Pentium Pro pioneered -- not because they're out of order, but just to eliminate pipeline bubbles most of the time.Building an 8-wide decoder for x86 is exponentially harder. The instruction lengths from 1 to 15 bytes mean those instructions could occupy anywhere from 8 bytes to 120 bytes. And you have no idea where later instructions start until you've already done most of the decode on earlier instructions. It's just intractable on cold code. On hot code you can add marker bits for the start of each instruction in the L1 cache, and have a uOp cache, and so forth. But that's all extra complexity and transistors and energy use that arm64 or RISC-V don't need.

author: brucehoult
author_rank: Super Contributor
timestamp: December 05, 2020, 11:25:00 pm
content: Quote from: magic on December 05, 2020, 11:10:35 pmThat's true in the ARM world.RISC-V is trying hard to head that kind of thing off before it starts. Each SoC/board may need a custom 1st stage bootloader to initialize DRAM and various other things, but then it presents a standardized "SBI" ECALL interface and even the 2nd stage bootloader (e.g. Das U-Boot or similar) sees a completely standardized system and the same uboot binary can run on every system, as does Linux once you get that far.

author: magic
author_rank: Super Contributor
timestamp: December 05, 2020, 11:34:41 pm
content: For the record, recent Cortex cores use µop caches and ARM claims that it actually improves efficiency by using less power than their Aarch64 decoder. Their cache is also wider than the decoder - more speed on highly looping code.Are you sure of that branch prediction thing? I suppose it could be that they increased the ROB depth opportunistically, to speed up easily predicted loops.

author: brucehoult
author_rank: Super Contributor
timestamp: December 06, 2020, 12:41:31 am
content: Quote from: magic on December 05, 2020, 11:34:41 pmInteresting. Aarch64 does have quite a few instructions that could benefit from splitting into uOps -- though nowhere near x86 level, of course. RISC-V doesn't currently have anything that would warrant splitting -- the instructions are their own uOps. Hmm, except maybe the atomic ops. But they need to avoid reordering. Some optional extensions may introduce uOps -- the Vector extension, for example.And the code size reduction work has people wanting to introduce things such as push/pop multiple to complete better with ARM in microcontrollers (where RISC-V is doing quite well already without it). People such as Huawei and Andes have implemented these things as custom extensions already in shipping chips, so it makes sense to at least standardize the opcodes so software is more portable across vendors, and gcc can target just one flavour.QuoteIt's mathematically certain that you can't use a 600 entry ROB / rename registers without correctly predicting all necessary branches -- which in some cases *may* come down to very large basic blocks, and in many others just relatively simple loops that execute a lot of times.Economically, they wouldn't do it unless it was giving benefit on a fair bit of important code.How much of the time it gets used .... anyone's guess...One thing I've never seen anyone mention is whether there is a mechanism to *not* race too far ahead if you encounter a few branches where the prediction is too uncertain.That's where conditional select is *really* useful. It might or might not be faster in isolation, but it often lets you totally get rid of branches are relatively unpredictable (at a small cost in doing unnecessary work on the result that isn't selected) and successfully speculate much further ahead.

author: Marco
author_rank: Super Contributor
timestamp: December 06, 2020, 07:26:29 pm
content: Quote from: borjam on December 05, 2020, 09:41:09 pmYes, even with all that at its worst the PC was far more open than Macs will ever be ... that's how bad having a dominant Mac is. Yet somehow some people who can recognize those evils on PC are blind to the much greater evil of a dominant Apple. It's utterly bizarre.

author: bd139
author_rank: Super Contributor
timestamp: December 06, 2020, 08:17:25 pm
content: But platforms don’t matter. Apple has just proven that by pulling the tablecloth out from under a full set again.Kernels, compilers and programming interfaces do matter. They deliver the benefits to the end users which is where the entire purpose of computing is.

author: Cerebus
author_rank: Super Contributor
timestamp: December 06, 2020, 09:24:26 pm
content: Quote from: Marco on December 06, 2020, 07:26:29 pmWhy don't we address that problem if and when Macs look like they might become market dominating. As they are nowhere even close to market dominating at the moment or in the foreseeable future your point is completely moot.

author: magic
author_rank: Super Contributor
timestamp: December 06, 2020, 09:42:08 pm
content: An underdog company churns out decent products for a small clique of dedicated fanboys.The company grows and erodes former monopolies, the fanboys go wild.The fanboys don't see what's coming when their company becomes the next monopoly.Many such casesAs far as I'm concerned, if it can't boot Loonix, it doesn't exist.And by the way, I don't mean a five years old fork of then-bleeding-edge LTS release, thank you ARM.Quote from: brucehoult on December 05, 2020, 11:25:00 pmLike PC BIOS and its IRQ calls? Not too bad (if it doesn't run in 16 bit mode, that is).But there is another part of the ARM disaster which is peripherals. IRQ controllers, PCI bridges, stuff.Any plans to make them register compatible? A firmware API behemoth like ACPI coming?

author: bd139
author_rank: Super Contributor
timestamp: December 06, 2020, 09:50:30 pm
content: There’s a difference between booting Linux and it actually working properly, a problem I regularly find. My T495s runs Fedora and after the last kernel update when you shut the lid it shits the kernel out. There was also a bug which I whined about loudly a few weeks back where the I2C / HDMI shit show (have you ever looked at the vile freedesktop code?) in a certain kernel decided to spin up a kernel task with 100% CPU on one core when running headless. Oh and don’t even get me started on trying to sort out a hosed systemd boot on LVM.I am dying for some vendor lock in and half decent well tested platform integration. Never had any of this shit on Solaris, HP/UX or macOS. And they came with manuals!I think we need to go back to the workstation model myself. I know that’s unpopular but the time cost for me when things go wrong is higher than any other cost.

author: magic
author_rank: Super Contributor
timestamp: December 07, 2020, 09:36:50 am
content: Well, I do admittedly tend to run LTS kernels and jump major releases once a few years for new features.Also thinking about building myself a known good GTK2 desktop environment from source and forever forget about upgrade drama here. It will likely run future applications for many years, until X is completely displaced by that Wayland thing.What I hate most is change for the sake of change. I used to actually like WinDOS back in the day. I hate what it is today. I have a permanent proprietary software PTSD, sorry

author: bd139
author_rank: Super Contributor
timestamp: December 07, 2020, 10:55:29 am
content: The LTS kernel on CentOS 7 was what was throwing the HDMI shit show. There was a sweet spot where the development of Linux needed to hold up and do a proper QA run and that was around CentOS 6 with the old Gnome desktop. If they literally fixed all the odd bugs, edge cases etc then progressively added improvements rather than blow the entire universe away they'd be good. But the main failure of open source software is that if it's not interesting, like fixing bugs, it is rarely done. Only via attrition some core packages have become stable (GNU I'm looking at you). I notable exclude FreeBSD from this which is actually really a corporation run product and not an ecosystem (which is a good thing).Same trouble with software PTSD. I actually just spent the last 30 minutes shitposting on a microsoft ticket about what a fucked up pile of shit I have to deal with at the moment. Wasting my time but it's cathartic. I also liked MS's historical platforms. My first paid dev work was on MS PDS 7 on MSDOS, followed by 16 bit Visual Basic. Both talking to Unixes behind the scenes but it was a nice time where things mostly just worked and fit in your head.Anyway rant over.I did a count up today on ARM CPUs in my house. I counted 22. I count 6 x86 cores. ARM has more than won.

author: brucehoult
author_rank: Super Contributor
timestamp: December 07, 2020, 11:37:35 am
content: Quote from: bd139 on December 07, 2020, 10:55:29 amI expect i could make a pretty good count of the x86 cores in this house. 32 in my Linux PC, 6 in the AMD 4500U laptop, 4 in the 2017 NUC, 4 in the 2011 MacBook Pro, 2 in the 2011 MacBook Air, 4 in the i7 4790K Linux machine I haven't turned on in five years. That's probably all.ARM .. I wouldn't even know how to make an estimate.Sure, I maybe know how many cores are in the M1 Mac, iPhone SE, iPhone 7, Apple Watch, Pi4, Pi3, Pi2, Pi1, Pi Zero, Odroid C3, Odroid XU4, Arty Z7 (ARM cores embedded in an FPGA), Blue Pill, Nucleo.At least I know the main cores. But there can be others doing auxiliary tasks. I've heard on good authority that x86 chips have an ARM core or two inside.But what about my multimeter? Oscilliscope? Pulse Oximeter? Amplified speakers? 4K monitor? Ethernet switch? Wifi router? MIcrowave oven? Dishwasher? And I'm sure a host of things I've not thought of right now. They might have ARM cores in them -- or maybe PIC or AVR or MIPS.I have over 40 RISC-V cores in my house. By mid January it will be over 50 as the Icicle FPGA board and HiFive Unmatched will bring 5 each.I think it was Horace Dediu who said that in the 1950s people knew exactly how many electric motors they had in their house, but by the late 1970s or 1980s no one had any idea how many they had. And in the 1970s and 1980s people kew exactly how many CPU cores they had in their house.

author: magic
author_rank: Super Contributor
timestamp: December 07, 2020, 11:53:11 am
content: Quote from: brucehoult on December 07, 2020, 11:37:35 amConsumer network gear was almost exclusively MIPS, though ARM is making some inroads this decade.

author: borjam
author_rank: Unknown
timestamp: December 07, 2020, 12:34:55 pm
content: Quote from: bd139 on December 06, 2020, 09:50:30 pmSeveral years ago I gave some FreeBSD advocacy talks on Linux conferences in Spain. Quite a risky prospect when, for example, I criticized the stupid tendency to make "ls" a package, diff another package... I compared it to SCO Unix which sold separate packages for "Text processing", "Development", "TCP/IP *runtime*", "TCP/IP Development" (necessary for compiling any sockets based application) etc.And yes, most of the penguin fanboys at least at the time were just bonsai enthusiasts. They kept installing packages and "hey, this works!" but they used Windows even for web browsing.QuoteThe closest thing now is Macos. At least I can compile and run stuff in C and Python without any troubles.

author: bd139
author_rank: Super Contributor
timestamp: December 07, 2020, 01:06:38 pm
content: If you think that's bad you want to see it taken to the extreme. NodeJS is the outcome of years of working out how to fuck up completely. I imported one small package and it imported 100 dependencies in a massive treeThis is why I like Go. Productive out of the box, no frigging dependency hell.

author: borjam
author_rank: Unknown
timestamp: December 07, 2020, 05:14:57 pm
content: Quote from: bd139 on December 07, 2020, 01:06:38 pmYep, I agree. I got the book last month and I'm really impressed. I guess it's going to become my next goto language. Pun intended

author: bd139
author_rank: Super Contributor
timestamp: December 07, 2020, 06:03:44 pm
content: It has become mine. Basically all I wanted was C with Unicode, some object orientation, without as many footguns, some concurrency primitives and a decent standard library and I got it!

author: brucehoult
author_rank: Super Contributor
timestamp: December 07, 2020, 09:07:20 pm
content: Quote from: bd139 on December 07, 2020, 06:03:44 pmHave you looked at D? It's along similar lines, has been around since 2001, and is mature.

author: bd139
author_rank: Super Contributor
timestamp: December 07, 2020, 09:34:58 pm
content: I did for a month or so. It didn't stick. The standard library that shipped with it wasn't particularly mature and there were some gaping holes in it. It never felt it had momentum behind it either.I think one of the attractive thing about Go is it's actually really easy, especially when it comes to concurrency matters. It is reminiscent (invoking tggzzz here) of Hoare's CSP paper. One of the things I tend to end up building is high performance messaging, filtering and routing engines and the abstractions allow you to compose your software using functional elements connected by channels. While the last one I built was a monster .Net / CLR thing that used async, Task APIs and the concurrent collections API, they were really a poor abstraction model for highly concurrent systems. Unfortunately necessity was that I used the tools available. I rebuilt a chunk of the platform in Go in a few days, a surprise in itself, and found out a couple of even more surprising things. Firstly it used 15x less RAM using the same workload test harness. When your memory ceiling on a single .Net process hits 1TB due to GC it gets interesting in the cost and reliability department. When inevitably one of the spinlock and interlock implementations inside CLR decides to give out, because quite frankly they were written by morons, there's no chance you're ever going to be able to debug that dump. Go, no problems. It never went wrong even chunking through 70Gb of RAM. Secondly I added prometheus metrics wrappers around the channel delivery parts which allowed me to do dynamic analysis of the bottlenecks and optimise worker pools etc. The final surprise is the reduction from about 100kloc of C# to just over 12kloc of Go.I tried to sell it back to them. They didn't want to knowAnyway I'm waiting for them to release a proper darwin/arm64 port at the moment. I'll be using Linux x86 for now.Edit: actually I didn't check before but it does work via Rosetta fine by the looks. I was a little worried about signing issues...

author: Marco
author_rank: Super Contributor
timestamp: December 08, 2020, 04:46:52 pm
content: A benchmark I'd like to see ... the pigz test arstechnica did, running repeatedly for about 5-10 minutes, showing how performance evolves and if possible some power measurements near start and finish (from mains socket). Both with 4 and 8 threads.I'd like to know just how little the little cores contribute, especially in temperature constrained situations.

author: brucehoult
author_rank: Super Contributor
timestamp: December 08, 2020, 10:15:44 pm
content: My experience so far is the little cores contribute pretty much the same as HyperThreading does on Intel. All four little cores together add maybe a little more processing power as one more big core would.I haven't seen any throttling at all so far. The thing is always a cold chunk of aluminium.

author: bd139
author_rank: Super Contributor
timestamp: December 08, 2020, 11:29:22 pm
content: Yep same experience with the temperature.I managed to get Rosetta to puke earlier though on a Go binary. Opcode translation error when I hit Ctrl C. Not sure exactly what happened there to be honest. Couldn’t reproduce it a second time. Bogons!I am seriously impressed though as it has been daily driver machine. Flawless so far.

author: brucehoult
author_rank: Super Contributor
timestamp: December 08, 2020, 11:52:02 pm
content: I demo'd mine at a small meeting last night.Someone asked about Handbrake so I installed that and we tested against a recent thin and light high end Dell laptop (I didn't get the exact model), same video source same presets. The Mac in Rosetta did 180 FPS, the PC 38 FPS.Interestingly, the beta native ARM version  of Handbrake got only 120 FPS. I guess Apple has done more ARM SIMD optimization than Handbrake / ffmpeg have, so far. actually the same app download, just testing with and without "Open in Rosetta" checkbox.

author: Cerebus
author_rank: Super Contributor
timestamp: December 09, 2020, 12:06:26 am
content: I presume in testing HandBrake you're avoiding the hardware accelerated video encoding options (the ones that name "VideoToolbox" in the encoding option)?

author: brucehoult
author_rank: Super Contributor
timestamp: December 09, 2020, 12:22:31 am
content: I don't know anything about Handbrake. I was asked to try it. We used the "Fast 480p30" preset under "General".

author: Cerebus
author_rank: Super Contributor
timestamp: December 09, 2020, 01:34:08 am
content: Quote from: brucehoult on December 09, 2020, 12:22:31 amThat uses a software H.264 compressor so you're good. That gives ~ 86 fps here on a 2018 Macbook Pro (from a 1080p25 source, so a little unfair making it do rate adaption). Switch to hardware assisted encoding, but with otherwise identical settings and it goes at around 100 fps. Both quite disappointing as my usual hardware assisted H.265 encoding to 720p25 from 1080p25 usually flies along close to 200 fps.

author: bd139
author_rank: Super Contributor
timestamp: December 09, 2020, 07:28:24 am
content: I’m waiting for a stable M1 build of Resolve before I even look at this. AFAIK ffmpeg doesn’t support the native codec in the CPU, merely “hardware acceleration”. My iPad is the scary thing. In LumaFusion it can export from a 4K source down to 1080p H265 faster than my ryzen in Resolve. Doesn’t even get warm on a 5 min video.

author: DiTBho
author_rank: Super Contributor
timestamp: December 09, 2020, 11:10:04 am
content: What about FinalCut ARM/M1?

author: bd139
author_rank: Super Contributor
timestamp: December 09, 2020, 12:54:56 pm
content: Costs actual money

author: borjam
author_rank: Unknown
timestamp: December 09, 2020, 02:16:21 pm
content: I guess the Final Cut test will be distorted by their own Metal optimized GPU anyway.I mean, substantially improved but it will make comparisons irrelevant.

author: bd139
author_rank: Super Contributor
timestamp: December 09, 2020, 04:14:01 pm
content: Well the application specific CPUs are what we're paying for really.

author: Mr. Scram
author_rank: Super Contributor
timestamp: December 11, 2020, 11:24:31 pm
content: Quote from: brucehoult on December 07, 2020, 11:37:35 amDon't forget things like HDD and SSD controllers and various other auxiliary and helper chips. Those are ARM chips, generally multiple cores. Just an X86 computer has a zoo of ARM cores on board.

author: Mr. Scram
author_rank: Super Contributor
timestamp: December 11, 2020, 11:31:28 pm
content: Quote from: bd139 on December 09, 2020, 07:28:24 amYou could argue that hardware acceleration is, in a sense, adding the instructions and complexity which ARM aims to avoid back in. X86 isn't great because it's efficient, it's great because it does many things reasonably well.Tacking all kinds of auxiliary onto an ARM core only works with tight integration and control over your ecosystem. I'm interested how that pans out when it all becomes old enough to have to deal with legacy compatibility, although it's probably a matter of pushing older hardware out the back and saying "tough shit!" to the owners as Apple tends to do.

author: brucehoult
author_rank: Super Contributor
timestamp: December 11, 2020, 11:41:32 pm
content: Quote from: Mr. Scram on December 11, 2020, 11:24:31 pmBoth Western Digital (two years ago) and now this week Seagate have said they are moving to RISC-V for their storage controllers.

author: bd139
author_rank: Super Contributor
timestamp: December 12, 2020, 12:03:56 am
content: Quote from: Mr. Scram on December 11, 2020, 11:31:28 pmWell the beauty of operating systems and programming interfaces should make that issue moot. The machine’s objective is to fill that higher level API and provide utility to the end user. Whether that uses a generic processor or an application specific processor or how it implements that should be part of the device trade off of cost, die size, power usage etc.If you use that API and they release new hardware then you get instant advantage.As for longevity and support I expect 5 years out of a piece of hardware but usually sell it after 2. As for support it has some costs. I recently helped sort out an 8 year old core 2 duo machine running windows 10. Yuck not living in that world ever again. I’d be in a care home by the time it got anything done. Old macs are just as bad but that’s mostly because 2013ish stuff had rust disks. In six years things should be interesting as I reckon current generation kit is still going to be pretty excellent (until we start getting webassembly shit to deal with)

author: bd139
author_rank: Super Contributor
timestamp: December 14, 2020, 05:28:05 pm
content: Another article with benchmarks:https://tech.ssut.me/apple-m1-chip-benchmarks-focused-on-the-real-world-programming/Incidentally I'm not upgrading my Ryzen now. It's going now I've finished GTA V and Watchdogs Legion. This is by far the most pleasant computer I've used for years. I am mostly using Go, Visual Studio Code, terraform, Lens and doing a bunch of AWS admin. No Windows any more.

author: bd139
author_rank: Super Contributor
timestamp: December 18, 2020, 04:12:25 pm
content: Noticed the Rosetta translation on startup here which was interesting. Not much lag on a 4 meg go binary (this is just returning in the entrypoint)Still no complaints!

author: brucehoult
author_rank: Super Contributor
timestamp: December 18, 2020, 10:45:36 pm
content: If the first run is slow because of Rosetta translation then why does it use only 2% CPU?It's loading the binary from disk to disk cache, not Rosetta.

author: bd139
author_rank: Super Contributor
timestamp: December 18, 2020, 10:51:32 pm
content: It’s a good question. However it literally just compiled that in a separate terminal window so I’d expect it to already have the blocks from the disk in memory after writing through a few seconds before. 300ms is fairly slow to pull 4 meg off an SSD as well.I’ll have Go 1.16 (beta) with native Darwin/arm64 tomorrow so will compare. Need to work out how to grab it without breaking my existing install first.

author: brucehoult
author_rank: Super Contributor
timestamp: December 18, 2020, 11:33:45 pm
content: OK, dynamic linking then.Or ... ::black hat on:: ... checking the app signature against a blacklist on the internet.

author: bd139
author_rank: Super Contributor
timestamp: December 18, 2020, 11:40:10 pm
content: It’s static linked.Your second point may be on the mark though. Will test tomorrow.

author: magic
author_rank: Super Contributor
timestamp: December 19, 2020, 07:35:53 am
content: You mean, tin foil hat?

author: olkipukki
author_rank: Frequent Contributor
timestamp: March 28, 2021, 09:32:34 pm
content: Quote from: bd139 on November 24, 2020, 02:42:48 pmSorry to say but looks like overpaid a lothttps://youtu.be/eACEHVceYl0?t=61

author: bd139
author_rank: Super Contributor
timestamp: March 28, 2021, 09:53:11 pm
content: That’s $628 now. Pretty close to reality.Ironically in 1994, the same year as that video, I blew every penny I had on an actual ARM desktop machine. It was an Acorn RiscPC 600. 32Mhz 4MB RAM and 210Mb hard disk.

author: Marco
author_rank: Super Contributor
timestamp: March 28, 2021, 10:31:30 pm
content: Quote from: bd139 on December 09, 2020, 07:28:24 amOn the other hand, the hardware encoder is almost certainly significantly inferior to libx265.

author: AntiProtonBoy
author_rank: Frequent Contributor
timestamp: March 29, 2021, 04:17:38 am
content: False equivalency. You are essentially comparing hardware accelerated H.264 (QSV) with H.265. Of course it's going to be significantly inferior in every respect. This is also true if you compare high quality H.264 encoding schemes with H.265. It's more constructive to draw comparisons between H.264 QSV and non-hardware accelerated H.264 codecs.

author: tooki
author_rank: Super Contributor
timestamp: March 29, 2021, 12:44:59 pm
content: Apple’s SOCs have supported hardware H.265 encoding since 2014.

author: Marco
author_rank: Super Contributor
timestamp: March 29, 2021, 07:48:10 pm
content: Quote from: AntiProtonBoy on March 29, 2021, 04:17:38 amIt has H.265 hardware encoding too and the post I responded to was talking about H.265.That said, I'm sure the hardware H.264 encoding is significantly inferior to libx264 too.

author: bd139
author_rank: Super Contributor
timestamp: March 29, 2021, 09:10:46 pm
content: I think I’d like to see an actual comparison done first before quoting that. The entire things are designed around media processing so I’m not sure why they’d ship a crappy codec.

author: tooki
author_rank: Super Contributor
timestamp: March 30, 2021, 05:40:11 am
content: Quote from: Marco on March 29, 2021, 07:48:10 pmThen what’s your point? Slow, multi-pass software encoding will always produce better (read: more storage-efficient for a given image quality) results than even the best hardware encoder.

author: tooki
author_rank: Super Contributor
timestamp: March 30, 2021, 05:47:43 am
content: Quote from: bd139 on March 29, 2021, 09:10:46 pmYep. With that said, a multi-pass encoder (which is conceptually incompatible with a real-time hardware encoder) will always have an edge in encoding efficiency.

author: Cerebus
author_rank: Super Contributor
timestamp: March 30, 2021, 04:07:51 pm
content: Quote from: tooki on March 30, 2021, 05:47:43 amNotconceptuallyincompatible. It's easy toconceivethe idea of a hardware encoder that took a stream of 'hints' alongside input video similar to those that might be gleaned from a first pass over video by a software codec.Whether 2-pass hardware is now necessary is another question. What a first pass of encoding gives you is a longitudinal view of the video stream, enough advance warning to know where you can save bits because a scene is relatively static so that you have them to squander on 'busy' scenes. Because of peak rate limits you only really have a relatively short window over which you can 'hoard' bits, a matter of seconds not minutes, so it's not inconceivable that modern hardware CODECs are getting close to high enough levels of integration and pipeline memory to make 2-pass encoding irrelevant as long as you can accept a reasonable encoding delay.I'd hope that the designers of CODECs for general purpose computers would consider both use cases: genuine minimum delay "real time" encoding, and high quality "rendering" encoding with non-real-time latency, and expose suitable modes to the software driving the CODEC.