GEOS-InfoBase-Forum

Klingt interessant, probiere ich aus.

Ein paar Hintergrund-Infos: (Marcus möge mich korrigieren, wenn ich falsch liege)

Die Anzahl der Handles ist intern die Anzahl der Einträge der Handle-Tabelle. Jeder Eintrag ist 8 Byte groß (glaube ich, vielleicht sind es auch 16 Byte). Das bedeutet bei 4096 Handles a 8 Byte einen exakt 32 kByte großen Speicherblock. Der wird vom System in den Hauptspeicher geladen, wenn es auf die Handles zugreifen muss. 32 k sind schon ganz schön viel, das SDK sagt: mach deine Blöcke nicht größer als 8 k. Prinzipiell gehen auch größere Blöcke (ich nutze bei JPEG z.T. 48 k), aber die Chance, das ein großer Block nicht mehr in den freien Speicher passt ist natürlich höher.
Falls ein Handle-Eintrag 16 Byte schluckt ist der Block 64 k groß - dann ist eh Sense.

Die magische Grenze liegt also bei 4096 (oder 4095, wenn man die Null mitzählt). Bei 4095 startet GEOS bei mir noch, bei 4096 nicht mehr. Spannend ist, dass GEOS meine 4095 wieder auf 3500 korrigiert, wenn es runterfährt. - Außer Spesen nichts gewesen.

Ich erinnere mich, das wir mit Marcus damals über das Thema gesprochen haben und es nicht so simpel ist, die Tabelle zu vergrößern oder zu teilen.

Hypothese: Wenn ein Handle-Eintrag 8 Byte groß ist könnte hier der gleiche "Bug" zuschlagen, der beim GEOS 2.x damals verhindert hat, dass es installiert wird, wenn mehr als 32MB Platz auf der Platte waren. Der Grund ist, dass der Datentyp "integer" (ganzzahling) in C von -32000 bis + 32000 geht. Zahlen größer als 32767 werden als negativ interpretiert (ja, das ist logisch und auch sinnvoll :-). Wenn dem so ist zeigen Handle-Nummern größer 4095 irgendwo ins Nirvana.

Gruß
Rainer

Zitat von »Achim«

Zitat von »Mütze«

Klingt interessant, probiere ich aus.

Hi Bernd.
Schon irgendwelche Erkenntnisse?

Ja.

- Habe statt der standardmässigen 3500 Handles kurz nach deinem Posting 4000 Handles per Hand in die GEOS.INI eingetragen. Der Wert bleibt seitdem beim Runterfahren erhalten, scheint also dauerhaft nutzbar zu sein.

- Mit Perf werden mir immerhin ca. 200 zusätzliche Handles angezeigt.

- Einen Geschwindigkeitszuwachs habe ich leider nicht bemerkt.

Bernd

Handles ebenfalls auf 4000 gesetzt. Geos.ini Viewer: 4000, Process Viewer: 3741, HandleMeter: 3741, GEOS-Modul in den Voreinstellungen: 3500. Prinzipiell bleiben mir die 4000 Handles beim Neustart erhalten; sobald ich aber deren Wert in den Voreinstellungen manuell zu erhöhen versuche und abspeichere, wird GEOS im laufenden Betrieb wieder auf 3500 gesetzt.
Nachtrag: Speed von 1600 auf 1800 gesteigert (1024x768, 64K).

Zitat von »Achim«

Wo hast du denn den geos.ini-Viewer her?

Habe nachgeschaut: Freeware von Walter Loos. Weiß nicht mehr, wo ich den damals gefunden habe. Hänge ich an.

Zitat von »Achim«

Ergo: Nach manueller Änderung der Handles in der geos.ini diese in den Voreinstellungen niemals mehr korrigieren.

Habe ich auch gemacht, wobei ich einkalkuliere, daß GEOS sich jetzt richtig aufhängen kann - also nicht mal ein KR-09, worauf ich eigentlich einen Anspruch habe.

Hallo zusammen

Wer Mut hat, kann sich den Wert 3741 "ein-patchen":

Ordner c:\ensemble\system\pref
Datei prefos.geo

In einem Hex-Editor den Hex-Wert "0D AC" durch "9D 0E" ersetzen (kommt nur einmal vor). Nun kann man im GEOS Voreinstellungs-Modul den Maximalen Wert von 3741 auswählen und auch speichern.

Zur Info:
Dez "3500" = Hex Big Endian "0D AC" = Hex Little Endian "AC 0D"
Dez "3741" = Hex Big Endian "0E 9D" = Hex Little Endian "9D 0E"

Ein kurzer Test hat soweit bei mir funktioniert. Einzige Unschönheit ist, dass bei jedem Öffnen des Voreinstellungs-Modul der Wert "3700" angezeigt wird... Die Auswahl wird anscheinend auf 100 Handles genau gemacht. Bei 3740 wird dann 3700 gespeichert. 3741 aber als 3741.

Ich selber konnte aber keinen definitiven Speed-Zuwachs erkennen. Liegt wahrscheinlich daran, dass ich auf einem Notebook arbeite. Da gibt es durch die Stromspartechniken oft grosse Unterschiede (10 - 20%) bei Speed, trotz Netzbetrieb.

Gruss
Andreas

Funzt; allerdings ist der Geschwindigkeitszuwachs nunmehr ebenfalls eingeschränkt. Ich belasse es bei dem Patch, werde aber manuell 4000 Handles einstellen. Erstaunlich, was die paar Einträge mehr ausmachen.

Ist es wirklich mit der manuellen Einstellung auf 4000 schneller als mit 3741 ?

Jedes Tool meldet doch 3741, auch wenn man hoehere Werte verwendet. Waere wirklich interessant, ob da alle Tools einfach einen fixen Oberwert vom System bekommen, obwohl mehr Handles vorhanden sind...

Ansonsten einfach mal den Patch auf den Hex LE Wert von 4000 setzen :-)

Zitat von »bolle732«

Ansonsten einfach mal den Patch auf den Hex LE Wert von 4000 setzen :-)

Dieser Wert ist bereits eingetragen. Wenn ich das richtig verstehe, lautet der Dezimalwert "4000" in Little Endian "34 30 30 30" - und das steht jetzt in meiner INI. Der "geos.ini Viewer" sagt ebenfalls "4000", die Voreinstellungen nach Deinem Patch hingegen "3741".
Und ja: GEOS läuft meßbar schneller (Speed bei 3500 = 1600, bei 3700(-41) = 1600/1700, bei 4000 = 1800).
Habe jetzt "4095" eingetragen. Kein Geschwindigkeitszuwachs. Hoffe auf schönere Abstürze.

Der Dezimalwert 4000 ist in Hexadezimal "FA0". Big Endian "0F A0", Little Endian "A0 0F".

Little Endian "34 30 30 30" wäre nach meiner Rechnung Dezimal 808464436...

Die Umrechnung ist relativ einfach. Dezimalwert in Hexadezimal umrechnen und mit Nullen auf ganzzahlige Anzahl Stellen auffüllen. Das ergibt Big Endian. Danach immer 2 Stellen von rechts nach links nehmen und neu schreiben. Dann hat man Little Endian. Hört sich schwieriger an als es ist.

Noch ein Beispiel:
Dezimal "123456" ist Hexadezimal "1E240". Wir haben 5 Stellen (ungerade), also setzen wir noch eine Null vorne ran was Hexadezimal in Big Endian "01E240" ergibt. Nun immer 2 Stellen zusammen (was ja jeweils ein Byte ist) von rechts nach links neu schreiben und wir erhalten Hexadezimal in Little Endian "40E201".

Intel verwendet in den CPUs immer Little Endian. Andere Prozessoren oder zum Beispiel in Netzwerkpaketen verwenden Big Endian.

Bei all dem bleibt die Frage unbeantwortet, wieviele Handles von den 4096 das System den einzelnen Anwendungen (oder deren Gesamtheit) zur Verfügung stellt.

Was mich völlig verwundert, warum die Anzahl der Handles überhaupt einen Einfluss auf die Geschwindigkeit haben können. So lange man noch nicht am Limit ist, also noch über tausend Handles unbenutzt sind macht es überhaupt keinen Sinn, dass das 500 oder 600 Handles mehr überhaupt irgend etwas ausmachen.

Sehr grüblerisch
Rainer

Das "System" selbst braucht auch Handles. Jede geladene Geode und Library (Kernel, Druckertreiber, Videotreiber ...) braucht Handles. Eines für die Datei selbst und für jede Code- oder UI-Resource auch mindestens eins. Da kommt ne ganze Menge zusammen.
Rainer

Zitat von »Rainer«

Was mich völlig verwundert, warum die Anzahl der Handles überhaupt einen Einfluss auf die Geschwindigkeit haben können. So lange man noch nicht am Limit ist, also noch über tausend Handles unbenutzt sind macht es überhaupt keinen Sinn, dass das 500 oder 600 Handles mehr überhaupt irgend etwas ausmachen.

Sehr grüblerisch
Rainer

Bevor das hier so stehen bleibt, habe ich den Speed bei 3500, 3700 und 3741 (4095) gemessen. Zuvor habe ich jeweils alles im Host abgeschaltet, was irgendwie stressen könnte (Netz und dergleichen). Ergebnis: tatsächlich war das System unter allen Voraussetzungen gleich schnell. Keinerlei Gewinn. Aber vielleicht knackigere Abstürze, weil die von Rainer erwähnten Systemreserven jetzt nur noch 354 Handles ausmachen?