[Allegro] 64bit-welt: allegro auf dem wege dahin?

Fr Mär 9 19:13:24 CET 2012

guten tag herr berger, danke für ihren beitrag, den ich auch wieder 
verstanden habe (danke!)

meine anmerks dazu. 
diese notiere unten das betreffende statement von Ihnen.

Guten Tag [Frau/Herr] Thomas Berger,
danke für Ihre Nachricht.
Am Freitag, 9. März 2012 um 11:19 schrieben Sie mir.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Meine Aeusserungen waren eher abstrakt gemeint bzw. auch
> vor dem Hintergrund des Problems bei Import.exe

naja. aber wir müssen darüber eben nachdenken. es wird schon zu 
irgendwelchen giga-datenbanken kommen. unten schreiben sie: stl 
bekommt ein problem bei ca 30 millio's an datensätzen...

> Etwas konkreter ist es so: Es ist zwar bereits einmal eine Umstellung
> erfolgt, naemlich von 16bit auf 32bit, diese aber nicht unbedingt
> aktuell mit srch32.exe etc., sondern vor allem bei der Entwicklung
> der Klassenbibliothek ab 1997(?), und damit war auch der Umstieg
> von C auf C++ als Programmierplattform verbunden. Es ist extrem
> unwahrscheinlich, dass die derzeitigen C- und C++-Programme sich
> durch einfaches Umlegen eines Schalters sauber fuer 64bit-Plattformen
> compilieren lassen. Es ist aber durchaus /moeglich/, dass eine
> Umstellung auf 64bit dennoch einfacher sein wird als die Umarbeitung in
> Richtung 32bit plus Support fuer grosse Dateien. Oder dass eine
> Umstellung auf 64bit-Faehigkeit den Code insgesamt so saeubert, dass
> die Erweiterung unter 32bit deutlich einfacher wird. Und letztlich
> ist durch 32bit erweitert die irgendwann faellige Umstellung auf
> 64bit ja nicht unbedingt abgewendet...

zur diskussion: welche 64bit-tools benötigen wir(?) unbedingt?
oder benötigt man zur herstellung von großen giga-datenbanken.
also: ich melde mich!

ich kann mir vorstellen:
index/qrix muss sein. (ohne die beiden kann man eine datenbank nicht 
erzeugen und nicht in ihr suchen). 
[doofe frage: kann avanti/acon das?]

a99.exe wäre für den direkten zugriff nicht schlecht, wenn man auf 
win-ebene rein will.

was fehlt?

> Geht es um konkrete Datenbanken, ist nicht nur die Kompatibilitaet
> bzw. Umschaltbarkeit der Sourcen oder der Binaries Thema, sondern
> auch die der realen Datenbanken (.CLD-Dateien und Indices):
- Indexdateien >> 2GB sind definitiv das Aus fuer PRESTO etc.,
>   aber "DOS ist tot" wurde etwa 1995 bereits angekuendigt, ist
>   unter Windows 7 x86_64 oder Server 2008 R2 Tatsache geworden,
>   da braucht nun allegro m.E. nicht mehr viel Ruecksicht zu
>   nehmen.

aufgepasst: im consumerbereich sind knapp 100% der pc's mit win7-64bit 
ausgestattet. im geschäfts/businessbereich (also auch für archive/bibliotheken) 
mag es etwas anderes aussehen. ich schätze da den anteil auf 80% (mit win7-64bit).
mir liegen keine genauen zahlen vor. reine erfahrungswerte. wo neue 
pc's gekauft werden, kauft keiner welche mit 32bit-betriebsystemen. 
übrigens: auch nicht mit lunixern. IST BEIDES eine falsche 
beobachtung? wer kennt bibliotheken, die BEWUSST -in den letzten 
beiden jahren- 32bit-betr.systeme gekauft haben????

mir lagen mal zahlen vor: (sind knapp 2 jahre alt!)
Aktuelle Zahlen vom Juli 2010 sagen (aus Microsoftquellen, zitiert in der c't 2010, Heft 16 auf Seite 35 oben "Windows7: Auf dem Weg zu 64bit") uns:
46% aller W7-Lizenzen sind 64bit. 11% sind es bei Vista. [nur] 1% bei WXP.
zitiert bei http://portal.allegronet.de/allegro/allegro-c-ist-32bit/

> - Solange es noch 32bit-Plattformen gibt, sollte man natuerlich darauf
>   achten, dass Datenbanken zu einer Version binaerkompatibel sind,
>   egal ob sie mit 32- oder 64-bit-Modulen erzeugt wurden.

ja, unbedingt!

> - Die .STL-Datei hat - beim Wert i0=72 aus cat.api - ein 2GB-Problem,
>   das bei knapp 30 Millionen Datensaetzen zuschlagen wird. Konzeptionell
>   muss sie aber ohnehin irgendwann einmal hinterfragt werden, in
>   Web-Kontexten ist sie fuer die Anzeige normalerweise schon laengst
>   irrelevant, und ihre Nuetzlichkeit beim Sortieren ist traditionell
>   leider recht unterentwickelt.

haben die bayern-daten nicht diese größe? 
wenn ich mal zeit hätte.....

> - Derzeit, mit Aufbohrung, ist das Verhaeltnis ansonsten recht ausgewogen:
>   Der maximale Aufbohrfaktor ist 124, damit kann man 255 .cLD-Dateien
>   beschicken, die jeweils etwa 1,85GB gross sind, insgesamt also
>   eine Datenbankgroesse von ca. 470GB, die - bei "kleinen" Datensatz
>   laengen von weniger als 119 Bytes, dem theoretischen Maximum von
>   4,29 Milliarden adressierbaren Datensaetzen recht nahe kommt.
>   Demgegenueber steht, dass man mit der Multix-Methode maximal 36
>   je 2 GB grosse Einzelindex-Dateien fahren kann (72GB Index fuer 470GB
>   Datenbank ist wenig, das wuerde ich bereits fur eine 47GB grosse
>   Datenbank erwarten), und auch jedes logische Register fuer sich nur
>   <2GB Umfang haben darf: Indexiert man fuer ein Uebernahmeregister
>   Koerperschaftsansetzungen und -verweise in voller Laenge (bei maximaler
>   Indexbreite von 250 Zeichen), dann bekommt man u.U. schon bei 8 bis 10
>   Millionen /Eintragungen/ Probleme, also einer deutlich geringeren Zahl
>   von Datensaetzen.

ich möchte dieses unterstreichen. kann dem nur vollzustimmen.

naja... 
herr lackhoff hat gerade geschrieben: ".... u.ae. fuer viel wichtiger halte als ein Allegro fuer
Terabyte-Datenbanken." auch da gebe ich zustimmung. was seine wünsche 
angeht. aber: wer, wenn nicht allegro, ist die datenbank?
komme mir bitte keiner mit dem drecksXML... ;-)

>   Ich denke, insgesamt effizientere Indexierung (und nicht nur Dateien
  >>2GB) wird irgendwann auch Thema fuer allegro werden und fuer den
>   dann zu erwartenden Kompatiblitaetsbruch kann man auch Optimierungen
>   in der allgemeinen Datenhaltung in Bezug auf hoeherbittige Plattformen,
>   evtl. sogar interne Speicherung in Unicode etc. vorsehen.

unicode benötigt bei 2bytes das doppelte? wenn ich das mit ascii 
vergleiche. also habe ich auch einen doppelten (oder ist das 
mathematisch falsch? korrekter: hoch zwei????= platzbedarf bei einer 
"indexeintragung"

ich habe da so eine ahnung, daß wir der dos-umgebung bald wehtun 
werden..... (müssen)

viele grüße
klaus lehmann

ps: ich bin nicht 32bit-apostel.
ganz im gegenteil: immer konnte ich schneller mit presto sein.
im sommer: diese elendigen schmerzen der maushand! "dank" a99.exe

> viele Gruesse
> Thomas Berger

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
* http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
* allegronet.de * Klaus Lehmann * D-01454 Radeberg * Kleinwolmsdorfer Str. 37
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow
* Yes we can. Only with allegro. Yes we do. Allways with allegro.
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 with VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki

Am Freitag, 9. März 2012 um 11:19 schrieben Sie:
> Hallo Herr Lehmann,

>> 2b. die konsequenz dessen, was da unten geschildert wird
>> zitat: 
>>> Fazit: Versucht man fuer *32bit-Plattformen* die 2GB-Grenze zu umschiffen,
>>> muss man recht viel im Code aendern, staerker die unterschiedlichen Welten
>> , ist: mit echten 64bit-tools zu arbeiten, wenn man gewisse grenzen 
>> überschreitet oder schreiten muss. 
>> ein qrix.exe, welches nach unten kompatibel bleiben will, so umzubauen, daß es beiden welten 
>> (=lesbar/erzeugbarkeit von größer als 2GB-dateien), geht nicht. 
>> ein qrix.exe, welches nur in der 64bit-welt lebt, sei einfach zu bauen.
>> das hiesse, ein gespann index/qrix.exe für 64bit muß her. habe ich das 
>> richtig verstanden? allegro ist auf dem weg ins 64bit-wunderland! ;-)

> Meine Aeusserungen waren eher abstrakt gemeint bzw. auch
> vor dem Hintergrund des Problems bei Import.exe

> Etwas konkreter ist es so: Es ist zwar bereits einmal eine Umstellung
> erfolgt, naemlich von 16bit auf 32bit, diese aber nicht unbedingt
> aktuell mit srch32.exe etc., sondern vor allem bei der Entwicklung
> der Klassenbibliothek ab 1997(?), und damit war auch der Umstieg
> von C auf C++ als Programmierplattform verbunden. Es ist extrem
> unwahrscheinlich, dass die derzeitigen C- und C++-Programme sich
> durch einfaches Umlegen eines Schalters sauber fuer 64bit-Plattformen
> compilieren lassen. Es ist aber durchaus /moeglich/, dass eine
> Umstellung auf 64bit dennoch einfacher sein wird als die Umarbeitung in
> Richtung 32bit plus Support fuer grosse Dateien. Oder dass eine
> Umstellung auf 64bit-Faehigkeit den Code insgesamt so saeubert, dass
> die Erweiterung unter 32bit deutlich einfacher wird. Und letztlich
> ist durch 32bit erweitert die irgendwann faellige Umstellung auf
> 64bit ja nicht unbedingt abgewendet...

> Geht es um konkrete Datenbanken, ist nicht nur die Kompatibilitaet
> bzw. Umschaltbarkeit der Sourcen oder der Binaries Thema, sondern
> auch die der realen Datenbanken (.CLD-Dateien und Indices):
- Indexdateien >> 2GB sind definitiv das Aus fuer PRESTO etc.,
>   aber "DOS ist tot" wurde etwa 1995 bereits angekuendigt, ist
>   unter Windows 7 x86_64 oder Server 2008 R2 Tatsache geworden,
>   da braucht nun allegro m.E. nicht mehr viel Ruecksicht zu
>   nehmen.

> - Wenn aber keine 16bit-Programme mehr auf den Index etc. zugreifen,
>   dann kann man auch daran denken, an den internen Strukturen diverse
>   Optimierungen (v.a. Alignierungen) vorzunehmen, von denen die Performance
>   von 32- und 64bit-Programmen deutlich profitieren duerfte: Also z.B.
>   "vorne" in der .TBL-Datei noch zwei oder 6 Leerbytes spendieren, damit
>   dann alle Adressen der Satznummern auf durch 4 oder sogar 8 teilbaren
>   Dateioffsets wohnen. Desgleichen fuer die Daten in den .cLD-Dateien,
>   ungefaehr entsprechend einem Faktor 4 oder 8 fuer die 1999 fuer
>   "spaete" v16's erfolgten "Aufbohrung".

> - Das bedeutet aber, dass man eine "alte" Datenbank erst reorganisieren
>   muss, bevor man mit "neuen" Programmen damit arbeiten kann (und
>   umgekehrt, also zurueck von neu zu alt, geht es evtl. gar nicht).
>   Anderswo ist das normal (inkompatible Aenderungen sind "major releases"
>   vorbehalten und umgekehrt ist eigentlich bei jedem "major release"
>   mit Umsetzungen oder Rekonfiguration zu rechnen), allegro jedoch
>   tickt normalerweise anders...

> - Solange es noch 32bit-Plattformen gibt, sollte man natuerlich darauf
>   achten, dass Datenbanken zu einer Version binaerkompatibel sind,
>   egal ob sie mit 32- oder 64-bit-Modulen erzeugt wurden.

> - Die .STL-Datei hat - beim Wert i0=72 aus cat.api - ein 2GB-Problem,
>   das bei knapp 30 Millionen Datensaetzen zuschlagen wird. Konzeptionell
>   muss sie aber ohnehin irgendwann einmal hinterfragt werden, in
>   Web-Kontexten ist sie fuer die Anzeige normalerweise schon laengst
>   irrelevant, und ihre Nuetzlichkeit beim Sortieren ist traditionell
>   leider recht unterentwickelt.

> - Derzeit, mit Aufbohrung, ist das Verhaeltnis ansonsten recht ausgewogen:
>   Der maximale Aufbohrfaktor ist 124, damit kann man 255 .cLD-Dateien
>   beschicken, die jeweils etwa 1,85GB gross sind, insgesamt also
>   eine Datenbankgroesse von ca. 470GB, die - bei "kleinen" Datensatz
>   laengen von weniger als 119 Bytes, dem theoretischen Maximum von
>   4,29 Milliarden adressierbaren Datensaetzen recht nahe kommt.
>   Demgegenueber steht, dass man mit der Multix-Methode maximal 36
>   je 2 GB grosse Einzelindex-Dateien fahren kann (72GB Index fuer 470GB
>   Datenbank ist wenig, das wuerde ich bereits fur eine 47GB grosse
>   Datenbank erwarten), und auch jedes logische Register fuer sich nur
>   <2GB Umfang haben darf: Indexiert man fuer ein Uebernahmeregister
>   Koerperschaftsansetzungen und -verweise in voller Laenge (bei maximaler
>   Indexbreite von 250 Zeichen), dann bekommt man u.U. schon bei 8 bis 10
>   Millionen /Eintragungen/ Probleme, also einer deutlich geringeren Zahl
>   von Datensaetzen.

>   Ich denke, insgesamt effizientere Indexierung (und nicht nur Dateien
  >>2GB) wird irgendwann auch Thema fuer allegro werden und fuer den
>   dann zu erwartenden Kompatiblitaetsbruch kann man auch Optimierungen
>   in der allgemeinen Datenhaltung in Bezug auf hoeherbittige Plattformen,
>   evtl. sogar interne Speicherung in Unicode etc. vorsehen.

> viele Gruesse
> Thomas Berger