M1 chip fast my ass...

[casperes1996]

The amount of software that doesn't run is all the convincing I need. Sure, you can emulate a console from the 1980s on the M1, but let's look at other emulators, shall we? Can you run PCem, which emulates an x86 Win9x era PC, on Mac? You cannot. Can you run Xenia to emulate the Xbox 360 on Mac? You cannot. Can you run PCSX2 to emulate PS2 games? You cannot (without great difficulty). Can you run RPCS3 to emulate PS3 games on Mac? You cannot. Can you run Spine, the up-and-coming PS4 emulator, on Mac? You cannot. Can you run Cemu to emulate Wii U games on Mac? You cannot. Can you run Yuzu to emulate Switch games on Mac? You cannot.

None of this software is available for the Mac. Windows and Linux only. Two operating systems which are also no longer natively available for the Mac. The only thing you get with Mac anymore is exclusive Apple software, exactly the way Apple wants it to be (don't you want to buy and use all of these perfect magical Apple products? Don't you love our harmonious ecosystem? Apple makes everything for you. Of course you want it, join us, join us now). I'll take that loss and gain immeasurable freedom and access to the rest of the software library available to the planet.

That wasn't really my point with the emulation argument. I wasn't really talking about running emulators on Apple Silicon Macs necessarily, simply making the argument that software archival has value but I don't think it is so threatened by deprecations as a result of emulation and virtualisation down the road.
Though I will say you need to add another (with great difficulty) since you can in fact compile RPCS3 for macOS and while it's not as straight forward as a Linux build a lot of the work has been put in to make it so. The makefiles have unique macOS entries to link against the proper frameworks and all.
I don't know most of the emulators you mention though but I'll tell you this; if they're unavailable that's not because of M1 or some locking down of anything. They're also not available on an Intel Mac.

I’m pretty sure “statistically impossible” isn’t a thing. I’m guessing you got that 10^-50 number from the same StackExchange article I found searching for the phrase— I can’t find any authoritative reference for the phrase though.

Something can be statistically possible while practically impossible— it’s statistically possible to flip heads 1000 times, but you aren’t going to do it in your lifetime, or if you take a gaussian distribution out far enough on the tails it still has a non-zero probability but you’ve reached the physical limits of the system in question.

It’s possible to be statistically insignificant, which doesn’t say anything about the likelihood of the event, and merely means you don’t have enough data to determine one way or the other.

I think someone used a bogus phrase looking to add credibility to a bogus argument and you and @TiggrToo are trying to map a formal definition to language that doesn’t exist. Perhaps they meant “impossible” and think adding the “statistically” modifier sounds cool, or maybe they mean “unlikely”.

I think you're perfectly correct in this assessment - Though my take on the phrase is that it's precise value is contextual and in a casual conversation I'd accept a threshold as low as a 10% chance or thereabouts. But as that StackExchange page you reference also says "It's completely arbitrary"

This is incorrect. Supporting 32bit applications means supporting an additional hardware operation mode (sometimes with different rules!), supporting and testing two pairs of libraries and also supporting a tricky set of edge cases of transitioning between the 32bit and 64bit boundary. There is also no reasonable way to transition to high-performance ARM while keeping 32-bit support (because 32-bit ARM is crap).

Furthermore, Apple has stripped 32-bit hardware from their chips. I believe starting with the A7. This allows them to focus more of their silicon budget on a faster, better 64-bit CPU. If all major systems could drop 32-bit and adjust the boot up process to fit, x86 chips could drop not just 32-bit hardware but also 16-bit hardware, which is in every single x86-64 chip right now. When an x86 system boots, it boots in "real mode", i.e. 16-bit mode - At least for multi boot, GRUB will put the chip into protected mode before handing it over to the kernel, which is 32-bit mode. But then the kernel needs to put the chip in long mode before it's read to properly use it in 64-bit and thus address all the system's memory in a flat memory model. Before all this all sorts of segmentation nonsense has to be set up that no modern OS really uses because we instead utilise a paging system, but it needs to be done for legacy reasons and for hardware support. And then of course there's the A20 gate. A hack that stuck with us because of flawed software that IBM wanted to remain compatible with and now all PCs need extra hardware and all PC operating systems need code to deal with this frustrating mess, just because of a mistake made several decades ago

A20 line - Wikipedia

en.wikipedia.org

ARM has also officially ripped out 32-bit support from a lot of their newer ARMv9 core designs. I'd rather have a better 64-bit chip than a worse one that can also run 32-bit.

OSX shouldn't have had x86 libraries period, IMO. The ONLY Intel Macs that ever existed with 32 bit processors were the very first using the Core Duo. Literally a 6 month period in 2006 led to 12 years of maintaining a pointless architecture in the OS and Xcode. Every other computer sold past that point supported x86_64

That is purely on Apple. It was a regression for sure. Arguments about the "consumer friendliness" of keeping 32 bit support are quaint, but it shouldn't have been possible in the first place. They had the opportunity to cut the knot in the transition, didn't, and created this situation.

Huh, never even really thought of that as an option back then. Could've been an interesting alternate timeline to see

 

[casperes1996]

Another thing is, i'm learning Python and it seems some Python libraries don't work in M1 too.

Hm. Got a specific library in mind? I'd like to do some testing. If it's an open source thing maybe I can even help fix it

 

[Analog Kid]

@beanbaguk, Let me just add, that you're putting the onus on developers, Why not put the onus on Apple for removing a compatibility layer for no reason. Would apple save money and time by removing 32 bit libraries, yes, but there is zero benefit to the consumer, but instead a higher level of impediment meaning there are now less apps that are available.

Just to spin it in this way, one million dollars to a trillion dollar company 0.0001% but to a company a 10 million dollar company its 10% Apple would have been better off imo, allowing the 32bit apps which is a consumer friendly move then just removing it and making life harder on the consumer.

In my opinion, if a developer can't be bothered to rebuild for 64bit after 5-10 years, then that application is abandonware. If they can't recompile against 64bit libraries, are they putting the effort into recompiling with security patched libraries?

 

[Zdigital2015]

The amount of software that doesn't run is all the convincing I need. Sure, you can emulate a console from the 1980s on the M1, but let's look at other emulators, shall we? Can you run PCem, which emulates an x86 Win9x era PC, on Mac? You cannot. Can you run Xenia to emulate the Xbox 360 on Mac? You cannot. Can you run PCSX2 to emulate PS2 games? You cannot (without great difficulty). Can you run RPCS3 to emulate PS3 games on Mac? You cannot. Can you run Spine, the up-and-coming PS4 emulator, on Mac? You cannot. Can you run Cemu to emulate Wii U games on Mac? You cannot. Can you run Yuzu to emulate Switch games on Mac? You cannot.

None of this software is available for the Mac. Windows and Linux only. Two operating systems which are also no longer natively available for the Mac. The only thing you get with Mac anymore is exclusive Apple software, exactly the way Apple wants it to be (don't you want to buy and use all of these perfect magical Apple products? Don't you love our harmonious ecosystem? Apple makes everything for you. Of course you want it, join us, join us now). I'll take that loss and gain immeasurable freedom and access to the rest of the software library available to the planet.

Then go and be as free as a bird…why are you even here?

 

[wyrdness]

the move to kill off 32bit apps was foolish on Apple's part, there's really no if ands or buts. Apple's draconian move to basically reduce the amount of software that can run was unnecessary and limited its customers for no reason.

Are you suggesting that Apple should still be supporting ancient 32-bit apps on their 64-bit Arm processors?

 

[GrumpyCoder]

Heck, if Apple silicon one day can emulate Intel i7-9900K and RTX 2080 with full performance I am all for it.

That is never going to happen. They might get GPU performance of a RTX2080 at some point, but full performance would include CUDA and that's where the line is drawn. Nvidia is a closed system, Apple cut off support a while ago. There were workarounds, with different backends for things like Tensorflow and PyTorch, but with Apple tightening up their eco system further and further, these are not alternatives anymore. I've never seen so many developers drop macOS support for scientific/research applications as in the past 12 months. macOS is pretty much dead at this point for this purpose unless used to connect to clusters where the work is done. It's a shame, because the M-series SoCs are great, but in the end it's the software that matters. Apple will be fine though, their target market is YouTubers, photographers and musicians now. I'm doing "productive things" on a Dell Precision with Xeon CPU and RTX8000 in the office, a i7 with Titan RTX in the home office and a Razer Blade 15 with RTX5000 now in addition to V100/A100 clusters, while my fully loaded MBP is used to browse the web and answer emails. Trying to get my hands on a Lenovo X1 Carbon in addition for lightweight travelling but would allow eGPU support in the home/office.

 

[GrumpyCoder]

Are you suggesting that Apple should still be supporting ancient 32-bit apps on their 64-bit Arm processors?

Well, it's obvious why Apple dropped support. But in the end, many businesses out there still reply on 32-bit apps and some dating even further back. So would it be a mistake to still offer 32-bit apps? No, but 32-bit doesn't fit Apples business model or target market.

 

[ADGrant]

the move to kill off 32bit apps was foolish on Apple's part, there's really no if ands or buts. Apple's draconian move to basically reduce the amount of software that can run was unnecessary and limited its customers for no reason.

Why have two computers laying around that's an odd justification. I have one Pc that can run both, and apple's move made gaming on the Mac (which was already sad) down right pathetic.

MacOS has been fully 64bit since Snow Leopard. It's not like developers have not had ample opportunity to recompile their apps. By restricting support to 64bit apps, Apple made the transition to ARM64 a bit simpler.

Microsoft OTOH, has taken forever to transition to 64bit. Visual Studio 2019 (their flagship IDE on Windows) is still a 32bit application which is absurd.

 

[ADGrant]

Alright, well I'm wrong then about the raw performance, no shame in admitting that. But it remains true that there is so very, very, very little to run on M1 processors compared to the incalculable wealth of x86 software out there.

In the iPad Pro, the M1 can run all iOS apps. It could on the Mac too if iOS developers decide to allow it.

It will take a while before all x86 MacOS software will be built for ARM but it will happen. Many applications run in some kind of VM anyway (Java, .NET or a Javascript runtime). Those runtimes have already been ported to ARM64 on MacOS.

 

[GrumpyCoder]

Microsoft OTOH, has taken forever to transition to 64bit. Visual Studio 2019 (their flagship IDE on Windows) is still a 32bit application which is absurd.

In the end, it's a text editor, so it matters little. Some components, debugger, compiler, etc. are already 64-bit. VS2019 will never be full 64-bit, that's what VS2022 is for. IDEs or at least their editor part are probably not a good choice to promote 64-bit support unless you're working on projects which are really, really large.

Then again...

 

[mi7chy]

Rebooting is such a rarity on Macs, and linux that its really a non-issue, and while my windows uptime tends to be very good, windows does benefit more from rebooting then macOS. In the end its how you use the machine, not how fast you boot up

MBA M1 has had issue that while sleeping, RAM consumption grows ending in disk swap usage which can cause premature SSD wear. Don't know if it was ever fixed but sure way to avoid it completely is by turning the device off when not in use. Anything with a battery I turn off if I don't use it for a day or two to minimize battery cycle wear. Better to fix the product deficiency rather than making the user change the way they use the product.

 

[casperes1996]

In the end, it's a text editor, so it matters little. Some components, debugger, compiler, etc. are already 64-bit. VS2019 will never be full 64-bit, that's what VS2022 is for. IDEs or at least their editor part are probably not a good choice to promote 64-bit support unless you're working on projects which are really, really large.

Then again...

I agree that it may not really matter if your text editor is 32-bit or 64-bit, it is also a bit about image and sending the right message. And WIndows needs to pull in a ton of 32-bit libraries when a 32-bit program is first loaded, increasing the memory footprint relative to an all 64-bit system. So sure, it’s not vital or anything, but there’s that song about starting with the man in the mirror, and as a major player like Microsoft, shipping 64-bit software just feels better to do and sends a better message about what others ought to do

 

[ADGrant]

In the end, it's a text editor, so it matters little. Some components, debugger, compiler, etc. are already 64-bit. VS2019 will never be full 64-bit, that's what VS2022 is for. IDEs or at least their editor part are probably not a good choice to promote 64-bit support unless you're working on projects which are really, really large.

Then again...

Yes, finally VS2022 will be fully 64bit over a decade after the world moved to 64bit.

 

[deconstruct60]

Microsoft OTOH, has taken forever to transition to 64bit. Visual Studio 2019 (their flagship IDE on Windows) is still a 32bit application which is absurd.

Absurd is probably too strong of a connotation. It is closer to be still trapped to the A20 line (as mentioned several posts ) and and several other short view, hackery from the 80's and 90's that are constipating "x86" implementations.

Take the minimal configuration 32 bit Windows OS install and put a IDE tool on there to manage some 1998 software project. That's a major contributing boat anchor . Win11 for the most part dumping 32-bit OS means finally about to cut the super old constraints boat anchor loose ( at least at the softwrae level. May take Intel/AMD a couple more years to do a 'garabage collection phase' on their end. A bit of a "chicken and egg" thing here with the transitions spread out over multiple companies. )

Most of the components doing the hard work ( compilers , debuggers , build tools , etc.) are really separate programs that the IDE just implicitly invokes (and are 64 versions of those). The "use case" example that Microsoft presented for VS 2021 is

"... To demonstrate the real-world effect of VS being a 64-bit application, Silver pointed to a GIF video showing the IDE open up a solution with some 1,600 projects and about 300,000 files: .... "

Visual Studio 2022: Faster, Leaner and 64-bit (More Memory!) -- Visual Studio Magazine

Visual Studio 2022 will be previewed this summer as a 64-bit application, opening up gobs of new memory for programmers to use. 'Here's to no more out-of-memory exceptions. 🎉'

visualstudiomagazine.com

So it is more the "project management" and GUI implementation parts that are seeing wins, more so than the basic text editor functionality. It could help with the "smarts" AI/ML parts over time.



P.S. also a small bit of the "shoemaker's children having no shoes"... It was just cheaper to do one 32 bit GUI app. Lots of money gets plowed into the other "subtools" ( compilers , etc. ) and usually are large subset of these dev tools are handed out for "free" ( so where is big revenue stream to cover the tool development. ) There are direct/indirect revenue sources to cover the dev tool ecosystem but the money tends to "trickle down" from high priority components to low priority components.

 

[kevcube]

Alright, well I'm wrong then about the raw performance, no shame in admitting that. But it remains true that there is so very, very, very little to run on M1 processors compared to the incalculable wealth of x86 software out there. This is normal right now obviously, but despite the hopium everyone's on regarding the M1, there is still going to be a staggering and permanent loss in the total capability of the Mac as a platform due to developers choosing to not port their apps (it will be this way, they are not all ready and excitedly waiting to port port port at Apple's whim... what next, dropping the Arm instruction set for an Apple custom set? It never ends), not to mention the cataclysmic loss that recently occurred due to the death of 32-bit execution already. And just wait until the Rosetta 2 death hammer comes down. Macs are fast becoming the computer to run essentially Apple pro apps and Photoshop/Illustrator and not much else.

M2 comes out: Well guys... we could... test Photoshop again?

does your workflow not work on M1? I'm a professional using one and I've got no compatibility issues. I just rejoice in the amazing battery life and never-turning-on fans.

I find anyone who complains about these machines just doesn't own one.

 

[Bandaman]

the move to kill off 32bit apps was foolish on Apple's part, there's really no if ands or buts. Apple's draconian move to basically reduce the amount of software that can run was unnecessary and limited its customers for no reason.

Why have two computers laying around that's an odd justification. I have one Pc that can run both, and apple's move made gaming on the Mac (which was already sad) down right pathetic.

Microsoft just killed 32-Bit support with Windows 11 as well as cutting off millions of PCs. What's your point? 32-Bit is officially dead on both platforms.

 

[kevcube]

don't fall for the hype

This is windows half-asleep mode. If you click "restart" in the windows power mode then it does a full power cycle with longer boot times, which would match the Mac.

 

[Bandaman]

does your workflow not work on M1? I'm a professional using one and I've got no compatibility issues. I just rejoice in the amazing battery life and never-turning-on fans.

I find anyone who complains about these machines just doesn't own one.

Same here. It has changed my workflow and my ability to work away from a power outlet forever. The battery life is ridiculous on top of it not losing performance when unplugged is a massive plus.

 

[kevcube]

You can't natively use Windows. You can't (actually) use Linux. You can't run 32-bit Mac apps or games. In a year or two you cannot use x64 Mac apps or games. You just reduced your ability to run the world's software library by a very likely 99% compared to a Mojave Intel Mac.

But hey, Photoshop. Final Cut Pro. iPad apps. Cool.

I'm 'actually' using linux by virtualizing the linux kernel for use with docker...

 

[darngooddesign]

"But it remains true that there is so very, very, very little to run on M1 processors " Just got my M1 MBP, I know little late to the party, but my old MBP is still working great (2014, MPB 15 2.5 GHz i7). My new laptop is the absolute most incredible laptop I have ever used. and guess what? It runs everything I use!

Sure some could claim there is a this or that that is not available, and if you use them, well, its a done deal for you. BUT THIS IS THE OST INCREDIBLE LAPTOP I HAVE EVER USED AND IT RUNS EVERYTHNG I USE!

Thank-you and good night

Hey, if you literally just got your new MBP you might consider returning it and waiting a month as the new MBPs are due imminently. If you knew about them but dont care then please disregard my comment.

 

[kevcube]

Hm. Got a specific library in mind? I'd like to do some testing. If it's an open source thing maybe I can even help fix it

yeah go fix apache arrow for me please ?

 

[deconstruct60]

Yes, finally VS2022 will be fully 64bit over a decade after the world moved to 64bit.

Did it?

Back in 2017 Intel announced it was dropping BIOS support in 2020.

Intel to Remove Legacy BIOS Support from UEFI by 2020

www.anandtech.com

EFI had some traction in the early 2000's but tried to leave BIOS behind.

UEFI - Wikipedia

en.wikipedia.org

UEFI was a adjustment to get more buy in but one of the offerings to get more buy-in was BIOS compatibility mode being required. 2005-2007 took a while for UEFI to settle down to very broad adoption. 2007 -> 2017 so 10 years to get to point Intel is willing to say going to turn transition mode off.

Kind of hard to dump odd-ball, 32-bit hackery when dragging it along in the basic boot mode of the system.

Yes, there is a solid, substantially large base of 64 bit code dating from around 2006-now . There is lots of more than 10 year old code out there to support as "legacy" and a substantial set of 15 year old code. There is large movement on some fronts , but on others there is a ton of hyper "ain't broke don't fix-it" , risk adverse folks out there also.

 

[bousozoku]

Most of you guys probably don't remember when computers were first hitting the consumer market. Back then coders had to have really have strict coding practices as they didn't have the luxury of memory and fast processors. From what I read ARM M1 chips go back to basic assembly language (machine language) and today's coder's are not used to think in this manner. What I mean they didn't have to worry about too much about having tight code. Well, at least this is my opinion. This is also Apples first generation of the M1 and all the developers are getting used to this new architecture. Programmers also have to take all the old code and convert it natively to the M1.

Just have to add, good programmers write good tight code anyways. You can make any computer that is a speed demon a slow poke with poorly writing Operating Systems and Applications.

Coders today worry more about the problem than the constraints.

My first 8-bit computer in 1981 had 16 KB of RAM and no disk space. My first "large" computer (in 1983) had 384 KB of RAM and 256 MB of disk space and used 30 dumb terminals. Both had maximum 64 KB blocks but the commercial machine supported 8 MB of virtual memory.

Until the late 1980s, I had never written a single program module that took over 64 KB but I had multiple modules to a single application.

While there are a lot of sloppy developers, many are dependent on the compiler's code quality. Right now, there aren't a lot of choices, and languages like Swift do things differently anyway.

 

[darngooddesign]

In the iPad Pro, the M1 can run all iOS apps. It could on the Mac too if iOS developers decide to allow it.

iOS dropped 32bit support in iOS11.

 

[GrumpyCoder]

I find anyone who complains about these machines just doesn't own one.

Not a smart thing to say. Run these then report back how well they work on M1:

• https://docs.nvidia.com/isaac/isaac/doc/index.html
• https://carla.org/
• https://github.com/stepjam/RLBench

Hint: you won't have any luck. So really the people not complaining about M1 are the ones that have limited use cases, those that work on the M1.