Hi,

ich bin auf der Suche nach jemandem der für mich mal testet, wie lange die Compile-Zeit eines recht trivialen Swift-Projekts dauert. Es besteht nur aus 2 Dateien und mein armer iMac Pro (2017) tut sich da sehr schwer.
Das liegt im wesentlichen an einer Datei, in der ein Array mit 1000 Einträgen (jeweils ein Tupelo) definiert wird. Wenn man da die Swift Type Inference ausnutzen will bekommt man Build-Zeiten jenseits von Gut und Böse, ohne Type Inference geht es rucki-zucki.

Vielen Dank schon mal im Voraus
Peter

Das neue MBP mit M1 Pro/Max habe ich (noch) nicht. Das kleine hat die Firma wohl schon bestellt, aber keiner weiß, wann es ankommt.
Aber ich kann es mal auf dem M1 mini probieren, wenn du magst. Nach meiner Erfahrung ist der ca. 3 mal schneller als mein MBP 2016. (Getestet mit LLVM 11 aus Source gebaut mit CMake und Ninja). Ein M1 Pro sollte noch bis zu 2 mal schneller sein, das kann ich aber erst ausprobieren, wenn er da ist.

Aber vielleicht ist die Lösung insgesamt doch besser, die Type Inference zu umgehen Wenn es statisch kompiliert wird, sollte sich der einmalige Aufwand schon lohnen, wenn es dynamisch erzeugt wird, solltest du es lieber aus einer Datei einlesen.

Hab ein M1 Pro Max am Start, aber da bräuchte ich nen Entwickler-Account, oder?

Theoretisch nicht, wenn er sein Projekt auf Ad-Hoc Signing konfiguriert. Xcode sollte genügen.

Hätte ein 16 Zoll MacBook Pro M1 Max mit 32 GPU Kernen und 32 GB RAM.

Hier ein 16" mit M1 MAX 32 GPU und 64GB RAM

Hier 14" M1 Max mit 24 GPUs bei 32 GB RAM.
XCode ist bei mir drauf.
Wir könnten das gemeinsam testen via TeamViewer oder alternativ Teams. Ich hätte allerdings frühestens morgen Abend Zeit dafür.

Vielen Dank erst mal für alle Freiwilligen die sich gemeldet haben.
Einer von ihnen hat den Link auf das Progrämmchen bekommen und testet es dann mal.

Das Resultat würde auch interessieren

Das braucht man doch gar nicht zu testen, denn das Problem und die Lösung stehen im Ausgangspost. Der Swift-Compiler kommt manchmal mit Type Inference nicht gut klar. Es ist zwar traurig, dass dieses Problem immer noch besteht (in den ersten zwei Jahren konnte man mit so billigen Sachen wie der Umrechnung von hh:mm:ss in Sekunden den Compiler abschießen), aber die Lösung liegt hier sicher nicht in schnelleren CPUs. Sondern darin, die Typen explizit zu benennen.

Also der erste Durchgang konnte gar nicht beendet werden. Ich lasse es gerade nochmal laufen, weil ich die Fehlermeldung schon weggeklickt habe.

Ich starte nach meiner Arbeit noch mal einen Test mit neugestartetem Mac. Habe aktuell 48 GB beim callserviced Prozess aufgrund des RAM Bugs und noch andere Programme laufen.

Hies hätte ja sein können, dass der Bug in der M1 Xcode Variante draussen ist, oder der M1 noch schnell genug ist damit es zuverläßig übersetzt werden kann.

Achja, der Bugreport an Apple ist gerade raus

Hier die Fehlermeldung:

Den "Bug" gibt es seit es Swift gibt. Und irgendwie hast du recht, Apple scheint darauf zu setzen, dass sich das mit steigender CPU-Leistung erledigt.

Den kenne ich leider ...

Also nach neugestartetem Mac (aber leider während einer Installation der After Effects Beta:

Nach gut 10 Minuten wieder der Fehler. Timeout wird also bei 10 Minuten liegen.
Es wurden gut 2 GB RAM benötigt.
CPU-Auslastung lag bei 50 %. Anbei noch ein Graph. Wie gesagt, leider zu spät gemerkt, dass was installiert wurde. Da waren wohl aber hauptsächlich die Effizienzkerne beteiligt. Am Ende sieht man, wie es abfällt und da war die Installation auch beendet.
Ich glaube aber nicht, dass er es ohne Installation geschafft hätte 😅

Mit expliziten Typen dauert es eine Sekunde.

ich hab M1 8GB kann ich gerne mal testen.

Ist wohl immer noch ein blöder Compiler Bug ...

Danke für die Hilfe

Nein, das ist kein Compiler Bug. Sondern eine grundlegende Designschwäche. Was besonders tragisch ist, weil Swift ja eine "Programmiersprache ist, die von Compilerentwicklern erfunden wurde", wie Chris Lattner in seinen WWDC-Auftritten wieder und wieder betont hat. Da hätte man erwarten können, dass der Compiler weniger Macken hat, als das bei Swift noch immer der Fall ist.

Die grundlegende Designschwäche ist die Type Inference an sich. Der Compiler sucht sich aus, welcher Datentyp da jetzt passt, wenn er nicht explizit angegeben wird. Dazu wird der Compiler vermutlich nicht nur die Stelle betrachten, wo der Wert definiert wird, sondern auch wo und wie er benutzt wird. Mag sein, dass er einen Durchlauf macht und dann entscheidet - der Datentyp wird benutzt wie ein String, dann wird String das beste sein. Bei einem Array mit Tuples muss er dass dann möglicherweise für jedes Element des Arrays zwei mal machen. Könnte ja sein, dass das letzte Element statt int ein signed int braucht.
Am Ende - nette Idee, aber den Datentyp nicht explizit anzugeben ist einfach nur Faulheit - sorry - und wenn der Kopf des Autors sich weniger Arbeit macht, dann muss der Compiler um so mehr tun. Es kann doch nicht so schwer sein, explizit Datentypen anzugeben, oder?
Aber ich gebe zu, ich habe allgemein Vorbehalte gegenüber Swift nachdem ich den genialen SmallTalk-Ansatz von Objective-C zu schätzen lernte. Ich glaube, mit Steve Jobs hätte Swift keine Chance gehabt.

Ist es nicht, aber es ist in vielen Fällen schlicht unnötig. Wenn man modernen Swift-Code mit ObjC vergleicht, dann fällt vor allem eine Sache auf: Swift-Code ist viel kürzer und in den allermeisten Fällen dadurch nicht nur besser lesbar sondern auch besser wartbar, denn nicht geschriebener Code muss auch nicht gewartet werden. Das ist schon einiges wert, finde ich.

Ich mag ObjC auch. Lange damit gearbeitet und es lieben gelernt.
Und ich motze gern über die Entwicklung von Swift, seit eine Community von Sprachnerds die Weiterentwicklung vorantreibt.
Heutzutage würde ich dennoch Swift jederzeit vorziehen, es ist mir einfach die angenehmere Sprache.

Und bezüglich "mit Steve Jobs hätte Swift keine Chance gehabt": Steve war extrem gut darin, alte Zöpfe abzuschneiden, auch gegen den Willen der User. Der wäre meiner Meinung nach der erste gewesen, der ObjC beerdigt hätte, sobald Swift einigermaßen marktreif war.

Hi,doch, es ist ein Compiler Bug.
Wenn in dem Array anstelle von 1000 nur 100 Werte stehen übersetzt der Compiler es auch mit Type Inference. Dass das dann bei 10-mal sovielen Werten in einen 10-minütigen Timeout läuft kann eigentlich nicht sein. Die Anzahl der Stellen an denen der Compiler für die Type Inference innerhalb des Array den Type suchen muss wächst ja mit O(n), im schlimmsten Fall wird seine Annahme mit dem letzten Element der Array über den Haufen geworfen.
Den restlich Sourcecode inspiziert Swift beim Type Inference nicht, denn die basiert ja auf der Initialisierung der Variablen.

Stimmt.Stimmt nicht: meiner Erfahrung nach ist das exakte Gegenteil der Fall. Swift ist AbKüFi in pathologischem Ausmaß. Objective-C wird oft die Länge vorgehalten, ein Argument, das ich überhaupt nicht nachvollziehen kann. Klarheit, Eindeutigkeit und Lesbarkeit sind für mich um Größenordnungen wichtiger als Kürze. Manchmal habe ich den Eindruck, Swift ist überhaupt nur entstanden, damit digitale Nomaden ihrer Tätigkeit auch auf einem Laptop mit Mini-Bildschirm im Starbucks oder am Strand nachgehen können.
Genau – deshalb ist Perl auch für seine Wartbarkeit so berühmt. Die beste Voraussetzung zum Warten von Code ist, dass man ihn überhaupt erst mal versteht. Nein, hier gebe ich ssb vollkommen recht. Ja, Steve Jobs hat alte Zöpfe schnell abgeschnitten, aber doch nur, wenn es etwas Besseres gab. Für jemanden mit dem ästhetischen Empfinden von Steve Jobs ist Swift aber nichts Besseres, sondern ein semantisch unerträglicher zeitgeisthöriger Gemischtwarenladen, der diametrale Gegensatz zu der Eleganz und Klarheit von Objective-C.Wann wird das sein?

So unterschiedlich sind die Erfahrungen. Ich muss jedesmal ko... wenn ich ObjC lesen muss und noch schlimmer, wenn ich den Code anfassen muss. ObjC zu lernen war im Vergleich zu Swift eine Qual. Nie wieder (wenn es sich nur irgendwie vermeiden lässt) ObjC für mich.

Dann frage ich mal neugierig nach. Nimm
bzw.

Da ich des Englischen mächtig bin (was man als Programmierer sein sollte) verstehe ich die Wörter array und mutable sofort; Lernaufwand 0.

Aber was bedeuten let und var? let gibt es zwar als englisches Verb; es soll aber ein Objekt (array1) bezeichnen; das ist mit einem Verb syntaktisch unmöglich. var gibt es als englisches Wort erst gar nicht. Lernaufwand also klar > 0.

Niemand von denen, die Swift mögen und die ich gefragt habe, konnte mir diese simple Frage konsistent beantworten. Sie benutzen die Sprache, verstehen sie aber nicht einmal.

Jetzt kannst Du natürlich ganz pragmatisch argumentieren, Dir sei völlig egal, was let und var als Worte bedeuten, solange Du weißt, was sie im Kontext der Programmiersprache bewirken – ist eben eine Konvention. Kann man machen. Aber Steve Jobs, der Mann, der darauf bestand, dass Platinen ästhetisch aussehen müssen, hätte eine solche pragmatische Haltung niemals durchgehen lassen. Insofern hat ssb definitiv recht.

Das größere Problem besteht aber darin, dass Code den ich schreibe, das tut was ich schreibe. Mit der Zeit wird man gut darin, auch das zu schreiben, was man mit dem Code beabsichtigt.

Code, den ich nicht schreibe, weil der Compiler es einem bequem machen kann, tut nicht das, was ich schreibe, sondern das was der Compiler meint, was ich geschrieben hätte. Das Problem ist nur, dass Compiler - Computer allgemein - ziemlich schlecht beim Denken sind. Der Compiler berechnet, was ich vermutlich gedacht habe. Das kann aber von meinen Gedanken abweichen - oder die Berechnung ist aufwändig (und stößt beim Beispiel an die Grenzen).

Diese Bequemlichkeiten sind praktisch für Einsteiger, die an vieles gar nicht erst denken und es so auch nicht lernen werden, daran zu denken - wozu, wird der Compiler schon richtig machen. Das ist aber eine sehr optimistische Annahme.

Sei mir nicht böse ssb, aber Type Inference ist nicht wirklich Rocket Sciene und hier hat der Compiler praktisch alle wesentlichen Infos um verdammt gute Ergebnisse zu liefern.
Und Type Inference war schon vor 30 Jahren in meinem Compilerbau-Praktikum an der TUM eine der leichteren Aufgaben.