M1 Macs?

[Daniel Brogan]

Has anyone run Golden Cheetah on one of the new M1 Macs? Any issues? How’s the performance? Is a M1-native build in the offing? Thanks.

[Mark Liversedge]

I would really like to do an M1 build, it really depends what infrastructure Travis offer.

Mark

[raf...@tfrank.de]

Oh yeah, please do an M1 build! That would be great! :)

[raf...@tfrank.de]

Hi Daniel,

just installed the latest developer built for all on my M1 Macbook Pro. 

Issueless install.

Upon first start and selecting my athlete history it went unresponsive and all fans maxed out for around 3 to 5 mins while it was apparently ingesting my complete history, ranging from 2012. But then it came on again issueless.

Performance is nice. Haven't done much in it yet, though.

Currently trying to decide whether I like that new build. On first default startup design, the mac version looks garish.

After a quick change of the default font inside the preferences and some colour arrangements it looks nice. But I have my gripes with the new  activities details page. Lots of clutter I don't need (change history, several long technical sensor ID, internal filenames, my own name) all stuff that distracts a self trained athlete as well as a trainer (sans the athlete name) supervising several atheletes from the real info on that page. That is date, RPE, and notes at the foremost.

And I often use and edit in the raw table. That ones screen real estate got cut by having it as a separate sub pane in the details pane rather than it's own complete pane...

[Ale Martinez]

El jueves, 24 de diciembre de 2020 a la(s) 12:37:42 UTC-3, raf...@tfrank.de escribió:

Hi Daniel,

just installed the latest developer built for all on my M1 Macbook Pro. 

Issueless install.

Upon first start and selecting my athlete history it went unresponsive and all fans maxed out for around 3 to 5 mins while it was apparently ingesting my complete history, ranging from 2012. But then it came on again issueless.

This is due to full metrics recomputation on upgrade, but unresponsiveness meanwhile is fixed in current snapshot build (remove temp/Cache contents if you upgrade).

 

Performance is nice. Haven't done much in it yet, though.

Currently trying to decide whether I like that new build. On first default startup design, the mac version looks garish.

After a quick change of the default font inside the preferences and some colour arrangements it looks nice. But I have my gripes with the new  activities details page. Lots of clutter I don't need (change history, several long technical sensor ID, internal filenames, my own name) all stuff that distracts a self trained athlete as well as a trainer (sans the athlete name) supervising several atheletes from the real info on that page. That is date, RPE, and notes at the foremost.

In v3.6 Data Fields configuration is global, during upgrade a metadata.xml file in GC home is built from config/metadata.xml from all your athletes, is easy to fix selecting config/metadata.xml from your preferred athlete and copying over metadata.xml on the parent folder when GC is closed, then restart.

[raf...@tfrank.de]

With the newest snapshot from 27th of December the unresponsive part was solved. The "symptoms" upon first start were the same, though.

From the very start the fans went maximum on my M1 Macbook Pro. Which is very unusual for this machine since Apple apparently not only has very "cool" (hehe) Silicon but also has a preference of starting the fans only after the machine is truly warmed up by minutes (as in... 10 t0 20 minutes at least) of real high computing loads.

So... blasting the fans from the get go is something which should warrant looking into the ingesting code of 3.6. Why can I say that?

Because today I decided to stop my looking into the state of 3.6 and finally install 3.5 for the first time on my M1 macbook and go start doing productive work with GoldenCheetah again. 

Lo and behold: the ingestion of my 1500 activities went even a bit faster (didn't stop either time but 3.5 seemed significantly faster) and: my machine stayed completely silent. CPU load was even higher on 3.5 than on 3.6. 

Nothing too tragic, since ingesting takes place but once. But - I would think there could be underlying issues in the 3.6 code which would warrant looking into nevertheless. 

Here two screenshots for what it's worth:

1.) GC 3.6 snapshot 27th Dec with fans top speed and max cpu usage 630 % (look at the "Reaktivierungen" metric).

2.) GC 3.5, cpu usage 730 %, and interestingly a bit more GPU %, no fans (as ususal on the M1 macbook)

[Ale Martinez]

What “ingestion” means to you in this context, what are you doing exactly, i.e. are you importing activities (from which format) or restoring a backup (taken from which version)?

[raf...@tfrank.de]

Hi Ale,

what I did in the following order:

1.) Copy my complete GC folder from old machine to new machine

2a) Download Developer Release 3.6 from GoldenCheetah.org (altough there it reads June 2020 and I guess I had a later one? But not the Snapshot, maybe I used a link from this group). 

2b) Open GC 3.6 for the first time (and the first GC on that new machine). Got prompted to make a new user first thing. Made a user named "dummy" and didn't do anything with it.

2c) navigated to the preferences and there to the first Tab "Allgemeines" (in German) and pointed athlete and workout library to my GC directory

2d) unsure about the exact course of next events. I guess I had to close GC, open it anew, got prompted for the sole athlete there is in this directory, i.e. me. Selected it and then the fans went on and GC was shown as "not responding" in the activity monitor. But ingested all activities just fine after some minutes of fan blaring.

So no - no Backup. Just a normal GC folder and a fresh "install" on a new machine.

3a) Downloaded the 3.6 snapshot from the 27th of December. And just copied it over into the programs folder over the former 3.6 June or Nov Developer Release.

3b) opened that incarnation for the first time. Hadn't to select an athlete, had'nt to point to the library. Ingestion took place. GC stayed responsive, a progressing progression bar could be followed on the top area under the menu bar like shown in the first screen shot. Fans were maxed out from the get go. 

So yes, the latest snapshot solved the "not responding" issue but it may still have some issues left over which may lead to that behaviour? Granted, it runs under Rosetta 2 and all but... as does 3.5.

4a) renamed GoldenCheetah to GoldenCheetah36 in my programs folder

4b) downloaded 3.5 current stable release and installed it.

4c) opened 3.5 for the first time on the new machine. No need for selecting an athlete. Program started with ingesting all 1500 activities. With the progression bar progressing (just like the former snap shot 3.6 version) and subjectively quicker, with higher shown CPU usage (see screen shot) and no fans at all.

Hope this helps. :)

cheers,

Torsten

[Ale Martinez]

El miércoles, 30 de diciembre de 2020 a la(s) 11:41:04 UTC-3, raf...@tfrank.de escribió:

Hi Ale,

what I did in the following order:

1.) Copy my complete GC folder from old machine to new machine

2a) Download Developer Release 3.6 from GoldenCheetah.org (altough there it reads June 2020 and I guess I had a later one? But not the Snapshot, maybe I used a link from this group). 

2b) Open GC 3.6 for the first time (and the first GC on that new machine). Got prompted to make a new user first thing. Made a user named "dummy" and didn't do anything with it.

2c) navigated to the preferences and there to the first Tab "Allgemeines" (in German) and pointed athlete and workout library to my GC directory

2d) unsure about the exact course of next events. I guess I had to close GC, open it anew, got prompted for the sole athlete there is in this directory, i.e. me. Selected it and then the fans went on and GC was shown as "not responding" in the activity monitor. But ingested all activities just fine after some minutes of fan blaring.

So no - no Backup. Just a normal GC folder and a fresh "install" on a new machine.

3a) Downloaded the 3.6 snapshot from the 27th of December. And just copied it over into the programs folder over the former 3.6 June or Nov Developer Release.

3b) opened that incarnation for the first time. Hadn't to select an athlete, had'nt to point to the library. Ingestion took place. GC stayed responsive, a progressing progression bar could be followed on the top area under the menu bar like shown in the first screen shot. Fans were maxed out from the get go. 

So yes, the latest snapshot solved the "not responding" issue but it may still have some issues left over which may lead to that behaviour? Granted, it runs under Rosetta 2 and all but... as does 3.5.

4a) renamed GoldenCheetah to GoldenCheetah36 in my programs folder

4b) downloaded 3.5 current stable release and installed it.

4c) opened 3.5 for the first time on the new machine. No need for selecting an athlete. Program started with ingesting all 1500 activities. With the progression bar progressing (just like the former snap shot 3.6 version) and subjectively quicker, with higher shown CPU usage (see screen shot) and no fans at all.

I see, but it it looks like comparing pears to apples to me, full cache metric recomputation is required when you use your v3.5 data folder with v3.6 the first time, which is not required if you use the same version.

BTW, don't use your upgraded v3.6 data folder with v3.5 for any reason, reload the v3.5 data folder if you want go back, bad things happens otherwise s.t.: https://github.com/GoldenCheetah/GoldenCheetah/wiki/FAQ-MOST-COMMON-QUESTIONS-OF-ALL#Why-are-my-charts-blank-or-data-is-missing

[Eric Christoffersen]

And about the fans running...

When a program is really tearing it up and making great use of a machine to do work, it generates maximum heat. More work means more heat. Restricted programs hit a bottleneck and then run slow and cool, and take longer to complete. So there's a perspective where getting fans to run is a high achievement. Since you don't know that same work is done, all you can deduce by the fans running is that something in gc init is expressing work to your laptop in a very nice way. :)

I actually profiled that slow 3.6 startup a few months ago. It is running a bunch of threads in parallel doing quite a bit of redundant work. It certainly could be made faster but fixing it would be a lot of typing though and its pretty much a one time cost so not really worth it to me.

[pepe]

A option to set  CPU Priority for GC when doing full databases re/computations and other intensive tasks would be a great thing to have, as full cache metric re-computation can slow my system to a crawl  with near 100% CPU Time.

[raf...@tfrank.de]

Ah, "full cache metric recomputation" you call it. Yes, that makes sense. That's what I meant with "ingestion". 

And thanks for the recommendation to use the old folder. 

[raf...@tfrank.de]

Hi Zak,

I see. Yeah... initially I thought the same about the fans going full tilt. I even half-jokingly tweeted about this in the following way: 

"Haha, all those Benchmark amateurs... the fastest way to max out the fans of a M1 Macbook Pro? Open a freshly installed #GoldenCheetah and have it ingest 1500 activities... 650 % CPU usage... ^^ I kinda think I should be impressed by GC to use all the brute force the machine has."

But then... as I said:

a) having a program causing the fans go nuts from the get go even before the cpu could develop any rising heat to cause said fans picking up shows there is something fishy. Even more if you consider the new M1 apple chipset. I don't know if you are already familiar with them but they are a completely different beast compared to anything I (and the whole computing world) basically had until now. And they certainly can't really compared with former intel based macs or especially intel based mac and windows notebooks. Really no other app from hardcore game to letting Adobe Lightroom (also under rosetta 2) ingest or export gigabytes worth of RAW photo batches does this (but does on intel based macs or pcs).

and b) Even if one could still be wary since the GC code on M1 macs is running under Rosetta 2 and as astoundingly widespread glitchfree (and still faster than on intel chips) running nearly all apps (sans a few plugins for video editing programs and such) this is - one could still hold this in favor towards GC 3.6.

But... the 3.5 version doesn't show this. No fans whatsoever. And it's running under Rosetta 2 just like 3.6.  And it seems even quicker. But I haven't really timed this since that wasn't of particular interest to me.

What is really of interest to me is a completely other thing: the time it needs to open GC. Also here I didn't timed this. But it seems like there is no real improvement here when I compare GC 3.5 on my new M1 macbook to my older early 2015 macbook. 

I still see that small white rectangle in the middle of the screen, hurrying to 100%. Maybe on the M1 mach it's already mostly at 100% when it appears. It then still takes some short but distinct and slightly to long moment (depending on my state of mind it seems to take ages) for the GC Window to appear...  And on my old machine it was a intel core i5 and an older slower SSD while on the M1 macbook it's said M1 chip and a blazing fast SSD.

cheers,

Torsten 

[Eric Christoffersen]

Fishy: yes I agree. The thing about the gc ingestion is that its doing a whole lot of nothing with a ton of data on as many threads as it can. Its a stress for memory and storage, absolutely thrashing all the buses. So memory controller and storage controllers are probably getting nuked. The fact that fans go nuts indicates that apple's firmware is set too aggressively. The fans running full blast is a situation the system is trying hard to avoid, never wishes to find itself.  I've worked on systems that did exactly this. We had programs hand crafted by the hardware team, specially designed to stress every component in the pipeline and still every year or so some dumb coincidence in a user program would find something better than we thought was possible. It was always some program doing a whole lot of nothing in a certain way that caused the crisis, bypassing the usual bottlenecks to drive a hardware component too hard. We'd add it to our benchmarks and find some way in the power firmware to dial back the system so it didn't go there -  without hurting perf of programs we cared about. The thing we never told people was that their program was the problem. Their program might be dumb but was our job to manage temperature.

3.5/3.6: I haven't looked at what the differences are between ingestion on 3.5/3.6. Lots of stuff changed, lots of bugs fixed. I can't say whether one should be faster than the other. If you really care run a profiler and discover facts.

I think the real issue with ingestion is that we're running n-passes over all the data of every activity. The passes are written to run that way but would be better if they were written as transforms that could all act on a smaller state. That would have n-filters running in a single pass. A single pass would mean much more compute brought to bear per unit of memory accessed.

In the end though... how often are you guys seeing this? Its a one time cost right? I'd care about perf if it was daily but right now for me its more like 'never'.

[Stuart Kreitman]

I attempt to launch 3.5 on an up to date Macbook Air M1 and get the following error:  

   "GoldenCheetah" cannot be opened because the developer cannot be verified.

  macos cannot verify that this app is free from malware.

afaik the only download provided is x64 which others here have successfully run on M1.

I am relatively new to macos and completely new to M1 and rosetta. (Is "ingestion" the word for Rosetta translation process?)

If you have advice on this, please put it at a basic level of understanding.

In the meantime, I've assembled a build environment and the tools xcode and qt, but still working through learning curve.

Thanks,

Stuart

[Ale Martinez]

El lunes, 15 de febrero de 2021 a la(s) 12:10:35 UTC-3, stuart....@gmail.com escribió:

I attempt to launch 3.5 on an up to date Macbook Air M1 and get the following error:  

   "GoldenCheetah" cannot be opened because the developer cannot be verified.

  macos cannot verify that this app is free from malware.

afaik the only download provided is x64 which others here have successfully run on M1.

I am relatively new to macos and completely new to M1 and rosetta. (Is "ingestion" the word for Rosetta translation process?)

If you have advice on this, please put it at a basic level of understanding.

This is not specifically related to GoldenCheetah, you should look at macOS documentation, s.t. https://support.apple.com/en-us/HT202491 

[Karl Billeter]

On Thu, Dec 10, 2020 at 08:12:16AM -0800, Daniel Brogan wrote:
> Has anyone run Golden Cheetah on one of the new M1 Macs? Any issues? How’s
> the performance? Is a M1-native build in the offing? Thanks.

Finally upgraded laptop. Much faster under Rosetta2 than native
architecture on my 2012 MacBook Air :-)

Built-in Python works fine. For R, I downloaded an x86 R build from
https://mac.r-project.org/ and that works too — as long as you remember
the right-click open/install trick for non-signed software.


K