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

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • gritsch schrieb:

    torquato schrieb:

    gritsch schrieb:

    torquato schrieb:

    macmoonshine schrieb:

    gritsch schrieb:

    und warum checkt das der compiler nicht?
    Gute Frage bei einer Sprache, die ihre Anwender vor bösen Programmierfehlern schützen will. +scnr+ ;) Passt irgendwie so garnicht zu Optionals, statischer Typisierung & Co.Anscheinend unterstützt der Swift-Compiler kein Loop-Unrolling: bugs.swift.org/browse/SR-203
    Das ist bei Schleifen, deren Elemente über Objekte beschrieben werden, wahrscheinlich auch sehr schwierig.
    Daraus geht aber auch hervor, daß das seit dem 14. Dezember behoben ist.Hier der entsprechende commit: github.com/apple/swift/commit/…18b609378f0852251b8f56c12
    Nur, wenn der Compiler in diesen Fällen prüft, ob Loop-Unrolling möglich ist, sollte er natürlich gleich auch prüfen, ob die Schleife überhaupt möglich ist. Dürfte man wohl als Compiler-Bug betrachten.
    das beispiel dort sollte aber nicht "entfaltet" werden sondern komplett aufgelöst werden in r += 9 oder besser r = r + 9 um sicher zu sein dass es in der nächsten swift version noch funktioniert...
    Ähh... Das verstehe ich jetzt nicht. Könntest Du näher erläutern, was Du damit meinst? Geht's um die Commit-Message, den Code, den Unit Test?
    um den code in der commit-message:

    Quellcode

    1. for e in [2,3,4] {
    2. r += e
    3. }
    OK. Mmhhh... Danke.

    Ich verstehe Deinen Kommentar trotzdem leider noch nicht. Was ist hier der Unterschied zwischen 'entfalten' und 'komplett auflösen'?
    Ist so eine commit message nicht nur eine bloße Veranschaulichung, worum es gehen soll?
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • *seufz*

    Ich versteh's nicht. :(

    Würde ich aber gerne. Klingt interessant. Könntest Du dieses r+=9, 'auflösen', 'entfalten' und diese 499500 mir erklären? Ich verstehe es nicht. Ich stehe komplett auf dem Schlauch.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    *seufz*

    Ich versteh's nicht. :(

    Würde ich aber gerne. Klingt interessant. Könntest Du dieses r+=9, 'auflösen', 'entfalten' und diese 499500 mir erklären? Ich verstehe es nicht. Ich stehe komplett auf dem Schlauch.
    das ist das ergebnis.
    dem compiler sind ja die anfangs und enzahlen bekannt. in der schleife wird nur eine addition durchgeführt also kann der compiler gleich das resultat (500500) in einer einzigen addition zu r hinzufügen.

  • gritsch schrieb:

    macmoonshine schrieb:

    Das ist etwas anderes als Loop-Unrolling.
    Genau. Aber genau das macht man eben bei dem beispiel in der commit-message also ist das beispiel sehr schlecht gewählt.
    wenn man schon tausende zeilen code schreibt sollte man sich auch 1 min zeit nehmen um die commit-message zu schreiben (denn 99,99% lesen wohl eh nur diese und nicht den code).
    Wenn das wirklich nur für diesen Spezialfall ist, ist das sehr dürftig.
    „Meine Komplikation hatte eine Komplikation.“

  • gritsch schrieb:

    macmoonshine schrieb:

    Das ist etwas anderes als Loop-Unrolling.
    Genau. Aber genau das macht man eben bei dem beispiel in der commit-message also ist das beispiel sehr schlecht gewählt.

    Ah. OK. Meine Fragen wurden zwar noch nicht direkt beantwortet, aber ich denke, ich verstehe jetzt halbwegs. Die Commit-Message suggeriert eine Loop-Wegoptimierung, verspricht aber Loop-Unrolling.

    Aber selbst bei einer Wegoptimierung könnte man vorher natürlich einmal testen, ob upperBound > loweBound ist, oder?

    Ich hatte mir etwas erhofft, Loop-Unrolling besser zu verstehen.

    gritsch schrieb:


    wenn man schon tausende zeilen code schreibt sollte man sich auch 1 min zeit nehmen um die commit-message zu schreiben (denn 99,99% lesen wohl eh nur diese und nicht den code).

    Öhhh... Null-Komma.... Öhhh... zulang! Leute werden diesen Commit überhaupt je lesen. Ich habe die Wahrscheinlichkeit um einen Tausenderfaktor erhöht. :)
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    a könnten sich Berliner Flughafenbauer mal eine Scheibe von abschneiden. Wir eröffnen BER jetzt endlich offiziell termingerecht und leiten den Flugverkehr einfach temporär über Tegel um.
    Bring die nicht auf Ideen!
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • torquato schrieb:

    Gibt's beim Compilerbau oder allgemein bei Softwareprojekten eigentlich nicht sowas wie ein 'Pflichtenheft'? Na, egal.
    Ein Pflichtenheft setzt voraus, dass man vorher weiß, was man nachher haben möchte. Es handelt sich jedoch bei Swift um eine Spielerei, um mal zu sahen, was geht (und vor allem: was nicht geht). Der Fehler liegt darin, dass Apple das als einsatzfähige Programmiersprache verkauft hat.

    torquato schrieb:

    Apropos Zeit. Swift 3.0 wird pünktlich zum Herbst fertig, nur daß dann nicht alles dabei ist, was Swift 3.0 einmal hätte sein sollen.
    Aha! Dann ist BER aber auch pünktlich fertig, nur eben nicht vollständig.

    Der Mensch ist zu erstaunlichen geistigen Leistungen fähig, wenn man sich etwas schön reden will.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • macmoonshine schrieb:

    Ich vermute, dass gritsch die Schleife wegoptimieren (Gaußsche Summenformel) will. Das ist etwas anderes als Loop-Unrolling.
    Hi, hi, an Gauß musste ich auch denken. Ob Gritsch jetzt von torquato eine Ohrfeige kassiert?

    Quellcode

    1. for e in [2,3,4] {
    2. r += e
    3. }
    Na, ja, was komplett anderes vom Lösungsansatz nicht, eher der Folgeschritt. Nachdem man Loop-Unrolling gemacht hat, steht da folgendes:

    Quellcode

    1. r += 2
    2. r += 3
    3. r += 4

    Dann kann man schon darauf kommen, dass der Compiler daraus gleich

    Quellcode

    1. r += 9

    macht.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    macmoonshine schrieb:

    Ich vermute, dass gritsch die Schleife wegoptimieren (Gaußsche Summenformel) will. Das ist etwas anderes als Loop-Unrolling.
    Hi, hi, an Gauß musste ich auch denken. Ob Gritsch jetzt von torquato eine Ohrfeige kassiert?

    Ähh... Warum sollte ich? Das liegt mir fern. Ich finde es nur schade, daß Gritsch nicht ausführlicher auf meine Nachfragen geantwortet hat. Das klang mir danach, daß ich da etwas lernen kann. Und deswegen bin ich in Foren, wie diesem. Das beste Feedback ist es, was neues lernen zu können...

    PS: Nicht, daß da was falsch verstanden wird. Die 'Gaußsche Summenformel' kenne ich.^^
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Amin Negm-Awad schrieb:


    Quellcode

    1. for e in [2,3,4] {
    2. r += e
    3. }
    Na, ja, was komplett anderes vom Lösungsansatz nicht, eher der Folgeschritt. Nachdem man Loop-Unrolling gemacht hat, steht da folgendes:

    Quellcode

    1. r += 2
    2. r += 3
    3. r += 4

    Dann kann man schon darauf kommen, dass der Compiler daraus gleich

    Quellcode

    1. r += 9

    macht.

    Danke für die Aufsplittung in zwei Schritte. Interessant.

    Macht man Loop-Unrolling nicht immer in Schritten von einem Vielfachen von 2? ?( Um irgendwie die Register gleichmäßig, parallel zu saturieren? Keine Ahnung. Da kenne ich mich eben nicht aus... ;(
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Amin Negm-Awad schrieb:

    macmoonshine schrieb:

    Ich vermute, dass gritsch die Schleife wegoptimieren (Gaußsche Summenformel) will. Das ist etwas anderes als Loop-Unrolling.
    Hi, hi, an Gauß musste ich auch denken. Ob Gritsch jetzt von torquato eine Ohrfeige kassiert?
    Ähh... Warum sollte ich? Das liegt mir fern. Ich finde es nur schade, daß Gritsch nicht ausführlicher auf meine Nachfragen geantwortet hat. Das klang mir danach, daß ich da etwas lernen kann. Und deswegen bin ich in Foren, wie diesem. Das beste Feedback ist es, was neues lernen zu können...

    PS: Nicht, daß da was falsch verstanden wird. Die 'Gaußsche Summenformel' kenne ich.^^
    Na, mit der Kenntnis von der Gaußschen Summenformel, hättest du eigentlich nach nur wenigen Sekunden dir die Frage an gritsch sparen können. Das ist ja der Witz an ihr.

    Wie dem auch sei, es ist – wohl falsch – überliefert, dass der Lehrer, der Gauß' Rechnung nicht verstanden hatte, diesen zur Strafe ohrfeigte, weil er "pfuschen" annahm.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • torquato schrieb:

    Amin Negm-Awad schrieb:

    Quellcode

    1. for e in [2,3,4] {
    2. r += e
    3. }
    Na, ja, was komplett anderes vom Lösungsansatz nicht, eher der Folgeschritt. Nachdem man Loop-Unrolling gemacht hat, steht da folgendes:

    Quellcode

    1. r += 2r += 3r += 4

    Dann kann man schon darauf kommen, dass der Compiler daraus gleich

    Quellcode

    1. r += 9

    macht.
    Danke für die Aufsplittung in zwei Schritte. Interessant.

    Macht man Loop-Unrolling nicht immer in Schritten von einem Vielfachen von 2? ?( Um irgendwie die Register gleichmäßig, parallel zu saturieren? Keine Ahnung. Da kenne ich mich eben nicht aus... ;(
    Es ist egal, wie du das Loop-Unrolling machst, da es gritsch um den Schritt *nach* dem Loop-Unrolling ging. Meinetwegen kannst du das auch mit Hula-Hoop machen
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Es handelt sich jedoch bei Swift um eine Spielerei, um mal zu sahen, was geht (und vor allem: was nicht geht).

    Blödsinn. Das ist keine Spielerei, nur weil Du es gerne als solches Betrachten würdest. Das ist ein ernsthaftes Projekt.
    Die Würfel sind gefallen. Wir wissen heute nur noch nicht so ganz genau, welche Augenzahl dabei rauskommt. ;)

    Amin Negm-Awad schrieb:

    Der Fehler liegt darin, dass Apple das als einsatzfähige Programmiersprache verkauft hat.

    Andersrum. Eine Developer-Alpha-Preview wurde vom Marketing als 'ready for production' verkauft und die, die heute am lautesten schreien, haben damals dem Marketing geglaubt.

    Ich hatte die Verzögerung der ABI-Stabilität ins Spiel gebracht. Mal ein kurzer Einblick gefällig, was bisher so an ABI bei Cocoa und Objective-C in der Vergangenheit schief gelaufen ist?

    The laws of ABI changes
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Amin Negm-Awad schrieb:

    torquato schrieb:

    Amin Negm-Awad schrieb:

    Quellcode

    1. for e in [2,3,4] {
    2. r += e
    3. }
    Na, ja, was komplett anderes vom Lösungsansatz nicht, eher der Folgeschritt. Nachdem man Loop-Unrolling gemacht hat, steht da folgendes:

    Quellcode

    1. r += 2r += 3r += 4

    Dann kann man schon darauf kommen, dass der Compiler daraus gleich

    Quellcode

    1. r += 9

    macht.
    Danke für die Aufsplittung in zwei Schritte. Interessant.
    Macht man Loop-Unrolling nicht immer in Schritten von einem Vielfachen von 2? ?( Um irgendwie die Register gleichmäßig, parallel zu saturieren? Keine Ahnung. Da kenne ich mich eben nicht aus... ;(
    Es ist egal, wie du das Loop-Unrolling machst, da es gritsch um den Schritt *nach* dem Loop-Unrolling ging. Meinetwegen kannst du das auch mit Hula-Hoop machen
    Moment, nur um das zu verstehen. Meine Frage nach Loop-Unrolling ist egal, weil Gritsch dabei an Gänseblümchen denkt!? ?(
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Es ging mir nicht um die Gaußsche Summenformel sondern einfach darum dass der compiler das ergebnis kennt (anfangszahl, endzahl und addition) und dieses verwenden könnte. mact der llvm auch brav, nur der swift-compiler machts nicht.

    Ich habe 1000 als obergrenze verwendet damit eben loop-unrolling NICHT angewendet wird (was der swift compiler ja eh nicht macht).

  • gritsch schrieb:

    Es ging mir nicht um die Gaußsche Summenformel sondern einfach darum dass der compiler das ergebnis kennt (anfangszahl, endzahl und addition) und dieses verwenden könnte. mact der llvm auch brav, nur der swift-compiler machts nicht.

    Ich habe 1000 als obergrenze verwendet damit eben loop-unrolling NICHT angewendet wird (was der swift compiler ja eh nicht macht).
    Warum ist 1000 eine sichere Grenze, um Loop-Unrolling auszuschließen? Und wird es eigentlich nicht erst ab einer gewissen Grenze interessant? ?(

    Die ganze LLVM-Architektur ist Schichtbasiert und fußt auf einen Pseudo-Code-Zwischenschritt, einen virtuellen Code. Deshalb das 'V' in LLVM. Da wird er IR, 'Intermediate Representation' genannt.
    Sämtliche Compiler, die auf LLVM aufbauen, erzeugen diesen IR-Zwischencode, auch Clang für Objective-C. LLVM hat eine Optimierungsphase für IR-Code.
    Die Swift-Compiler-Architektur verwendet einen zusätzlichen Pseudocode-Zwischenschritt. SIL. 'Swift Intermediate Language'. Aus verschiedenen Gründen. Z.B. werden Swift Apps als SIL in den App-Store geladen, um erst von da aus auf die einzelnen Plattformen kompiliert zu werden...
    Dieses SIL erfährt selbst noch eine Optimierungsphase, SIL Optimization, bevor es an LLVM für IR weitergereicht wird.

    Mir leuchtet jetzt nicht ein, wieso Du davon ausgehen kannst, daß es in Swift gar kein Loop-Unrolling geben sollte. Ich dachte, das wird spätestens in LLVMs IR gehändelt? Objective-C mit Clang hat Loop-Unrolling. Wenn Swift das gar nicht hätte, dann würden ja auch zahlreiche Performance-Tests furchtbare Vergleichsdaten für Swift liefern. Was so nicht der Fall ist. ?(
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Amin Negm-Awad schrieb:

    Es handelt sich jedoch bei Swift um eine Spielerei, um mal zu sahen, was geht (und vor allem: was nicht geht).
    Blödsinn. Das ist keine Spielerei, nur weil Du es gerne als solches Betrachten würdest. Das ist ein ernsthaftes Projekt.
    Die Würfel sind gefallen. Wir wissen heute nur noch nicht so ganz genau, welche Augenzahl dabei rauskommt. ;)

    Amin Negm-Awad schrieb:

    Der Fehler liegt darin, dass Apple das als einsatzfähige Programmiersprache verkauft hat.
    Andersrum. Eine Developer-Alpha-Preview wurde vom Marketing als 'ready for production' verkauft und die, die heute am lautesten schreien, haben damals dem Marketing geglaubt.

    Ich hatte die Verzögerung der ABI-Stabilität ins Spiel gebracht. Mal ein kurzer Einblick gefällig, was bisher so an ABI bei Cocoa und Objective-C in der Vergangenheit schief gelaufen ist?

    The laws of ABI changes
    Aha, das Marketing gehört nicht zu Apple. Interessant. Wessen Marketing war es dann? Übrigens hat es Lattner als Spielerei verkauft. Und das ist es auch, ganz unabhängig von meiner Betrachtung. Jedenfalls kein einsatzfähiges Produkt.

    "Verzögerung" ist gut. Vielleicht solltest du im Marketing von Apple arbeiten. Ach, nein, Apple war es ja gar nicht.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?