This is not the same as writing i in 10…1, which will compile but crash at runtime.

Sag mal, bist Du nicht vorrangig Jurist? Mit solchen Argumentationen könntest Du es beim OLG HH echt weit bringen.

github.com/owensd/swift-perf/pull/2/files

github.com/AndreasPrang/Programming-Languages-Speed-Test
(Kompiliert ab Swift 3.0 nach meiner Anpassung, die Werte wurden im Read.Me nicht angepasst)
Insofern kann ich mich nur erinnern, dass Swift nach der Anpassung um Faktor 10 langsamer war als vorher und damit vom 1. auf den 6. gerutscht ist.

Aber das könnt ihr ja selbst ausprobieren und berichten.

Es gibt keine Overflows in C. INT_MAX+1 == INT_MIN. INT_MIN-1 == INT_MAX. UINT_MAX+1 == 0.
Ist so definiert (Genaugenommen ist das vorgeschriebene Compilerverhalten in dem Fall 'undefined' und dementsprechend jedes Verhalten korrekt) und demnach kein Overflow.
DU prüfst also VOR der Operation, ob sie überhaut einen Sinn ergibt.
Wenn Du eine Bankingsoftware schreibst, nimmst Du keinen INT sondern was aus der bign.lib oder weiß der Geier.

Swift optimiert hier mögliche Fehler weg, die keine sind.

Ob 'Additionsergebnis stimmt nicht' oder 'Wirft ne Exception', in beiden Fällen tut das Programm nicht das, was man erwartet.
Es unterscheidet sich lediglich im Detail dessen, was es anders tut als erwartet: Falsch rechnen vs. komplett abkacheln.

Überhaupt ist diese ganze Geschwindigkeitsdiskussion fürn Arsch. Behaupte ich ja seit Swift 1.0
Arbeiteste mit Objekten haste Geschwindigkeitsverluste. Arbeiteste mit Interpretern haste Geschwindigkeitsverluste.
Ist für medizinische Apparate sicherlich wichtig, aber auf denen wird Swift so nicht laufen. Auch da bekommst Du die Geschwindigkeit definitiv nicht, wenn Du mit Objekten oder ausladenden Rechenoperationen hantierst.

Je nach Sprache kann das ewig dauern. Je nach Compiler kann das optimiert werden. Wie sähe diese Optimierung aus, würde sie manuell durchgeführt?

Huch. PEMDAS. Gaußsche Summenformel a.k.a. 'Der Kleine Gauß'. Simple Arithmetik.
(Für Leute mit Abitur simpel, also nicht für mich. Für mich ist das Schwarze Magie gepaart mit Voodoo.)

Was ich in diesem Zusammenhang aber total albern finde ist dieser Geschwindigkeits-Schwanzvergleich der Programmiersprachenfrakionen.
Beispiel gefällig? Verglichen mit unserem Objective-C und Swift im letzten Beispiel des vorherigen Posts war Python (unkompiliert) fast 7,5x beziehungsweise über 33x langsamer.
Plover ermöglicht eine nahezu Echtzeitumwandlung von Stenographietastenanschlägen in entsprechende Silben. Programmiert in Python (vermutlich kompiliert).
Die Performancebremse ist hier der Mensch.

Es ist immer die Frage was gebraucht wird.
In Echtzeitkomponenten wie medizinisch-technischen Gerätschaften gibt es kein Objective-C. Ich weiß nicht, ob der Geschwindigkeitsverlust zu hoch ist, die Beschränkung auf GnuStep zu restriktiv ist oder es einfach nur niemand versucht hat. Dort wird es mit Sicherheit in naher Zukunft auch kein Swift geben, einfach weil deren 'Open Source Cross Platform' Initiative bedeutet 'Mac OS X oder 32/64 Bit Ubuntu'
(Das darauf basierende Arch Package ließ sich beispielsweise nicht mit den wichtigen Libraries bauen, weil sie mit arschalten binutils hantieren.)
Aber Java wird da benutzt. Wir erinnern uns sicherlich noch an Java 2 auf dem guten alten 800MHz Pentium II bzw. die Zeit, die wir mit Warten verbracht haben...

Warum hier alle auf Swifts angeblich bescheidener Performance herumreiten wird klar, wenn man sich den Lattner von 2014 ins Gedächtnis ruft.
Safe. Fast. Expressive.
Steht so sogar noch auf deren Seite.

Mit ihren ständigen ABI-Brüchen und der damit einhergehenden Inkompatibilität ist das alles andere als sicher.
Auch deren Typsicherheit funktioniert nur so lange, wie hinten rum nicht irgend ein Blödsinn rein kommt - den man dank Typsicherheit allerdings nicht zur Laufzeit abfangen kann.

Schnell ist es nur, wenn man weiß, wie man die Sicherheiten umgeht.
Oder wenn man der prozeduralen Programmierung mächtig ist und weiß, wo man was wie optimieren kann.

Wirklich ausdrucksstark sind Operatoren- und Methodenüberladungen sowie voller Unicode-Emoji-Blödsinn-Support auch nicht.
Und wenn man dann auch noch die Typbestimmung dem Compiler überlässt und ihn mit überladenen Methoden verwirrt hat sichs mit dem Ausdruck.

Vielleicht sind ihm auch in seinem Skript nur ein paar unwichtige Füllwörter abhanden gekommen.
Either Safe or Fast. Maybe Expressive.

Ich persönlich verfolge auch die Mailingliste nicht mehr, weil der anfängliche Zauber verflogen ist.
Das Beste, was uns der Schmiss gebracht hat, sind Playgrounds und via Markdown gerenderte Kommentare.

DAS hätten sie auch mit Objective-C hinbekommen. Einfach mal bei den Jungs von F-Script anfragen, wie man was in OS X injected.

Expressive.

Substitution schrieb:

Ich habe nie auch nur eine Zeile objective-c dafür verwendet, alles in Swift.

Zumindest zur Drucklegung des Foreneintrags hast Du Hunderte Zeilen Objective-C verwendet.
Erkennt man beispielsweise an NSTimer. Du hast da lediglich nix von gemerkt.

Das macht die Sache ja so gefährlich. Du sitzt in einer Weltraumrakete (Objective-C), deren Cockpit ausgestattet ist wie bei einer Dodge Viper (Java).
Alles kein Problem, bis Du mit einem echt komplizierten Manöver fiesen Solarwinden ausweichen willst - für das das Viper-Cockpit keine Kontrollflächen hat.

Hast du auch diesen Beitrag gelesen?

EDIT: Hier trifft genau das zu, was gritsch vor ca. 10000000000000 Beiträgen zu den Range-Operatoren meinte. Die Bedeutung ist versteckt. Während ich bei for(i = 1; i < 10; i += 3) bzw. for(i = 1; i <= 10; i += 3) direkt sehen kann, ob die 10 enthalten ist, geht bei stride() diese Information verloren.

Ja, und das ist sicherlich genau das, was jede sicherheitsrelevante Software braucht. Undefiniertes Verhalten.


Wie prüft man denn jetzt in C VOR der Operation, daß z.B. INT_MAX überschritten wird?

Das ist nicht ganz richtig: Mit -Ounchecked kannst du die Runtimechecks (inklusive Overflowchecks) abschalten.

Ja, ist ja richtig. Statt 'immer' hätte ich natürlich besser 'standardgemäß' oder so schreiben sollen.^^

Durch den Schalter ergeben die Checks meines Erachtens erst einen Sinn: Wenn Overflows im Code eine Gefahr sein können, sollte man sie auch explizit überprüfen und den Fehler explizit verarbeiten. Die impliziten Checks kann man dazu nutzen, Overflows während der Entwicklung zu finden. Zumindest für zeitkritischen Code sollte man die impliziten Checks im produktiven Code aber abschalten.

Substitution schrieb:

ich nutze lediglich objective-c-frameworks mit komfortabler Swift-Syntax.

Inwiefern ist die Swift-Syntax komfortabler? Wie vergleichst du die Syntax von zwei Sprachen, von denen du eine nicht kennst bzw. noch nie verwendet hast?

BTW: Finde den Fehler in folgender Zeile:

so langsam muss ich doch mal einschreiten - sonst fällt mein Thread noch auf Rang drei der meist kommentierten Beiträge ab
Jedes Swift-Thema, das länger ist als eine Seite besteht gefühlt zu mindestens 50% aus Unsinn, und im großen und ganzen ist der Inhalt immer der selbe ("Swift ist Mist", "Nein!", "Doch!"; repeat)
Mit der nötigen Distanz ist da ja irgendwie lustig, aber eigentlich nicht besser als die Fremdschäm-Formate der Privatsender...

Wie so oft ist die Lösung ja eigentlich ganz einfach, und zwar gerade jetzt:
Bei den meisten ist heute wahrscheinlich Bombenwetter, also raus an die frische Luft - es gibt keinen Preis dafür, den letzten Post eines Flamewars zu verfassen, und ignorieren ist das beste Mittel gegen diejenigen, die Streit als ihren Lebensinhalt betrachten.

Substitution schrieb:

BTW: Wozu nutzt man eigentlich noch Int8, Int16, usw.?
Früher hat man noch jeden Bit an Speicherplatz benötigt, ich verstehe aber einfach nicht, wieso man das heute nocn begrenzen muss.

Als einzelner Wert gibt es wahrscheinlich wirklich sehr wenig sinnvolle Anwendungsfälle. Wenn ich aber die Bytedaten eines 4GB großen Videos in den Hauptspeicher einlesen will gibt es einen riesigen Unterschied zwischen 8- und 32-Bitdatentypen.

Der Fehler in der Zeile hat übrigens nichts mit dem Datentyp zu tun.

Substitution schrieb:

Was ist der Fehler in der Zeile?

Der Compiler sagt dazu:

Könnt ihr mal mit euren nervigen "Könnt ihr mal mit eurem nervigen Swift-Geflame aufhören?"-Geflame aufhören?


Ja, klar. Wenn der zu addierende Wert negativ ist klappt das nicht blablubbgelöt.

Vielleicht auch

Was ich damit sagen will: Natürlich kann man nicht prüfen, ob INT_MAX überschritten würde, indem man es ausprobiert, weil INT_MAX nicht überschritten werden kann.
Das Compilerverhalten von INT_MAX+1 ist undefiniert und damit per Sprachstandard zu verrmeiden.

Man muss da schon ein wenig Überlegung reinstecken. DAS sollte man aber so oder so, wenn einem die 64 Bit Integer zu klein werden könnten.

.oO(Von Performance reden aber Int8 und Int64 als zu vernachlässigen definieren - lass das bloß keinen Embedded Developer hören!)

Naja, du kannst den Fehler auf zwei Arten beheben. Entweder fügst du vor dem Gleichheitszeichen Whitespace ein, oder du entfernst das Leerzeichen dahinter.

In einem hat der Club der alten Männer ja Recht: for (int i = 0; i < 10; i++) ist das Intuitivste, das seit der Erfindung des Faustkeils aufgeschrieben wurde.

Hihi, ich lese den Thread schon die ganze Zeit und komme aus dem Lachen nicht mehr raus