report-stories

Der M1 Max Chip im Daily Doing eines Android Developers

Unser Android Developer Benny hat den neuen M1 Max Chip auf Herz und Nieren geprüft

von  Benny Schneider
08.06.2022

Hi, ich bin Benny, Mobile Entwickler und habe ein Problem …

Ihr Mobilisten da draußen, vielleicht kennt ihr es:

Ihr sprecht mit Kolleg:innen aus dem Backend ein bisschen über eure Projekte, Technologien, Gemeinsamkeiten und Unterschiede und irgendwann kommt ihr auf das Thema Build-Zeiten und Deployment. Während euer Gegenüber das Ganze eigentlich nur beiläufig anschneidet und sich nichts dabei denkt, rutscht euch ein “Davon kann ich nur träumen” raus und ihr wünscht euch im selben Moment, ihr hättet lieber nichts gesagt. 

Die darauffolgenden Sätze gleichen einem Eingeständnis, dass Mobile halt doch nicht immer cool ist und das Leben als Mobile Dev doch seine Schattenseiten haben kann. Von schnellen 10 bis 30 Sekunden Builds können wir Mobile Devs eigentlich nur träumen, nicht mal ein frisch aufgesetztes Android Projekt mit nur einer View installiert eine App auf den meisten Maschinen so schnell. Euer Gegenüber beendet das Gespräch mit einem “Da macht ihr aber irgendwas falsch” und ihr macht euch vom Kaffeeholen wieder zurück an euren Platz, in der Hoffnung, dass der Build nun endlich fertig ist und ihr weiterarbeiten könnt.

Solche und andere Gespräche haben mich und meine Kolleg:innen immer wieder dazu gebracht, die Projektstrukturen und Build Files auf der Suche nach schlecht performenden Settings und Code zu durchforsten. Der Blick in die Changelogs unserer IDEs und Frameworks war immer hoffnungsvoll auf Ankündigungen zur Optimierung der Build Performance gerichtet und auf Konferenzen haben wir nur zu gerne auf die Worte “We optimized the Performance as well” gehört, uns danach in den Arm genommen, geweint und gesagt “Bald wird alles besser”.

Was bis’n du für einer?

Also, wer mich nicht kennt: Ich bin Benny, Mitte dreißig, geboren in Gera (liegt in Thüringen) und aufgewachsen in Dortmund. 18 Jahre Ruhrgebiet sind prägend und bereiten gut auf’s Leben vor, ihr wisst schon was ich meine. Fürs Ingenieurstudium bin ich dann ins sonnige Köln gezogen und habe mich mittlerweile mit Kind und Kegel am äußeren Speckgürtel Kölns breit gemacht: im schönen “Kerpen Horrem” - mit rheinischer Stimme gesprochen klingt’s noch schöner ;) Obwohl es hier eigentlich wirklich ganz schön ist. =) 

Seit Mitte 2015 arbeite ich bei REWE digital. Erst als Scala/Clojure Backend Dev, um es mir dann wenig später im Mobile Consumer Apps Bereich als Android Dev gemütlich zu machen. Damit habe ich nun auch schon fast 6 Jahre Android Entwicklung auf der Uhr, mit vielen Mobile Devs gearbeitet, sowie das ein oder andere zum Thema Android Entwicklung gelernt.

Bleib mal bei der Sache!

Diesen Text habe ich natürlich nicht ausschließ des Spaßes wegen verfasst, dem Ganzen liegt ein ernster Kern zu Grunde: Wie schaffen wir es, uns von so viel verschenkter Build Zeit beim Coding zu befreien und uns somit sehr viel effizienter, schneller und auch glücklicher zu machen? Wie ich bereits angedeutet habe, wird kontinuierlich an der Optimierung der Software gearbeitet, aber die anfänglich großen und positiven Auswirkungen auf unsere Builds wurden mit der Zeit immer kleiner, wobei die Anforderungen von Tools, IDEs und den mobilen Betriebssystemen (auf unseren Emulatoren) immer weiter gestiegen sind. Auch moderne UI Frameworks wie Jetpack Compose und Swift UI haben den Druck auf unsere Arbeitsmaschinen erhöht und dabei sind wir auch gleich beim Punkt: 

Wenn sich bei der Software nicht mehr viel bewegt in Sachen Performance, muss an der Hardware gedreht werden.

Unsere Kolleg:innen im Backend haben es da ein wenig einfacher mit verteilten Cloud Systemen und skalierender Computing Power, die in wohl gekühlten Rechenzentren fernab des Büros schlummern. Für uns Mobile Devs ist ein performantes Lastentier als täglicher physischer Begleiter unabdingbar. Vom großen Wurf der cloudbasierten Entwicklungsumgebung für Mobile Devs habe ich zumindest noch nichts gehört …

Als Apple Ende 2021 die “großen” Macbook Pros mit M1 Max und M1 Pro vorstellte, waren wir schon ein bisschen erstaunt über die ersten Testberichte und der herausragenden Performance der neuen, auf ARM Technologie basierenden, SoCs. Wobei ich zugeben muss, dass in meinem Fall auch ein wenig Skepsis herrschte, ob das Ding wirklich so gut ist.

Glücklicherweise konnte unser Engineering Manager Mike das Go erwirken, allen Mobile Entwicklern ein Upgrade auf die neuen Macs mit M1 Max und 32GB RAM zur Verfügung zu stellen, in meinem Fall war es das 16” Modell.

Nach vielen Monaten des Wartens, geschuldet dem Halbleitermangel, der Pandemie, feststeckender Schiffe und was nicht noch allem, konnten wir die neuen Geräte im März in Empfang nehmen.

 

Und? Was kann das Schätzchen nun?

Wie sich das für einen Ingenieur gehört, habe ich das gute Stück natürlich erst einmal gut ausgetestet, ausgemessen, ganz viele Zahlen aufgeschrieben, umgerechnet und verglichen.

Testgerät:

Apple MacBook Pro 16” mit M1 Max und 24 Core GPU und 32GB RAM. Nachfolgend “M1 MacBook” genannt.

Vergleichsgerät:

“Apple MacBook Pro 16” von 2019, mit i9 uns 32GB RAM. Nachfolgend “Intel MacBook” genannt.

Die Zahlen allein lassen zwar schon eine starke Maschine vermuten, aber eben leider nur auf dem Papier. Für ein so potentes Gerät ist es leider viel zu dünn ausgefallen und die Kühlung stark unterdimensioniert, was in der Folge zu hohen Temperaturen, CPU Throttling und damit verbundenen Geschwindigkeitseinbußen führt.

Test Szenario:

Die neuen M1 Chips wurden ja mittlerweile durch jedes erdenkliche Benchmark Programm gejagt und kamen dabei immer gut weg. Deswegen habe ich mich entschieden, mein Vorhaben auf reale Anwendungsgebiete zu richten und die Clean Build und Test Zeiten unserer REWE Android App “REWE Angebote & Coupons” zu vergleichen. Zusätzlich habe ich dabei noch auf die gesamte Performance des Systems (Bedienbarkeit von Anwendungen), Geräusch- und Wärmeentwicklung betrachtet und gemessen.

Die Temperatur der Chips habe ich dabei via iStatistica Sensors und die Lautstärke mit der App “Schallmessung (Sound Meter)” aus dem Google Play Store gemessen.

Test App:

Kurze Worte zu der Architektur und dem Aufbau unserer App “REWE Angebote & Coupons”, um die Vergleichbarkeit zu anderen Projekten herzustellen.

Unsere App folgt einem multi modularem Aufbau via Dynamic Features und umfasst mittlerweile 42 mal mehr und mal weniger voneinander abhängige Gradle Module. Unsere App Architektur beruht auf einem von uns angepassten Clean Architecture Pattern in Kombination mit MVVM View Architecture. Sie baut gänzlich auf Kotlin Code in Verbindung mit Gradle als Build Framework.

Build Zeiten Vergleich:

Verglichen wurden Clean Builds mit Installation der App auf einem externen Android Device, Clean Assembles der App und Clean Durchläufe all unserer im Projekt befindlichen Unit Tests. Dabei habe ich immer jeweils 10 Durchläufe auf jedem der Devices pro Testthema und identischer Codebase unternommen und den Mittelwert bestimmt, um eine bessere Vergleichbarkeit zu gewährleisten. Bei allen Tests wurde die Debug Version unserer App gebaut, ohne Obfuskierung, ohne Signing usw..

Clean Installs:

Bei den Clean Installs auf einem externen Device via USB Connection hat das Intel MacBook im Schnitt 3:26 Min gebraucht, wobei zu beobachten war; dass die Builds mit fortlaufender Anzahl immer ein wenig langsamer wurden. Ich vermute, dass es sich dabei um CPU Throttling des Intel MacBooks handelt. Es ist üblich, dass CPUs bei einer zu hoch werdenden Temperatur zunehmend Leerlauf Prozesse untergeschoben werden, damit die Last auf den Komponenten geringer wird und das System schneller an Temperatur abnehmen kann. Dies führt jedoch naturgemäß zu Performanceeinbrüchen. Das M1 MacBook konnte die gleichen Prozesse mit einem beeindruckenden Schnitt von 1:12 Min. verarbeiten. Dabei waren die Abweichungen gering von 0:10 bis 0:20 Min. Damit arbeitet das M1 MacBook im Schnitt 2,86 fach schneller als Intel MacBook von 2019, was einer Performancesteigerung von ca. 186 % entspricht.

Clean Assembles:

Assembles zählen bei Android Projekten zu den größten Tasks für unsere Rechenmaschinen, sie werden in der Regel aber nur auf unseren CI/CD Systemen ausgeführt. In der alltäglichen Entwicklung braucht man viele der hier anfallenden Aufgaben nicht unbedingt auf der lokalen Maschine zu erledigen. Doch gerade weil dieser Task so groß ist, eignet er sich gut für einen Vergleich. 

Im Mittel hat das Intel MacBook für diese Aufgaben 7:43 Min. gebraucht, bei gleichem Verhalten, wie auch schon bei den Clean Installs. Gegenteiliges wäre jedoch auch unerwartet. =) Das M1 MacBook schaffte die gleichen Aufgaben im Mittel in 2:48 Min., was immer noch 2,75 mal schneller ist und einer Performancesteigerung von ca. 175 % entspricht.

Unit Tests:

In unserem App Projekt sind derzeit 2120 Unit Tests, welche die App auf Herz und Nieren Prüfen. Da es sich hierbei um sehr viele parallel lauffähige Operationen handelt, wird von den Prozessoren ein besonders starkes Multi Threading abverlangt. Noch einmal zur Übersicht: Der Intel besitzt 8 physische Kerne, die jeweils 2 Threads bearbeiten können, er stellt also insgesamt 16 Threads für Aufgaben bereit. Der M1 Max bietet 8 Hochleistungs CPU Kerne und 2 Low Energy Kerne, kann also “nur” 10 Threads gleichzeitig zum rechnen verwenden.

Das Intel MacBook brauchte für die gesamten Unit Test Läufe im Schnitt 4:52 Min. und das M1 MacBook 2:18 Min. Das heißt auch hier hat das M1 MacBook die Nase vorne, jedoch “nur” mit 2,1-facher Geschwindigkeit und einem Mehr an Leistung von ca. 112 %. Durch die 6 zusätzlichen Threads ist das Intel MacBook daher nicht ganz so weit abgeschlagen.

Geräuschentwicklung und Temperatur:

Auch wenn diese beiden Eigenschaften eher nebensächlich erscheinen, machen sie bei dem Vergleich auch einen erheblichen Unterschied deutlich.

Zunächst fange ich wieder mit dem i9 MacBook an. Dabei konnte ich in der Spitze 100ºC (CPU Throttling Grenze) und 69 bis 74ºC im Idle Betrieb messen. Die Lüfter des Geräts waren dauerhaft an und kamen in der Spitze maximal auf einen Wert von 5600U/min.

Beim M1 MacBook waren die gemessenen Temperaturen des SoCs in der Spitze bei 92ºC und im Idle bei 46 bis 51ºC. Für einzelne Testdurchläufe blieben dabei jedoch wohlgemerkt beide installierten Lüfter aus. Erst bei mehreren Build Durchläufen hintereinander sprangen die Lüfter auf eine sehr niedrige Drehzahl von maximal 1600U/min an. Das entspricht einem niedrigeren Wert als dem im Idle Betrieb des Intel, nämlich 1700 bis 1800U/min.

Wie zu erwarten ist damit auch die Geräuschentwicklung des Intel MacBooks wesentlich höher, hier konnte ich minimal einen Wert von 38dB(a) und maximal 68dB(a) feststellen, was im Vergleich ungefähr der Lautstärke von Flüstern bis zu einem brausenden Wasserkoch reicht. Da die Lüfter des M1 MacBooks im Normalfall inaktiv sind, hebt es sich akustisch nicht von der Umgebung ab und wenn die Lüfter dann doch einmal anspringen, erreichten sie einen Wert von 36dB(a), was einem leiseren Flüstern entspricht.

 

Fazit

Bei dem ganzen Vergleich handelte es sich doch schon um ein sehr ungleiches Paar. Beide Notebooks folgen komplett unterschiedlichen Technologien mit ARM und x86. Auch das Alter der beiden Geräte spielt sicherlich eine Rolle. Neue Intel- oder AMD-Prozessoren werden sicherlich ähnliche und auch vielleicht bessere Ergebnisse erzielen, jedoch nicht in einem MacBook und wahrscheinlich auch nicht bei so niedrigem Stromverbrauch und Temperaturen.

Zudem kann man mit eingeschalteten Software features wie Caching usw. bei beiden Geräten die jeweiligen Build Zeiten um ein paar Sekunden nach unten schrauben. Mit dem M1 Max kommen so auch Änderungen in Compose Layouts schon innerhalb von ca. 20 Sekunden auf den Screen des externen Devices.

In der Bedienung fühlt sich jedoch alles ein ganzes Stück smoother auf dem M1 MacBook an. Emulatoren haken weniger bis gar nicht, Programme öffnen sich wesentlich schneller und arbeiten mit z.B. Jetpack Compose wurden für mich erst mit dem neuen Mac wirklich möglich. Auch wenn Google noch einiges an Liebe in die Preview Funktion stecken muss um das Feature rund zu machen. ;)

Meines Erachtens hat Apple jedoch mit den M1 Macs endlich wieder Profigeräte erschaffen die dem “Pro” würdig sind und uns Mobile Entwicklern bei unserer täglichen Arbeit wieder besser unterstützen und und effizienter machen.

Auch wenn die Anschaffung eines solchen Gerätes natürlich auf den ersten Blick teuer erscheint, kann man die gesparte Zeit sehr einfach gegen ein Entwicklergehalt plus zusätzlicher Aufwandskosten rechnen und wird sehen, das sich so eine Anschaffung sehr schnell amortisieren wird. Bei durchschnittlich 20 Builds pro Arbeitstag (bei Jetpack Compose mit und ohne Preview sind es deutlich mehr) kommen in dem hier geführten Vergleich schnell 45 bis 60 Minuten zusammen, in denen entweder gar nicht oder nur erschwert gearbeitet werden kann, da während der Build Zeit keine IDE Unterstützung zur Verfügung steht oder Code Highlighting, Autovervollständigung und der Gleichen. Und ich gebe zu beachten, dass ich mit dem 2019er i9 MacBook auch schon sehr gut aufgestellt war, bei älteren Modellen geht die Performance natürlich noch einmal weiter runter.

Darum an die Chefs und Hardwarebeauftragten da draußen: Überlegt euch gut, ob ihr wirklich an dieser Stelle sparen wollt! Die Softwareentwicklung wird wahrscheinlich im Nachhinein teurer werden als die Investition in gutes Arbeitswerkzeug, auch wenn natürlich nicht jede neue MacBook Generation im Vergleich zur vorherigen einen so enormen Leistungsschub hat, wie ihn nun das M1 Max darstellt. Einen Erneuerungszyklus der Hardware von zwei bis maximal drei Jahren halte ich daher durchaus für sehr sinnvoll. Wenn jedoch so eine Ausnahme Generation wie der M1 Max dazwischen kommt lohnt es sich wahrscheinlich auch früher zu wechseln, um so einen großen Performance Schub zu erhalten.

Und damit verabschiede ich mich von euch und Dankeschön für's Lesen ;)

 

Nächste Story in : report-stories

Mein Markt Plattform – eine Plattform von Kaufleuten für den Endkunden

Christian de Pay

Suche hier nach Stories, Jobs und Themen…

Zurück
Keine Suchergebnisse für verfügbar
Robot
Leider gibt es unter Deinem Suchbegriff keine Ergebnisse.
Further down we have several terms for you or take a look at our job openings!
Suchvorschläge: