🚀 go-pugleaf

Elcaro Nosille <ElcaroNosille@akapost.com> wrote:

>   Richard W. K�nning schrieb:
>
>>> Das Problem sollte nicht das MT sein, sondern TeX zu verstehen und
>>> das umzubauen. Wenn man das aber direkt bei einer Entwicklung bedenkt,
>
>> Eben.
>
>Ja, aber deswegen ist MT nicht per-se schwierig. Code anderer Leute

MT per-se nutzt einem nichts. Das Drehen eines Autolenkrads ist per-se
auch trivial, schon zweij�hrige (oder noch j�ngere) Kinder k�nnen das.
Das Lenkrad so zu drehen, da� man nicht mit Botanik oder Architektur
kollidiert, ist nicht mehr ganz so einfach, insbesondere bei h�heren
Geschwindigkeiten.

Eine Anwendung so zu zerlegen, da� man hinreichend viele Teile erh�lt,
um alle verf�gbaren CPUs gleichm��ig auszulasten, ist alles andere als
trivial.

>zu verstehen und irgendwie umzubauen ist meistens ne aufw�ndige Sache;
>unabh�ngig davon ob der Code nun MT-f�hig werden soll oder nicht.

Es ist egal, ob der Code von anderen Leuten ist oder ob er �berhaupt
schon existiert. Wenn die Problemstellung keine triviale Aufspaltung
in parallele Teile erlaubt, dann ist die Aufspaltung halt nicht
trivial (bis hin zu unm�glich).

>>> ... dann ist's einfach.
>
>> Warum sollte es dann einfach sein? Wenn man nicht gen�gend
>> hinreichend unabh�ngige Teile findet, dann wird es schwierig.
>
>Ich wei� nicht was Du mit gen�gend unabh�ngigen Teilen meinst
>und kann mir hier mehrerlei darunter vorstellen.

Mit gen�gend unabh�ngigen Teile meine ich Teile der Programmlogik
(oder der Daten), die eine l�ngere Zeit ohne Kommunikation mit den
anderen Teilen abgearbeitet werden k�nnen.

>>> Im Falle von TeX k�nnte es aber relativ einfach sein weil man das
>>> Rendering durch Banding gr��tenteils parallelisieren k�nnte. Nur
>
>> Welches Rendering? TeX rendert nichts.
>
>Achso, Du meintest die �bersetzung nach DVI.

Ich habe TeX geschrieben, also meine ich auch TeX.

>> Das war mal anders, beim �bersetzen meiner Diss. konnte ich erst mal
>> ganz in Ruhe Kaffee trinken gehen (TeX ist nur ein Beispiel f�r ein
>> Programm, das zumindestens nicht trivial parallelisierbar ist, es
>> gibt gen�gend andere).
>
>Tja, dann frag ich mich ob MT denn hier �berhaupt not tut und nicht
>ein effizienteres TeX.

Bei gegebener Funktionalit�t mu� halt ein entsprechender Aufwand
getrieben werden, ich glaube kaum, da� TeX da soviele
Effizienzreserven hat. Was not tat, war eine CPU mit besserer
Mono-Leistung (und zeitweilig hatte ich auch statt eines 6 MHz 80286
eine iirc 10 oder 12 MHz CPU (m�glicherweise war diese schon ein
80386, aber da bin ich mir nicht sicher), damit ging es schon deutlich
flotter).
Ciao,
Richard
-- 
Dr. Richard K�nning          He�stra�e 63
Tel.: 089/5232488            80798 M�nchen