Apple M1 und Archicad 24 :-(

[torben_wadlinger]

Also, nachdem mein Sohn heute sein M1 MacBook Pro (16 GB RAM) bekommen hat, haben wir gleich mal ausprobiert wie das mit Archicad 24 (6004) so funktioniert. Und natürlich haben wir das mit unseren Standard-Projekten getestet: viele Punktwolken, komplexe Geometrien, viele Polygone.

Ergebnis: ewiges Laden des Projekts von der BIM-Cloud, Projekt in Endlosschleife nach Anschalten aller Punktwolken im 2D (Projektgröße auf der Cloud ca. 4 GB inkl. Punktwolken). Irgendwann verabschiedete sich auch die Touchbar und der Rechner wurde hart neu gestartet.

Gleiches Projekt auf einem Intel-MacBook Pro (32 GB RAM, Intel Grafik) von 2018: Projekt lädt ebenfalls langsam aber zumindest reagiert es irgendwann wieder.

Mein Fazit nach dem Schnelltest: Finger weg von den M1 solange Archicad nicht nativ läuft und man datenintensive Projekte hat. Schade eigentlich, denn im Gegensatz zum Intel-Mac röhrte der Lüfter kein Stück.

Wir werden jetzt mal rumspielen, ab welchem Komplexitätsgrad der M1 in die Knie geht.

[Anonymous]

Die Hoffnung stirbt bekanntlich zuletzt...

Wir haben nun zwei Apple M1 Max mit 10‑Core CPU, 32‑Core GPU, 64 GB Arbeitsspeicher und
1 TB SSD Speicher im Einsatz.
Die Performance ist nach drei Tagen Einsatz, überhaupt nicht besser geworden! Kleine Projekte in Ordnung, grosse Projekte genau gleich Träge wie auf einem iMac 2019! Wird zum Beispiel mit aktiver Transparenzpause ein Geschoss gewechselt, kann man 20 Sekunden warten (bei grossen Projekten)!
Wenn dies im Sommer mit der nativen Version nicht deutlich besser wird, hat Graphisoft wohl keine Ahnung von Multiprozessoren und wir werden ArchiCAD wohl als Fehlinvestition abschreiben müssen!

Da helfen auch Skulpturen von Steve Jobs am Hauptsitz nichts ;-(

[torben_wadlinger]

@sofalounge
AC kann gar nicht schneller sein, da das alles unter Rosetta läuft. Die native Single-Core-Performance liegt bei Geekbench bei etwa 1700 und damit ca. auf dem Niveau eines Core i7 12700 (bisschen darunter).

Wenn Du negativ gesschätzt 20% Leistung im Singe-Core für Rosetta abziehst, landest Du bei ca. 1400 Punkten. Das entspricht einem 2020er iMac mit i7 10700. D.h. wenn ihr von iMacs auf Studios gewechselt habt, hättet ihr euch den Wechsel sparen können.

Und selbst bei unseren nagelneuen HP Z1 mit 11700 und 64GB RAM und RTX 3070 ist AC bei mittelgroßen Projekten schnarchlahm. Man kann sehr gut beobachten, was passiert wenn man die Geschosse wechselt: es geht der Speicherverbrauch nach oben, parallel fährt der Prozessor hoch und wenn das neue Geschoss geladen ist, geht der Speicherverbrauch wieder runter und die Prozessorlast ebenfalls. Wenn Du jetzt arbeitest und Systernals mitlaufen lässt, kann man sehr gut die Speicher- und Prozessorlasten mitverfolgen. Und dann siehst Du dass da massiv Datenbank-Operationen ablaufen. Bisher benutzt AC wohl mongoDB, aber das ist immer noch nicht auf M1 angepasst. Auf dieser Seite von GS ist jetzt auch der Eintrag GigaBase aufgetaucht.

https://graphisoft.com/legal/license-ag ... e-licenses

Eventuell tauscht GS gerade die interne Datenbank aus.

[Anonymous]

Ja, das es aktuell nicht schneller wird, hatten wir befürchtet / erwartet.
Jedoch ist unsere Erwartungshaltung, dass es mit der nativen Version mindestens gleiche Geschwindigkeitsverbesserungen (Faktor 5) gibt, wie dies VectorWorks in der halben Zeit fertig gebracht hat. Eigentlich hätte ich auch nie gedacht, dass sich Graphisoft so viel Zeit lässt mit dem Thema Multicore (10 Jahre geschlafen?)...

GigaBASE kenn ich gar nicht. Hat jemand bereits Erfahrungen, ist nicht sehr viel verfügbar im Netz und leider eine unglückliche Domain, welche weitere Verzögerungen mit sich bringen könnte...

[torben_wadlinger]

Das ist wirklich unglücklich mit der Domain. Und der Code ist seit 2017 nicht mehr aktualisiert worden. Ich frage mich, welche Datenbanksysteme die anderen Programme so einsetzen. Aber das ist alles nur rätselraten. Wir müssen halt abwarten.

[AlexS1]

"Holger Kreienbrink" wrote:
Die M1 native Version ist in der Entwicklung. Wir werden sie in der zweiten Jahreshälfte komplett fertig stellen.
Sobald wir eine Vorabversion haben (wird im Sommer sein), werden wir diese auch veröffentlichen.

Bis dahin bitte ich euch noch um ein klein wenig Geduld.

Bis jetzt hieß es, dass mit AC 26 die native Version im Sommer kommt. Das ist also jetzt auch schon wieder Geschichte. Jetzt ist es nur eine Vorabversion, die im Sommer kommt. Die finale Version in der zweiten Jahreshälfte, also Ende des Jahres.
Das ist echt nicht mehr lustig!

[tru_ber]

"Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt Archicad nativ auf M1."
Henry Anwender

Mit dem Wissen, dass erst im Herbst eine funktionierende M1-Version rauskommt, werden wir im Büro keine neuen Projekte mehr in Archicad starten. Wir können uns keine weiteren Ausfälle, Performanceprobleme und Projektverzögerungen erlauben.

Viele Grüsse und vielleicht bis im Herbst, Ampelmännchen

[achtbru]

Es bleibt erstmal abzuwarten, ob die native M1 version überhaupt mehr Leistung bringt oder "nur" fehlerfrei läuft. Ich mach mir da keine großen Hoffnungen. AC ist anscheinend so voll mit uraltem code und alten APIs.

[Schicker]

Moinsen,

das nicht alle Kerne unterstützt werden, ist nicht nur ein Problem / Ärgerniss auf Apple-Computern. Bei Windowsrechnern ist es genau so. Da kann man immer wieder beobachten wie bei 12 Kernen (24 Threads) ein einiziger Kern arbeitet. Selbst bei Berechnungen von Bauteillisten ist nur ein geringer Teil der CPU ausgelastet. Startet man ein Rendering, passiert erst mal nicht viel, bis die C4D-Engine anfängt zu rechnen. Dann sind auf einmal alle Kerne am arbeiten. Danach wirds wieder mau.

Ich hoffe, daß die Anpasungen zu dem M1 nicht nur für Mac-User einen Vorteil bringt, sondern daß für alle Plattformen endlich die CPU mit allen Kernen unterstützt wird.
(Aber das hoffe ich schon seit über 10 Jahren.)

Grüße

[Anonymous]

Zumindest ist es als Mac-Anwender beruhigend, dass die Windows-Version auch nicht ausreichend performt 😆

Hoffen wir, dass mit der 26 alles besser wird! Sonst packen sie es sicher mit der Jubiläumsausgabe 30 😁

[runxel]

Bei allem (ja durchaus berechtigten) Rant über die Performance sehe ich mich trotzdem mal gezwungen hier eine Lanze zu brechen:
Bestehenden Code für Multikern zu optmieren ist ein nahezu aussichtsloses Unterfangen. Wer sich das so vorstellt, dass man da einfach "mal 'ne Zeile ergänzt im Quellcode" oder ein Pragma drauf haut.... der denkt sich wahrscheinlich auch, dass man eine perfekte Treppe auf Knopfdruck bekommt 😉

Tatsächlich ist Concurrency immer noch ein hartes Kernproblem der Informatik. Hust*RaceConditions*hust
Wer da eine Lösung hat, bekommt sicherlich eine Menge Geld nen schönen Turing Award für hinterhergeworfen.

Und wenn hier einer mit Computerspielen ankommt: Bei denen ist ja Genauigkeit nicht gefragt. Ob da irgendwas einen Pixel weiter links, oder weiter rechts ist, spielt keine Rolle. Der nächste Frame macht das eh wieder obsolet.
Aber wir möchten ja schon gerne, dass die Wand da steht, wo wir uns das denken...