Perl 6 und Nebenläufigkeit (Raku / Perl 6)

[thread]14438[/thread]

Perl 6 und Nebenläufigkeit

Leser: 30

Articles: hide open all | hide show old branches

+11 replies
leo11

2009-01-02 18:35

User since
2008-08-14
250 Artikel
BenutzerIn

Ich hoffe auf einen Schalter im Compiler/Interpreter. Einmal umgelegt und zack kann man wie bisher programmieren und es werden alle Prozessoren ausgelastet so das ein Programm bei 4 Prozessoren erheblich schneller läuft als bei einem. Nach dem was ich bisher gelesen habe wird das wohl nix. Nebenläufig programmieren geht eng einher mit seiteneffektfreien Programmieren. Also funkional. Was wiederum ganz was anderes ist als deklarativ und für's alltagsgeschäft sicher nicht attraktiv... .

Würd mich intressieren was man bzgl. Perl 6 und Nebenläufigkeit sagen kann.

Auch ganz allgemein (unabhängig von Perl 6), was ihr so an Konzepten kennt um der Sache her zu werden.
Last edited: 2009-01-02 18:36:57 +0100 (CET)
- +2 replies
- lichtkind
  
  2009-01-02 21:50
  
  User since
  2004-03-22
  5679 Artikel
  ModeratorIn + EditorIn
  
  das ist ein thema um das sich larry eher drückt und wo er mehr auf parrot leute wartet bis sie mit vorschlägen kommen. das subsystem für concurency ist auch eher noch ein draft soweit ich weiss
  
  http://docs.parrot.org/parrot/latest/html/docs/pdd...
  Tutorien in der Wiki, mein zeug:
  kephra, baumhaus, garten, gezwitscher
  
  Es beginnt immer mit einer Entscheidung.
  - leo11
    
    2009-01-03 09:34
    
    User since
    2008-08-14
    250 Artikel
    BenutzerIn
    
    Ok, danke. Scheint nicht gerade das beliebteste Thema zu sein. (-;
- murphy
  
  2009-01-03 14:01
  
  User since
  2004-07-19
  1776 Artikel
  HausmeisterIn
  
  2010-01-02T17:35:37 leo11
  Ich hoffe auf einen Schalter im Compiler/Interpreter. Einmal umgelegt und zack kann man wie bisher programmieren und es werden alle Prozessoren ausgelastet so das ein Programm bei 4 Prozessoren erheblich schneller läuft als bei einem.
  
  Das ist ein Wunsch, der nicht eher in Erfüllung gehen wird, als es eine KI gibt, die wesentlich besser programmieren kann als Du selbst, die Intention Deines Programmes erkennt und es als parallele Variante neu schreibt ;-)
  
  Für begrenzte automatische Parallelisierung gibt es zwar Ansätze (zum Beispiel OpenMP für C, C++ und FORTRAN), aber ohne darauf zu achten, wie man sein Programm strukturiert kommt dabei auch kein guter Code heraus.
  
  Quote
  Nach dem was ich bisher gelesen habe wird das wohl nix. Nebenläufig programmieren geht eng einher mit seiteneffektfreien Programmieren.
  
  Naja, nebenläufige Programmierung funktioniert mit und ohne Seiteneffekte. Es ist nur bei weitem einfacher und effizienter seiteneffektarmes Multithreading zu betreiben, weil beim Programmieren einige lästige und schlecht zu findende Fehlerquellen ausgeschlossen werden und zur Laufzeit Synchronisationsaufwand eingespart wird.
  
  Quote
  Also funkional. Was wiederum ganz was anderes ist als deklarativ und für's alltagsgeschäft sicher nicht attraktiv... .
  
  Dass funktionale Programmierung in den meisten Fällen einfach eleganter und weniger fehleranfällig ist gilt auch für serielle Programme. Warum es für den Alltag nicht attraktiv sein soll, eine bessere Technik zu verwenden, die Arbeit spart, leuchtet mir nicht wirklich ein ;-)
  
  Quote
  [...]
  Auch ganz allgemein (unabhängig von Perl 6), was ihr so an Konzepten kennt um der Sache her zu werden.
  
  Ich persönlich finde expliziten aktorenbasierten Parallelismus ganz angenehm zu programmieren. Und eine Bibliothek die Operationen wie map und fold automatisch parallel ausführt ist auch praktisch.
  When C++ is your hammer, every problem looks like your thumb.
- +6 replies
- sid burn
  
  2010-01-04 13:11
  
  User since
  2006-03-29
  1520 Artikel
  BenutzerIn
  
  Soweit ist es ja bisher geplant auch in der Perl 6 Spezifikation (soweit ich mein) das einige Operatoren Parallel ausführbar sind. Ob dies dann letztendlich wirklich genutzt wird hängt dann wohl von der Implementierung ab. Rakudo macht es derzeit ja nicht. Ob der neue Rakudo "ng" branch das macht der ja auch lazy mit sich bringt weiß ich nicht.
  
  Was ich toll finden würde wäre wenn man an einer Subroutine einfach eine Art Flag anbringen kann und somit mitteilen kann das diese Funktion Seiteneffektfrei ist. Was dann wiederrum dazu führt das Parrot weiß das er diese Funktion/Methode auch Parallel ausführen kann.
  
  Ein map/grep oder auch for schleifen die dann nur seiteneffektfreie sachen nutzen kann er dann automatisch optimieren soweit es möglich ist.
  
  Aber vielleicht ist das ja auch nachträglich als Perl 6 Modul möglich. An der Syntax so ein Flag zusätzlich einzubauen sollte es zumindest nicht scheitern da Perl 6 ja anpassbar ist.
  
  Ansonsten halte ich diesen Punkt selber für ziemlich wichtig. In den letzten Jahren und wohl auch in den nächsten Jahren werden wohl die Anzahl der CPU Kerne immer weiter steigen. Eine Sprache die derzeit immer noch in der Enwtwicklung ist und auf solch eine Hardware Entwicklung nicht reagiert dazu fällt es mir irgendwie schwer zu sagen das solch eine Programmiersprache "Modern" wäre.
  
  Dann macht es vielleicht wirklich in Zukunft mehr Sinn einfach Perl 5 + Moose (und weitere Moderne Module zu nutzen) solange wie es möglich ist. Und irgendwann dann mal einfach auf Haskell etc. umzusteigen anstatt Perl 6 zu lernen.
  Last edited: 2010-01-04 13:14:24 +0100 (CET)
  Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
  - +3 replies
  - Taulmarill
    
    2010-01-04 13:21
    
    User since
    2004-02-19
    1750 Artikel
    BenutzerIn
    
    Ich meine auch gelesen zu haben, dass bei (hyper? meta?) Operatoren wie z.B. @foo = @bar [+] @baz; darauf geachtet werden soll, dass die Reihenfolge der Additionen nicht fest steht sondern von der Implementation abhängt, damit das parallelisiert werden kann.
    
    Kann das jemand bestätigen? Ich suche noch mal ob ich das wiederfinde.
    $_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78 0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0 F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B
    - +2 replies
    - sid burn
      
      2010-01-04 13:42
      
      User since
      2006-03-29
      1520 Artikel
      BenutzerIn
      
      Jup ist es. Das wurde beim Perl 6 Adventskalender erwähnt.
      
      http://perl6advent.wordpress.com/2009/12/01/perl-6...
      
      Genauer wurde es hier erwähnt: http://perl6advent.wordpress.com/2009/12/06/day-6-...
      
      Quote
      However much you are tempted to write @array>>.say, don’t do it. It may work in the current version of Rakudo, but by using the hyper operator you are promising the operation is parallelizable, and the order of the operations on the list(s) is not fixed. The hope is that future versions of Perl 6 will automatically run these operations in parallel.
      
      Soweit wie es ausschaut sind die ganzen Metaoperatoren die auf einer Liste arbeiten automatisch schon so das hier Parallelisiert werden kann. Bzw man muss drauf achten das diese eben Parallel ablaufen dürfen. Das gleiche gilt auch für die any(), or() und and() "funktionen". Also z.B.
      
      Code (perl): (dl )
      
      if ( $irgendwas == 1|3|5 ) { ... }
      
      Hab den Name gerade vergessen.
      Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
      - leo11
        
        2010-01-04 14:59
        
        User since
        2008-08-14
        250 Artikel
        BenutzerIn
        
        Intressant.
        
        Ich bin von anderer Seite hierauf aufmerksam geworden:
        http://clojure.org/
        
        Dazu gibt's im aktuellen Linux-Magazin nen Artikel,der auch online zu lesen ist:
        http://www.linux-magazin.de/Heft-Abo/Ausgaben/2010/01/Nebenlaeufig?category=0
        
        Falls ihr das Skript mal ausprobieren wollt: Nachdem es mit REPL-> load-file geladen wird muss man es hiermit aufrufen:
        (de.linuxmagazin.cpu-heizung/mandelbrot-parallel)
        
        Die Prozessoren werden tatsächlich ganz ähnlich ausgelastet.
  - +2 replies
  - lichtkind
    
    2010-01-04 15:13
    
    User since
    2004-03-22
    5679 Artikel
    ModeratorIn + EditorIn
    
    ist es nicht erlang das auf parallelität ausgelegt ist?
    Tutorien in der Wiki, mein zeug:
    kephra, baumhaus, garten, gezwitscher
    
    Es beginnt immer mit einer Entscheidung.
    - sid burn
      
      2010-01-04 15:43
      
      User since
      2006-03-29
      1520 Artikel
      BenutzerIn
      
      Ja Erlang ist speziell eine Programmiersprache die auf Parallelisierbarkeit ausgelegt ist. Aber Funktionalen Sprachen wie Haskell bieten das vom Design her schon. Bzw Erlang ist ja ebenfalls eine Funktionale Programmiersprache.
      
      Haskell im speziellen ist zum Beispiel mehr statisch Typisierter als C. Dadurch kann die Sprache selber vieles annehmen. Zum Beispiel können Funktionen in Haskell keine Nebenläufigkeit haben. Das bedeutet eine Funktion mit aufgerufenen Parameter muss absolut immer das gleiche zurück liefern. Dadurch das es so definiert ist kann auch jede Funktion Parallel ausgeführt werden in Haskell und der GHC Compiler macht davon auch gebrauch.
      
      Jedenfalls muss man nicht speziell Programmieren und die Haskell Implementierung kann automatisch mehrere CPU Kerne nutzen. In Perl ist das z.B. nicht möglich da jede Funktion ja Nebenläufigkeit haben kann und es eben nicht sichergestellt ist das eine Funktion mit den gleichen Parametern auch das gleiche zurück liefert.
      
      Ansonsten ist dies bei Funktionalen Sprachen vom Design her wohl eher der Fall als bei den Imperativen/OOP Sprachen. So das hier diese Optimierung automatisch vorgenommen werden kann.
      
      Zumindest weiß ich das bei Haskell automatisch shcon ein Teil auf mehreren Kerne ausgelagert werden kann ohne das der Programmierer speziell dafür Programmieren muss. Ansonsten gibt es soweit ich wohl gesehen habe auch für Haskell Module womit man mehrere CPU Kerne explizit ansprechen kann. Erlang wird das wohl von sich aus schon eingebaut haben.
      
      Allerdiengs kenne ich Haskell und auch Erlang nicht genau genug um da genaues zu sagen zu können.
      
      Um aber auf Perl 6 zurück zu kommen so finde ich das schon gut das bei manchen Operatoren Parallelisierbarkeit gefordert wird. Wäre aber toll wenn die Sprache noch mehr darauf ausgelegt wird. Bzw wenn soetwas auch nachher als ein Modul möglich wäre ist das Sicherlich auch volkommen okay.
      
      Ich habe bisher noch keine Sprache entworfen und kenne da nicht genau die Möglichkeiten von Parrot und/oder Rakudo. Da aber Perl 6 ja beliebig anpassbar ist von der Syntax kann man denke ich später wohl einiges nettes dazu entwickeln oder als Modul anbieten.
      
      Zumindest wäre es gut wenn man einige Sachen schon direkt in der Sprache verpflanzen könnte was Multitasking angeht.
      Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
- moritz
  
  2010-01-04 17:01
  User since
  2007-05-11
  923 Artikel
  HausmeisterIn
  2010-01-02T17:35:37 leo11
  Ich hoffe auf einen Schalter im Compiler/Interpreter. Einmal umgelegt und zack kann man wie bisher programmieren und es werden alle Prozessoren ausgelastet so das ein Programm bei 4 Prozessoren erheblich schneller läuft als bei einem.
  
  Das geht nur so weit gut, wie die statische Analyse des Compilers Abhängigkeiten erkennen kann. Und es ist auch eine Frage des Algorithmus - einige lassen sich sehr leicht parallelisieren, andere fast gar nicht. Vollständig automatisch wird das wohl immer ein Traum bleiben.
  
  Quote
  Würd mich intressieren was man bzgl. Perl 6 und Nebenläufigkeit sagen kann.
  
  Darauf gibt es mehrere mögliche Antworten:
  
  1) Larry will ein concurrency-Modell, dass Threads und Events vereint, inspiriert von diesem Paper.
  
  2) Einige Sprachfeatures parallelisieren automatisch. Wer implizite Abhängigkeiten zwischen den parallelen Aufrufen einbaut oder sich auf die Ausführungsreihenfolge verlässt, ist selbst Schuld.
  
  Dazu gehören die "hyper"-Operator und feeds:
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9 10 11
  
  @result = @array».method(); @result = hyper @array.map: { .method }; @result = @array1 »+« @array2; # Elementweise Addition # ähnlich wie UNIX pipes, nur mit Objekten: @source ==> function1 ==> grep { $_ % 2 == 0 } ==> function2 ==> @result
  
  3) Unabhängig vom genauen Nebenläufigkeitsmodell ist Perl 6 so designed, dass möglichst viel Information lexikalisch gehalten wird, was micro-threading deutlich vereinfacht. Es gibt auch kaum wirklich globale Variablen in einem Perl 6-Programm.
  
  Dass Larry sich vor concurrency drücken mag, wie lichtkind angedeutet hat, geht am Kern des Problems vorbei: Alle Teile der Spezifikation, die noch von niemandem implementiert wurden, sind mit Vorsicht zu genießen, und es lohnt sich nicht, viel Arbeit reinzustecken, solange es niemand implementiert. Erst bei der Implementierung merkt man, wo die Probleme liegen, und wo Potential für Erweiterungen liegen.
  Perl 6 - Perls Zukunft

View all threads created 2009-01-02 18:35.