Smalltalk - Mehr als nur eine Sprache

Smalltalk - Mehr als nur eine Sprache

Posts 1-6 of 6
  • Hans Nikolaus Beck
    Hans Nikolaus Beck    Premium Member   Group moderator
    The company name is only visible to registered members.
    Smalltalk und Multicores
    Hi,

    Hyperthreaded CPUs und Multicore sind ja offensichtlich die Zukunft im PC Markt (bei MacOS ditto). Eröffnet das Möglichkeiten für Smalltalk ? Ich kann mich dunkel an Diskussionen erinnern, bei Squeak oder VW, aber ich habs nicht mehr gefunden.

    Weiß jemand, ob bei den kommerziellen STs vorgesehen ist, dass deren VMs ab einer Version x (ST) Prozesse auf Cores verteilen können ?

    Grüße

    Hans
    • 25 Oct 2005, 7:19 pm
  • Hans-Martin Mosner
    Hans-Martin Mosner
    The company name is only visible to registered members.
    Re: Smalltalk und Multicores
    Hans Nikolaus Beck schrieb:
    Weiß jemand, ob bei den kommerziellen STs vorgesehen ist, dass deren VMs ab einer Version x (ST) Prozesse auf Cores verteilen können ?
    So weit ich weiß, sieht VisualWorks das für absehbare Zukunft nicht vor. Smalltalk MT macht es ja schon lange, da kenne ich aber den aktuellen Status nicht.

    So weit ich weiß, sind Memory Management-Algorithmen, die mit Native Threads zurecht kommen, dünn gesät. Ich bin nicht sicher, ob die Umstellung einer stark optimierten VM wie VisualWorks mit einem realistischen Budget zu machen ist.
    Bei Neu-Entwicklungen, die das von vornherein berücksichtigen, kann das ganz anders aussehen.

    Tschüss,
    Hans-Martin
    • 26 Oct 2005, 10:27 am
  • Hans Nikolaus Beck
    Hans Nikolaus Beck    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Smalltalk und Multicores
    Hi Hans-Martin,
     
    So weit ich weiß, sind Memory Management-Algorithmen, die mit Native Threads zurecht kommen, dünn gesät. Ich bin nicht sicher, ob die Umstellung einer stark optimierten VM wie VisualWorks mit einem realistischen Budget zu machen ist.
    Ich frage mich in wie weit es die Argumentation für Smalltalk in Zukunft erschwert, wenn man zugeben muss, dass es Hardware-Parallelität nicht nutzen kann, denn offensichtlich sind Multicores und Multichips doch Stand der Dinge und in Zukunft gegeben sind wie heute die 3D Grafikkarte. Und das ist jetzt nicht zwingend die Frage ob sinnvoll oder nicht, aber so werden die potentiellen Kunden denken.

    Vielleicht könnte es so gehen: entweder wirklich die "Green Threads" auf diverse CPUs verteilen (und damit auf native Threads, was natürlich das Memory Management trifft), oder mehrere VMs (wie auch immer) kooperieren lassen.

    Grüße

    Hans
    • 26 Oct 2005, 7:50 pm
  • Hans-Martin Mosner
    Hans-Martin Mosner
    The company name is only visible to registered members.
    Re^3: Smalltalk und Multicores
    Hans Nikolaus Beck schrieb:

    Vielleicht könnte es so gehen: entweder wirklich die "Green Threads"
    auf diverse CPUs verteilen (und damit auf native Threads, was
    natürlich das Memory Management trifft), oder mehrere VMs (wie auch
    immer) kooperieren lassen.
    Das erste ist vermutlich zu schwierig und bringt mehr Probleme als es löst.
    VW kann mit seinen Green Threads problemlos etliche tausend Processes abbilden. Das bekommt man mit einer native threading Implementierung nicht hin.

    Mehrere VMs einzusetzen ist die Standard-Lösung für z.B. Server-Betrieb. Damit kommt man schon ziemlich weit.

    VW kann außerdem mit dem "Threaded" API für externe Schnittstellen zumindest die Ausführung von C-Funktionen parallelisieren. Das könnte z.B. für rechenintensive Applikationen wie Multimedia-Kram, Kryptographie oder Image-Rendering interessant sein.

    Aus meiner Erfahrung würde ich sagen, dass "Appeasement" nichts bringt. Wer mit solchen Argumenten gegen Smalltalk entscheidet, hat sehr oft andere Gründe im Hintergrund. Gegen diese hilft es überhaupt nicht, wenn man die vorgeschobenen Argumente entkräftet. Das kostet nur unnötig Zeit.
    Was anderes ist es, wenn jemand Smalltalk einsetzen *will* und an eine Performance-Grenze stößt. In den meisten Fällen ist es möglich, solche Probleme zu lösen, ohne eine grundsätzliche Reimplementierung der VM zu machen...

    Tschüss,
    Hans-Martin

    Update: Gerade habe ich diese Heise-Meldung gelesen: http://www.heise.de/newsticker/meldung/65437
    Insofern sollte man sich wirklich Gedanken darüber machen, ob es wirklich so viel bringt, native threads in Smalltalk zu unterstützen.
    Andere Ansätze, wie z.B. der von E (http://erights.org/) sind da möglicherweise besser geeignet. Die Konzepte von E werden auch in der Squeak-Community diskutiert, und es kann durchaus sein, dass Implementierungen des E-Konzepts für Smalltalk in absehbarer Zeit verfügbar werden. Mit einer performanten Kommunikation zwischen verschiedenen Objekträumen (Vats in E-Terminologie) könnte das auf Multicore-Systemen sehr interessant sein.
    This post was modified on 27 Oct 2005 at 11:40 am.
    • 27 Oct 2005, 10:48 am
  • Hans Nikolaus Beck
    Hans Nikolaus Beck    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^4: Smalltalk und Multicores
    Hi,

    Vielleicht könnte es so gehen: entweder wirklich die "Green Threads" auf diverse CPUs verteilen (und damit auf native Threads, was natürlich das Memory Management trifft), oder mehrere VMs (wie auch immer) kooperieren lassen.
     
    Das erste ist vermutlich zu schwierig und bringt mehr Probleme als es löst.
    Gut möglich
      >
     
    VW kann außerdem mit dem "Threaded" API für externe Schnittstellen zumindest die Ausführung von C-Funktionen parallelisieren. Das könnte z.B. für rechenintensive Applikationen wie Multimedia-Kram, Kryptographie oder Image-Rendering interessant sein.
    Stimmt, daran hatte ich noch nicht gedacht

     
    Aus meiner Erfahrung würde ich sagen, dass "Appeasement" nichts bringt. Wer mit solchen Argumenten gegen Smalltalk entscheidet, hat sehr oft andere Gründe im Hintergrund. Gegen diese hilft es überhaupt nicht, wenn man die vorgeschobenen Argumente entkräftet. Das kostet nur unnötig Zeit.
    Aacch, ich will nicht sagen dass es nur vorgeschobene Argumente sind. Die Frage an sich, wie man das Beste aus n cores herausholt ist ja berechtigt, ebenso wie die Frage ob n mal dasselbe laufen lassen schon das Maximum ist. Aber du hast natürlich recht - und wie auch in dem Heise Artikel angesprochen - die technische Lösung muss beherrschbar bleiben. Und es wäre sicherlich fatal, wenn man die Einfachheit bzw. Beherrschbarkeit des Smalltalksystems wegen unbedingter Unterstützung von native Threads gefährdet.

    Update: Gerade habe ich diese Heise-Meldung gelesen: http://www.heise.de/newsticker/meldung/65437
    Insofern sollte man sich wirklich Gedanken darüber machen, ob es wirklich so viel bringt, native threads in Smalltalk zu unterstützen.
    Andere Ansätze, wie z.B. der von E (http://erights.org/) sind da möglicherweise besser geeignet. Die Konzepte von E werden auch in der Squeak-Community diskutiert, und es kann durchaus sein, dass Implementierungen des E-Konzepts für Smalltalk in absehbarer Zeit verfügbar werden. Mit einer performanten Kommunikation zwischen verschiedenen Objekträumen (Vats in E-Terminologie) könnte das auf Multicore-Systemen sehr interessant sein.
    Klingt gut, muss ich mal lesen. Danke für den Tipp.

    Grüße

    Hans
    • 27 Oct 2005, 9:33 pm
  • Post visible to registered members