Support for M1-based Macs?


zendnez

Recommended Posts

54 minutes ago, jdrch said:

M1 Macs run x86 code just fine transparently via Rosetta 2 with very little performance penalty (or at least none that you'd notice in an app like Resilio Sync.) So just what's already there.

I'm not clear if you are representing Resilio on this or just sharing an opinion. Can you clarify, please?

We don't yet have clear benchmarks regarding battery consumption of emulated apps vs native apps. On my machines, Resilio tends to use a consistent 0.7% CPU. That's not a huge amount and I'm not in a position to claim definitively that a native app will use less, but power management is certainly one of the reasons that apps will go native over time.

In any case, I'd love to hear from the source.

Link to comment
Share on other sites

9 hours ago, luomat said:

 

Be that as it may, I still hope the the app will be updated for actual M1 support rather than relying on Rosetta 2.

 

 

The iOS build supports the M1 natively. The entire point of Rosetta 2 is the same as that of WOW back in the day and WOW64 today: to enable unmodified binaries compiled to target a different instruction set to run with no penalty on the host OS. From the M1 reviews I've read, Rosetta 2 handles this perfectly. From a performance perspective, you're not gonna gain a whole lot from a native build anyway because literally the toughest thing Sync does from a CPU perspective is hash files, which even the slowest current gen CPUs handle easily. The limiting factor in Resilio Sync workload performance will almost always be network speed, not CPU execution.

But you don't have to take my word for it. Per AnandTech's M1 review (emphasis mine):

Quote

Generally, all of these results should be considered outstanding [...] [Rosetta 2] is [...] a full-fledged compatibility layer that when combined with the outstanding performance of the Apple M1, allows for very real and usable performance of the existing software application repertoire in Apple’s existing macOS ecosystem.

 

9 hours ago, zendnez said:

I'm not clear if you are representing Resilio on this or just sharing an opinion. Can you clarify, please?

We don't yet have clear benchmarks regarding battery consumption of emulated apps vs native apps. On my machines, Resilio tends to use a consistent 0.7% CPU. That's not a huge amount and I'm not in a position to claim definitively that a native app will use less, but power management is certainly one of the reasons that apps will go native over time.

In any case, I'd love to hear from the source.

The only people who represent Resilio are the ones with Sync Support, Admin, etc. around their profile pic. Staff don't automatically respond to everything. Assuming you have a paid license, the best way to get their direct attention is to file a ticket. I'm speaking purely on the basis of having used Resilio Sync as the backbone of my own personal IT workflow since 2014.

If you really want native code right now, use the iOS build, which AFAIK runs natively on the M1.

As for future plans, from what I gather reading posts on here, Resilio Sync macOS (I don't own a Mac, but plan to get an Apple Silicon one as soon as it fits into my budget) support isn't exactly the strongest of the OSes it supports (that would be Linux & Windows, from my firsthand experience); mostly because some of the OS' design and restrictions hinder its intended functionality. Search the forum for "macOS" to see for yourself. Personally I've been waiting for an Illumos port forever. That said, Resilio Sync's combined OS and platform support is the widest of any competing solution and possibly the widest of any 3rd party application I've encountered. I count 15 builds per release at that last link. 16 if you include the iOS build that's not on that page.

TL,DR: There's reason to be optimistic about a native build in the medium to long term, but I wouldn't expect one in the short term. If you want to speed up the process, file a ticket about the lack of an Apple Silicon build.

Link to comment
Share on other sites

Thanks for the response. I addition to the outstanding question about if/when we can anticipate a universal binary from Resilio, you bring up a bunch of fun topics.

The comparisons to WOW/Wow64 aren't quite accurate, though they did both address a similar scenario in which an operating system and/or processor architecture evolved and app compatibility was maintained. WOW/WOW64 were thin layers that did things like shim OS API calls, fiddle without pointers, and flip the OS (in some cases) between 32-bit and 64-bit mode since X64 processors were designed with that capability.

Rosetta 2 is different. It derives from the earlier instance of Rosetta which facilitated Apple's processor transition from PowerPC to x64. Rosetta was at least partially informed by the work Apple did to transition from Motorola 68k to IBM PowerPC. Back when that happened in the mid 90's, none of us thought it would work but Apple pulled it off. Initially with a very brute force emulation strategy (emulating not just 3rd party code but large portions of MacOS itself) and, not long after, with their "dynamic recompilation" emulator which seemed like total science fiction to most of the industry. If you're looking for a fun history lesson, take a peek at https://en.wikipedia.org/wiki/Dynamic_recompilation. In other words, it's not about supporting the evolution of an architecture, it's about getting code to run on a completely different architecture. I don't know the extent to which it does this via one-time recompilation (and caching on disk) versus runtime translation versus a combination of both (which I think is probably closer to the truth).

I haven't checked to see if the iOS app for Resilio is available in the MacOS app store. Unless they actively blocked it, my understanding is that it will be. But I don't think it's a legitimate alternative to the MacOS version - iOS apps run as sandboxed on MacOS as they do on iOS. I suspect it'll sync a file structure in its own sandbox which isn't really what we need.

Emulation is awesome. It gets stuff running. I have a new MacBook Air and I can attest that the early reports about its performance are spot on including native and emulated code. I don't have enough time with it to state with confidence that the emulated Resilio app works flawlessly. Microsoft had to ship an update to Office just to get it to work. Google had to ship Chrome for the same reason. Microsoft's Edge beta channel works, the release channel doesn't. The issues that apps have won't necessarily prevent launch - they can cause other issues. So, minimally, it's worth it for every software vendor to vet compatibility, update if necessary, and share longer term support plans.

Anyhow, fun conversation and the kind of thing that would likely be even more fun to chat about over a beer. At some point, I'd still love to hear from Resilio on their thoughts and plans!

 

Link to comment
Share on other sites

  • 2 weeks later...
12 minutes ago, Nick Artman said:

+1 on this.  Apple's adoption of the ARM based processor will only increase and will need addressed at some point.  I am not familiar with the frameworks involved, however is this something that will require a ground-up rebuild, or just a recompile?

They need to build a Universal Binary using Xcode 12. So, minimally, an Xcode update, build config changes, and a recompile. Could be more complex depending on their dependencies, how many binaries they produce, any x64-specific hand-coded optimizations.

Essentially, though, it's this: https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary

Link to comment
Share on other sites

On 11/18/2020 at 7:24 AM, jdrch said:

The iOS build supports the M1 natively. The entire point of Rosetta 2 is the same as that of WOW back in the day and WOW64 today: to enable unmodified binaries compiled to target a different instruction set to run with no penalty on the host OS. From the M1 reviews I've read, Rosetta 2 handles this perfectly. From a performance perspective, you're not gonna gain a whole lot from a native build anyway because literally the toughest thing Sync does from a CPU perspective is hash files, which even the slowest current gen CPUs handle easily. The limiting factor in Resilio Sync workload performance will almost always be network speed, not CPU execution.

But you don't have to take my word for it. Per AnandTech's M1 review (emphasis mine):

 

The only people who represent Resilio are the ones with Sync Support, Admin, etc. around their profile pic. Staff don't automatically respond to everything. Assuming you have a paid license, the best way to get their direct attention is to file a ticket. I'm speaking purely on the basis of having used Resilio Sync as the backbone of my own personal IT workflow since 2014.

If you really want native code right now, use the iOS build, which AFAIK runs natively on the M1.

As for future plans, from what I gather reading posts on here, Resilio Sync macOS (I don't own a Mac, but plan to get an Apple Silicon one as soon as it fits into my budget) support isn't exactly the strongest of the OSes it supports (that would be Linux & Windows, from my firsthand experience); mostly because some of the OS' design and restrictions hinder its intended functionality. Search the forum for "macOS" to see for yourself. Personally I've been waiting for an Illumos port forever. That said, Resilio Sync's combined OS and platform support is the widest of any competing solution and possibly the widest of any 3rd party application I've encountered. I count 15 builds per release at that last link. 16 if you include the iOS build that's not on that page.

TL,DR: There's reason to be optimistic about a native build in the medium to long term, but I wouldn't expect one in the short term. If you want to speed up the process, file a ticket about the lack of an Apple Silicon build.

"The iOS build supports the M1 natively."

That's not what "natively" means. You're using it wrong. Don't.  At best, I think you meant "compatible". As you state later, it's using emulation. 

"literally the toughest thing Sync does from a CPU perspective is hash files, which even the slowest current gen CPUs handle easily."

WHAT? Each CPU generation is faster for encryption (they literally move things that were in done in software in previous generations and turn it into hardware that runs much faster) and makes a big improvement over each generation. Your statement either needs a bunch of modifiers or its simply silly.  Improving what would be the biggest processing obstacle for the CPU is a gain.  They're also encrypting files (lan_encrypt_data=true is default setting). But I'm arguing about CPU hardware. I have no idea about what M1 does implement in hardware over previous Intel chips, but they sure have harped on about how they have their security engines on chip, and so on.

"The limiting factor in Resilio Sync workload performance will almost always be network speed, not CPU execution."

That has NEVER been my experience and I'm curious why you'd even think that unless you only operated over very slow links. I've NEVER been able to max out network connections (I have 10Gbe at home with NVMe drives, big raids, running on AMD 2920X Threadrippers, 32GB RAMDisks, etc) and there is clear resource optimizations they need to do to improve high speed syncing (ie, interrupt handling, not running their terrible debug logging, etc). I'm like gobsmacked by your statement, as there are many, many people on the forums who have asked over the years why the sync speed is no where near their network limits.  CPU and especially Disk I/O are bottlenecked WAY, WAY, WAY before network speeds are.

Link to comment
Share on other sites

Quote

That's not what "natively" means.

See Wikipedia for yourself:

Quote

Something running on a computer natively means that it is running without any external layer

AFAIK iOS apps don't need external layer to run on Apple Silicon macOS.

Quote

As you state later

I was referring to Rosetta 2 running x86-64 macOS apps on Apple Silicon macOS. I thought that was obvious, my bad.

As for the rest of what I said, I run Sync on 11 devices ranging from a lowly Galaxy S5 to a 4C/8T desktop. I haven't noticed Sync run any faster on one than the other. All my changes sync instantly and since I'm always syncing the same folders, the only time a device syncs from scratch nowadays is when I 1st set it up.

I've also been able to saturate my gigabit network connection using Sync.

Clearly your setup is far more expensive than mine, all props to you.

Link to comment
Share on other sites

3 hours ago, jdrch said:

See Wikipedia for yourself:

AFAIK iOS apps don't need external layer to run on Apple Silicon macOS.

I was referring to Rosetta 2 running x86-64 macOS apps on Apple Silicon macOS. I thought that was obvious, my bad.

As for the rest of what I said, I run Sync on 11 devices ranging from a lowly Galaxy S5 to a 4C/8T desktop. I haven't noticed Sync run any faster on one than the other. All my changes sync instantly and since I'm always syncing the same folders, the only time a device syncs from scratch nowadays is when I 1st set it up.

I've also been able to saturate my gigabit network connection using Sync.

Clearly your setup is far more expensive than mine, all props to you.

Oof. Did you not read the very first paragraph you linked to? And then the second paragraph gave an exact example of emulation, allowing a binary written for gameboy to be played on other processors.

"In a more technical sense, native code is code written specifically for a certain processor.[1] "

That would be x86_x64 native. Arm (the M1 CPU) is not. That first sentence is an over simplification and I would argue it doesn't belong there (nobody talks "native" code when building debs vs rpm's, because they build to architects, the CPU'S). 

Also, calling bullshit on you saturating your gigabit network. 

Do a simple file copy over the network and monitor it to see you're consistently above 950Mbps for the transfer. 

Now do the same with Resilio. Tell me if it's closer to 300Mbps or 600Mbps.

So now your argument is that YOU run very low CPU devices but don't sync enough to see peak performance issues. No difference between a phone and desktop? C'mon now, don't be silly. If you used the Android app with any decent amount of files, you'd know how wrong you are.

Resilio is nice for the hands off syncing, but there's lots of performance improvements to be made. They seem to have a lot of platform support but no QA, which means testing and optimization doesn't happen (have you tried running on 512MB RAM NAS?). Desktop developers are not the same as embedded developers that operate on smaller resources and operate more efficiently. There's likely various buffer settings and what not to tune, etc.

Anyway, in the future, I'll likely use rsync for initial sync as Resilio just wasn't transferring near what it should have been. Rsync recently added improved compression and a noticeable speed improvement. 

Link to comment
Share on other sites

Look man, this a discussion forum about Resilio Sync, not a computing seminar. I said what people who want an Apple Silicon build should do. If you want one, do that. Arguing with me about what is and isn't native isn't going have any impact on what Resilio does, so I suggest you direct your effort towards what you want instead of trying to win an internet conversation.

Link to comment
Share on other sites

4 minutes ago, jdrch said:

Look man, this a discussion forum about Resilio Sync, not a computing seminar. I said what people who want an Apple Silicon build should do. If you want one, do that. Arguing with me about what is and isn't native isn't going have any impact on what Resilio does, so I suggest you direct your effort towards what you want instead of trying to win an internet conversation.

So, when you give out incorrect info, get called out on it, this is how you respond? Without knowledge or experience, who are YOU to be telling what others want? They have the laptop, they have battery and processing issues), and they are looking for an ETA for that build. You're offering NOTHING OF VALUE telling them that there is no benefit to a native build. You don't know that.

"compiled to target a different instruction set to run with no penalty on the host OS. From the M1 reviews I've read, Rosetta 2 handles this perfectly."

You were 0/2 in that. There is ALWAYS a penalty in emulation (just different amounts) and no, Rosetta 2 does not handle this perfectly. There HAD to be major updates for major software for it to even work. There still isn't Adobe programs that will run.  I don't know what reviews you've read, because all of them will have caveats. You do know that Apple has been carefully picking and choosing the advertised benchmarks, right? Every new release is a smoke show hiding problems until they get worked out. Look it up, they gaslight you into thinking there is no problem, despite overwhelming evidence to the contrary (see the various class action lawsuits).

I'll sum this up in saying, you don't know what you're talking about, are not qualified to tell other people what's what, and what you say will not influence Resilio's decision to build native or not.

 

p.s. newsflash, this is a discussion forum and this is ON TOPIC. If you thought otherwise, you have made the mistake and should show yourself out.  You don't handle being told you're wrong very well instead of using it as a learning moment. That's unfortunate.

Link to comment
Share on other sites

@jdrch - I don't understand what horse you have I this race but you are digging in on mis-informative posts.

I started this thread with the intent of asking about the timeline for an M1 build. Your suggestion to run the iOS build isn't helpful. Not only is such an option not available (Resilio hasn't published a Catalyst based build to the App Store) but it's just not going to behave the right way. So please stop promoting the notion that it's an option. It's not.

As @muse points out above, the few diagnostics we have to help us understand how the Intel / Rosetta version runs suggest that there is room for improvement. Batter consistently lists Resilio (and often only Resilio) as the significant user of energy on my Air even when no inbound or outbound sync is occurring. Activity monitor similarly shows Resilio using significant energy. Compared to other sync apps such as DropBox or OneDrive, Resilio has always run hot. But this behavior - just anecdotally and without the tools to truly understand - looks worse. It's easy to guess that whatever combination of polling and file system notifications are being used is hitting longer, more expensive codepaths due to Rosetta.

I see Resilio consume a constant 5.0+% CPU (assume that means a core) is pretty unexpected. I'm running the M1 targeted version of Outlook (a beta) and even that app stays at a pretty constant 0.5%.

I do hope to see some comment or progress on this from Resilio. BTW - I am a paying (and generally very happy) customer.

 

260364065_ScreenShot2020-12-06at3_07_37PM.png.083be64cd662206040c3833117494a5d.png266912501_ScreenShot2020-12-06at3_09_15PM.thumb.png.179ff2a0dd1563dd7b8663c7aa1a56be.png

 

Link to comment
Share on other sites

Right… For most people, "native" on MacOS would mean a desktop application, compiled to the correct architecture. If it's running translated/emulated, or it's not the desktop application, it wouldn't count as "native" in a strict sense of the word.

Compare, would users of Outlook, Lightroom, Photoshop, or any other app be happy with the answer "just get the mobile app"?

With all that said, Resilio Sync hasn't historically received updates very quickly, even when the architecture wasn't changed, so we might have to sit tight for a while for a native build.

Link to comment
Share on other sites

FWIW I have an M1 MacBook, and Resilio isn't too bad for me. I'm seeing CPU under 2% and it's not registering as high battery usage, so it may depend somewhat on your usage.

It should also be noted that Dropbox, which is a much much much larger company still does not have an Apple Silicon build yet, nor do they have any public comments about when one will be available. In fact, earlier builds of Dropbox failed entirely on Apple Silicon.

So, while I hope that there is an Apple Silicon native build coming, I'm willing to give them a little time.

Now, if we get to the end of Jan / Feb and still haven't heard anything, then making some noise seems more reasonable.

Link to comment
Share on other sites

@tjluoma Thanks for your always thoughtful comments. I agree we need to cut the Resilio team some extra slack for being much smaller than the "big guys". Throw the joys of 2020 on top of that and the slack on that rope should double at least.

It's clear to me and to a lot of other power users that Resilio Sync is a superior technology vs the bloated stuff from the big cloud companies like Google Drive, Dropbox, OneDrive etc. With the added benefit of privacy. Which is why I continue to stick with it for now.

BUT that being said, it would go a LONG way towards restoring confidence in this amazing (but, let's all be honest, very much stalled) product if the devs would pop in here once in a while and give us a "hey we're alive, yes we're working on X,Y,Z and it's looking like a summer 2021 timeframe". The silence is deafening and I think that more than any performance issues or minor bugs, is what's got some of us worried.

Link to comment
Share on other sites

  • 1 month later...

Resilio Sync is constantly hanging after some time and the process does neither sync properly anymore nor is it possible to regularly quit the application. In Activity Monitor, the process is shown running with 100% CPU and must be killed manually to relaunch.

In the current form, Resilio Sync is at best unreliable and most unusuable on my Mac mini M1.

I have attached a spindump. 

Spindump.txt

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.