[Allegro] acon-Beobachtungen

[Bernhard Eversberg]

Thomas Berger schrieb:

> I.
> bei einem komplexen Export, der sich mit SRCH anstandslos produzieren liess,
> crashte acon (30.8.2010) mit Dr. Watson Nachf. Stundenlanges Eingrenzen
> zeigte dann die "uebliche" Ursache: Eine Schleifenkonstruktion, die eigentlich
> eine Variable aufessen sollte, bis die vollstaendige Leerung dann das
> Abbruchkriterium gewesen waere, verlaengerte die entsprechende Variable...

Die Schleifenkonstruktion müßte ich schon sehen. Es kommen tausendfach
solche Konstrukte vor, die klaglos klappen, daher ist mir das suspekt.

> 
> II.
> var "xy"
> xport param
> if no jump ...
> 
> brachte bei nichtvorhandener xy.apr leider nicht den lt. xexport.rtf
> vorgesehenen Sprung, sondern den beliebten "Exception error (Memory access)".
acon oder a99?
Diese Zeilen allein produzieren kein Fehlverhalten, weder in a99 noch in
acon, eben getestet. Es kommt also wohl auf den Zusammenhang an.

> 
> 
> III.
> Die zu exportierenden Datensaetze enthielten Kategorien, die mit einem oder
> mehreren "|" endeten (MAB-Fuellzeichen), Vergleich der Ergebnisse von acon und
> SRCH zeigte, dass in der acon-Variante ein "|" fehlte (und wenn es das einzige
> Inhaltszeichen war, fehlte die gesamte Kategorie). Ich habe den Verdacht, dass
> das Zeichen bei der Konstruktion
> fetch rec
> ...
> insert
> in srch.job auf der Strecke bleibt, ist das plausibel oder soll ich genauere
> Tests veranstalten?
Ja bzw. nein, das ist plausibel. Aber es ist ein Relikt, das wir mal
beseitigen sollten, d.h. a99 und acon davon bereinigen.

> 
> IV.
> Der Export konvertierte die Zeichen nach UTF-8, beim Start der Verarbeitung
> eines jeden Satzes sowie unmittelbar nach jeder erfolgreichen Nachladung wird
> #da
> gegeben (#dA aber nur beim Verarbeitungsende, nicht vor oder nach dem
> Rueckstapeln nachgeladener Saetze: ich hatte das so verstanden, dass #da auf
> den aktuell obersten Satz im Nachladestapel wirkt, ist dies gleichzeitig der
> unterste, wirkt es auch auf den Hintergrundspeicher.
Das ist, sehe ich gerade, nur bei a99/acon der Fall, nicht bei SRCH.
Sollten wir aber wohl korrigieren, d.h. auch SRCH sollte das so machen
(und PRESTO), weil ja nicht beim Nachladen eines Satzes jedesmal erneut
der Hintergrund auch verschoben werden sollte.

> Mit welcher "Magie" ueber
> |i8 und |i9 besetzte #uxi korrigiert werden, weiss ich leider nicht).
> 
Das sind #u-Variablen wie andere auch. Nur wenn sie im Moment des #da
existieren, werden sie konvertiert. Kommt im nächsten Moment ein |i8,
werden sie neu belegt (und "wissen" nichts vom vorangegangenen #da).

Zunächst: #dA ist überflüssig, wenn der Satz nicht zurückgespeichert
wird, d.h. kein "put" folgt, denn dann bleibt ja das Ganze für die
Datenbank folgenlos. Es ist nicht überflüssig, wenn nachfolgend mit
demselben Satz abermals eine Ausgabe veranstaltet wird, die #da enthält.

> In der SRCH-Variante waren allerdings in einigen Faellen Akzente um
> zwei Positionen verschoben (bzw. hinten aus dem Text "herausgefallen").
Dann hat vorher zweimal #da stattgehabt.

> Moegliche Probleme der Parameterdatei einmal beiseite gelassen (ich habe noch
> nicht systematisch untersucht, ob es in beiden Varianten uebereinstimmende
> inkorrekte Doppelverschiebungen gibt): In welcher Situation ist es denn
> moeglich, dass acon und SRCH.EXE Akzentvertauschung abweichend handhaben?
Nur in dem genannten Fall, wenn im Arb.Speicher nur ein Satz ist, kein
Stapel.

> Hat evtl. acon einen eingebauten "Schutz", so dass der Versuch einer erneuten
> Akzentvertauschung folgenlos bleibt, wohingegen SRCH diese ausfuehrt?
> 
Nein.

> 
> V.
> Durchfuehrung diverser Exporte (viele Nachladungen, jedoch keine V14-
> Expansionen, falls Suchbegriffe auf der Kommandozeile, dann auch -F
> angegeben) an einer kleinen Datenbank (etwa 150.000 Saetze, das gesamte
> Datenverzeichnis hat etwa 130MB) benoetigte mit SRCH.EXE im "Windows XP Mode"
> (virtueller PC mit Windows XP) etwa 34 Minuten bei konstant 25% CPU-Auslastung
> (einer von vier Kernen, mehr nutzt der "Windows XP Mode" nicht).
> 
> Dasselbe mit acon (und "meinem" srch.job) benoetigte ca. 20 Minuten (ebenfalls
> Vollauslastung mit 25% CPU-Last), d.h. die Beschleunigung durch das 32bit-
> Programm betraegt etwa den Faktor 1,7. Ist es denn wirklich unrealistisch,
> fuer acon dieselbe Leistungssteigerung um etwa Faktor 5 zu erwarten, wie
> wir sie fuer index.exe beim Uebergang vom 16 auf 32 bit erlebt haben?
> 
Dsa liegt daran, daß acon ein auf der Klassenbibliothek basierendes,
objektorientiertes C++-Programm ist, SRCH dagegen ein konventionelles
C-Programm, sehr kompakt und direkt programmiert. Objektorientierung
hat ihren Preis, wie man bei Java am überzeugendsten sieht. index.exe
ist, wie SRCH, konventionelles C, abgeleitet aus dem alten INDEX unter
Weglassung aller Oberflächenaspekte (reines Konsolprogramm).
Zum zweiten kommt wohl erschwerend hinzu, daß Ihr srch.job extrem
opulent gestaltet ist, vernachlässigend, daß eine interpretierte
Sprache (FLEX) mehr Zeit braucht, und daß sich lange Variablennamen und
weiter unten liegende Sprungziele etc. bei hochfrequenten Schleifen
dann umso hemmender bemerkbar machen. Ein Vergleich, ceteris paribus,
mit "meinem" srch.job könnte aber erweisen, wer von uns beiden hier
übertreibt. Wenn ich, dann überwiegt die Objektorientierung, und da dran
können wir nun leider nicht weiter herumoptimieren.

B.Eversberg