[OT] kleine RAM-Disk zur Auslagerung von TMP u. TEMP bei Win

[Leo Baumann]

Nach meinen Experimenten mit einem SSD RAM Cache wobei ich jetzt gierige
Schreib-/Lesezeiten fĂźr die SSD erreiche, habe ich noch was
Interessantes gefunden, wobei die TMP u. TEMP-Ordner aus den
Umgebungsvariablen von Windows in eine kleine RAM-Disk ausgelagert
werden anstatt auf der SSD gespeichert zu werden.

Das schont die SSD und ist bei den häufigen Operationen in TMP u.
TEMP-Ordnern etwa 20 x schneller als auf dem Drive.

FĂźr den SSD RAM Cache benutze ich 8 GiByte, was mit PrimoCache folgende
Performance bringt:

-----------------------------------------------------------------------
CrystalDiskMark 6.0.2 x64 (C) 2007-2018 hiyohiyo
Crystal Dew World : https://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

Sequential Read (Q= 32,T= 1) : 10577.668 MB/s
Sequential Write (Q= 32,T= 1) : 8891.945 MB/s
Random Read 4KiB (Q= 8,T= 8) : 1022.017 MB/s [ 249515.9 IOPS]
Random Write 4KiB (Q= 8,T= 8) : 685.205 MB/s [ 167286.4 IOPS]
Random Read 4KiB (Q= 32,T= 1) : 403.847 MB/s [ 98595.5 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 358.414 MB/s [ 87503.4 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 412.800 MB/s [ 100781.3 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 338.576 MB/s [ 82660.2 IOPS]

Test : 1024 MiB [C: 57.3% (74.4/129.7 GiB)] (x5) [Interval=5 sec]
Date : 2019/06/02 12:19:07
OS : Windows 10 Professional [10.0 Build 18362] (x64)

FĂźr die kleine RAM Disk fĂźr den TMP u. TEMP-Ordner habe ich 512 MiByte
eingerichtet.
https://www.com-magazin.de/praxis/windows-7/windows-ram-disk-beschleunigen-52883.html

Beide Aktionen zusammen machen mein Windoof 10 merklich schneller.

Das funktioniert allerdings nur sinnvoll, wenn man RAM-Kapitalist ist,
so wie ich mit 64 GiByte.

Gruß

 

[Martin Gerdes]

Leo Baumann <charly020664@yahoo.de> schrieb:

Das funktioniert allerdings nur sinnvoll, wenn man RAM-Kapitalist ist,
so wie ich mit 64 GiByte.

Mein erstes Mikroprozessorsystem hatte 1 kB RAM. Ich war recht stolz auf
die Speicherausstattung, das Vorbild hatte nämlich nur 256 Byte RAM.

 

[Rafael Deliano]

Mein erstes Mikroprozessorsystem hatte 1 kB RAM. Ich war recht stolz auf
die Speicherausstattung, das Vorbild hatte nämlich nur 256 Byte RAM.

Mein AIM65 hatte 1980 auch nur zwei 2114 bestückt. Gnädigerweise waren
aber leere Sockel für 4kByte 2114 verhanden. Für die ich mir sofort
die ICs beschaffte.
Der GP32 mit dem ich heute typisch arbeite hat nur 512 Byte SRAM. Die
oberen 256 Byte werden selten benutzt. FORTH hat Stacks und keine
Stackframes wie C. Ist also weniger auf RAM angewiesen.

MfG JRD

 

[Johannes Bauer]

On 08.06.19 14:06, Rafael Deliano wrote:

FORTH hat Stacks und keine
Stackframes wie C. Ist also weniger auf RAM angewiesen.

Wie kommst du denn darauf, dass eine nicht stackbasierte
Programmiersprache mehr RAM braucht als eine stackbasierte? Halte ich
ehrlichgesagt fĂźr Unfug, darum interessiert mich deine BegrĂźndung.

Gruß,
Johannes

 

[Manuel Reimer]

On 07.06.19 21:01, Leo Baumann wrote:

Das schont die SSD und ist bei den häufigen Operationen in TMP u.
TEMP-Ordnern etwa 20 x schneller als auf dem Drive.

Im Prinzip bastelst du nur fĂźr Windows nach was bei vielen
Linux-Anwendern lange Standard ist.

Ich kenne /tmp nur als Ramdisk. Kann aber auch eine Eigenart von Arch
Linux sein.

/tmp --> Ramdisk. Keine Garantie das der Inhalt einen Reboot Ăźberlebt
/var/tmp --> SSD. Überlebt einen Reboot.

Gruß

Manuel

 

[Hans-Peter Diettrich]

Am 08.06.2019 um 14:06 schrieb Rafael Deliano:

Mein erstes Mikroprozessorsystem hatte 1 kB RAM. Ich war recht stolz auf
die Speicherausstattung, das Vorbild hatte nämlich nur 256 Byte RAM.

Mein erstes RAM war PMOS (27V), mit 256*12 Bit in 4 Häppchen aus 3 1K*1
Chips zusammengebastelt. Dabei habe ich meinen ersten
Kleinleistungstransistor zerschossen, weil ich dem testhalber
versehentlich 10nF statt 270pF als Last zugemutet habe :-(

Mein "Aquarium" - 2000*56 Bit Kernspeicher im Stahlrahmen mit
Plexiglas-Scheiben - habe ich leider nie zum Laufen gebracht :-(

Mein AIM65 hatte 1980 auch nur zwei 2114 bestückt. Gnädigerweise waren
aber leere Sockel für 4kByte 2114 verhanden. Für die ich mir sofort
die ICs beschaffte.

Dafür habe ich einen Stack aus 2114 zusammengelötet, mit den CS zum
74138. In einem anderen Rechner als 16K RAM benutzt.

Meinem ST256 habe ich auch eine weitere RAM Bank huckepack aufgelötet,
doppelte Kapazität zum kleinen Preis

DoDi

 

[Rafael Deliano]

> Meinem ST256 habe ich auch eine weitere RAM Bank huckepack aufgelötet,

Für Breadboards mit bedrahteten Bauteilen manchmal
immer noch eine sinnvolle Technik:
http://www.embeddedFORTH.de/temp/DIL-Stack.pdf
Da Unterschied sich bei einem 74HC4051 Multiplexer nur
ein Pin in der Verdrahtung.

MfG JRD

 

[Rafael Deliano]

> Halte ich ehrlichgesagt fĂźr Unfug, darum interessiert mich deine BegrĂźndung.

Der Ton macht die Musik,
ich kann, muß aber nicht, mit jemand über irgendetwas diskutieren.

MfG JRD

 

[Michael Schwingen]

On 2019-06-09, Rafael Deliano <rafael_deliano@arcor.de> wrote:

FĂźr Breadboards mit bedrahteten Bauteilen manchmal
immer noch eine sinnvolle Technik:
http://www.embeddedFORTH.de/temp/DIL-Stack.pdf

Nicht nur dort.

Mein RIO Empeg (Auto-mp3-Player mit Festplatte) hat 2 TSOP-RAMs huckepack
auf den Original-RAMs. 1 Fädeldraht am hochgebogenen CS-Pin an die CPU,
ordentlich fixiert - hat jahrelang im Auto funktioniert (bis ich das Auto
gewechselt habe). Die originalen 16MB wurden mit größeren Festplatten und
ext3 doch etwas eng ...

Der neue Wagen spielt MP3 von USB-Sticks, aber die Fähigkeiten des Players
lassen im Vergleich zu der jetzt 18 Jahre alten Kiste doch zu wĂźnschen Ăźbrig
....

cu
Michael

 

[Johannes Bauer]

On 09.06.19 08:25, Rafael Deliano wrote:

Halte ich ehrlichgesagt fĂźr Unfug, darum interessiert mich deine
BegrĂźndung.

Der Ton macht die Musik,
ich kann, muß aber nicht, mit jemand über irgendetwas diskutieren.

Hast du glaube ich in den falschen Hals bekommen, war nicht unhĂśflich
gemeint.

Ich glaube es halt einfach nicht. Denn der Overhead durch einen
Stackframe (den man bei C ja auch Ăźberhaupt nicht braucht, z.B.
-fomit-frame-pointer) ist Ăźblicherweise vergleichsweise gering
verglichen mit Daten im RAM, vÜllig unabhängig ob die im Stack oder auf
dem Heap liegen. Und wenn man eine Unterfunktion aufruft, dann mĂźssen
irgendwo die volatilen Register gesichert werden.

Viele Grüße,
Johannes

 

[Sieghard Schicktanz]

Hallo Johannes,

Du schriebst am Sun, 9 Jun 2019 20:42:16 +0200:

Ich glaube es halt einfach nicht. Denn der Overhead durch einen
Stackframe (den man bei C ja auch Ăźberhaupt nicht braucht, z.B.
-fomit-frame-pointer) ist Ăźblicherweise vergleichsweise gering

Der Overhaed des Stack-_Frame_ ist was ganz anderes als der "nicht
gebrauchte" Frame-_Pointer_ - der ist nämlich nur ein Element da draus,
und der wird bei C wegen der nicht vorhandenen verschachtelten Funktionen
sowieso nicht gebraucht.
Der Stack-Frame enthält alles, was in einer (C-) Funktion als Daten lokal
definiert ist. Bei FORTH gibt es keinen Stack-_Frame_, da es auch im
Prinzip keine lokalen Daten gibt - alle Daten werden per Stack oder in
globalen Variablen "transportiert".

verglichen mit Daten im RAM, vÜllig unabhängig ob die im Stack oder auf
dem Heap liegen. Und wenn man eine Unterfunktion aufruft, dann mĂźssen

FORTH kennt auch (original) keinen Heap, sondern es benutzt einen zweiten
Stack fĂźr diverse Zwecke, und es hat Mechanismen, Daten zwischen den Stacks
auszutauschen.

> irgendwo die volatilen Register gesichert werden.

FORTH ist eine sog. "threaded language", ähnlich wie die Java-VM oder
andere Systeme, die einen Zwischencode benutzen, allerdings auf maximale
Effizienz ausgelegt. Das hat zur Folge, daß es _gar keine_ "volatilen
Register" gibt, die bei Aufrufen von "Unterfunktionen" gesichert werden
müßten. Lediglich für Interrupts müssen natürlich die Register der VM
gesichert werden, aber das gilt fĂźr jegliche Kontext-Umschaltungen
jeglicher Architekturen.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Johannes Bauer]

On 09.06.19 22:50, Sieghard Schicktanz wrote:

Der Overhaed des Stack-_Frame_ ist was ganz anderes als der "nicht
gebrauchte" Frame-_Pointer_ - der ist nämlich nur ein Element da draus,
und der wird bei C wegen der nicht vorhandenen verschachtelten Funktionen
sowieso nicht gebraucht.
Der Stack-Frame enthält alles, was in einer (C-) Funktion als Daten lokal
definiert ist. Bei FORTH gibt es keinen Stack-_Frame_, da es auch im
Prinzip keine lokalen Daten gibt - alle Daten werden per Stack oder in
globalen Variablen "transportiert".

Naja, der Stackframe enthält schon auch, je nach Architektur natßrlich,
Returnadresse und eben gesicherten Basepointer. Lokal allozierte Daten
zählen aber nicht als Vorteil fßr FORTH im Gegensatz zu C, weil vÜllig
unabhängig ob du die global definierst oder eben während der Laufzeit
einer Funktion auf dem Stack, den RAM brauchst du eben so oder so. Und
man kann natĂźrlich auch in C den Stack nicht benutzen, indem man eben
Modulglobal alloziert (je nach Wert landet das dann in .data oder .bss)
oder eben Funktionsstatisch. Aber was das bringen soll, sehe ich nicht
-- sondern sehe das eher als Nachteil, dass man immer den Worstcase
RAM-Verbrauch hat während man sonst eben nur die Teile vom Stack
verwendet, die man braucht.

verglichen mit Daten im RAM, vÜllig unabhängig ob die im Stack oder auf
dem Heap liegen. Und wenn man eine Unterfunktion aufruft, dann mĂźssen

FORTH kennt auch (original) keinen Heap, sondern es benutzt einen zweiten
Stack fĂźr diverse Zwecke, und es hat Mechanismen, Daten zwischen den Stacks
auszutauschen.

Aber egal wie wir die Segmente jetzt nennen: RAM ist ja RAM. Also die
Frage ist schon, warum spart man (und das war ja Rafaels ursprĂźngliche
Aussage) bei FORTH im Vergleich zu C RAM ein? Und gibts da Messungen
dazu? Ich finde das sehr uneinleuchtend.

irgendwo die volatilen Register gesichert werden.

FORTH ist eine sog. "threaded language", ähnlich wie die Java-VM oder
andere Systeme, die einen Zwischencode benutzen, allerdings auf maximale
Effizienz ausgelegt. Das hat zur Folge, daß es _gar keine_ "volatilen
Register" gibt, die bei Aufrufen von "Unterfunktionen" gesichert werden
müßten. Lediglich für Interrupts müssen natürlich die Register der VM
gesichert werden, aber das gilt fĂźr jegliche Kontext-Umschaltungen
jeglicher Architekturen.

Hm, naja aber irgendwann muss der RAM ja allokiert werden. Also
angenommen ich habe eine Schleife die hochzählt und jede Iteration ruft
sie ein Unterprogramm auf. Dann gibts da irgendwo den Wert, den Counter.
Und der muss gespeichert werden, irgendwo im RAM. Ob der jetzt (wenn ich
dich richtig verstanden habe) einmal fest platziert wird und dann nicht
beim Unteraufruf verschoben werden muss oder ob der jeweils gesichert
und wiederhergestellt wird, macht doch fĂźr den RAM-Verbraucht keinen
Unterschied, oder?

Gibt's da vielleicht ein einfaches Beispiel, dass verdeutlicht, wieso
man da weniger RAM verwenden muss?

Viele Grüße,
Johannes

 

[Sieghard Schicktanz]

Hallo Johannes,

Du schriebst am Mon, 10 Jun 2019 00:37:41 +0200:

Der Overhaed des Stack-_Frame_ ist was ganz anderes als der "nicht
gebrauchte" Frame-_Pointer_ - der ist nämlich nur ein Element da draus,
....
Naja, der Stackframe enthält schon auch, je nach Architektur natßrlich,
Returnadresse und eben gesicherten Basepointer. Lokal allozierte Daten

NatĂźrlich, die Return-Adresse ist ja sogar _der_ Beweggrund fĂźr den Stack
im allgemeinen und den Stackframe im besonderen.

zählen aber nicht als Vorteil fßr FORTH im Gegensatz zu C, weil vÜllig
unabhängig ob du die global definierst oder eben während der Laufzeit
einer Funktion auf dem Stack, den RAM brauchst du eben so oder so. Und

Nicht ganz - lokal in einer (C-) Funktion allozierte Daten brauchen
_immer_ Speicher, auch wenn sie nicht benutzt werden. Auf dem Stack
mĂźssen nur Daten Ăźbergeben werden, die auch verarbeitet werden. Das war
aber nicht mal unbedingt mein Argument - es ging mir nur um die
GegenĂźberstellung der Herangehensweisen.

man kann natĂźrlich auch in C den Stack nicht benutzen, indem man eben
Modulglobal alloziert (je nach Wert landet das dann in .data oder .bss)

Nein, Du kannst nicht den Stack nicht benutzen, solange Du auch nur eine
Funktion aufrufst. Interrupts und Multitasking gehen ohne Stack auch nicht.
Der Stack ist ein zentrales Strukturelement in praktisch jeder aktuellen
Programmiersprache oder sogar noch allgemeiner, Datenverarbeitungsumgebung.

oder eben Funktionsstatisch. Aber was das bringen soll, sehe ich nicht
-- sondern sehe das eher als Nachteil, dass man immer den Worstcase
RAM-Verbrauch hat während man sonst eben nur die Teile vom Stack
verwendet, die man braucht.

Statische Allokation ist eben zeitlich immer verbraucht, dynamische
(Stack, Heap) ändert sich ständig, möglichst bedarfsgemäß.
Manche Programmiersprachen legen halt einiges an Einträgen im Stackframe
an, das nicht immer gebraucht wird (Framepointer, Objectpointer ["self"],
Parameterlisten, evtl. noch anderes), andere versuchen halt, mit mĂśglichst
wenig "Overhead" auszukommen. Oder den, wie bei FORTH, mĂśglichst ganz zu
vermeiden, was aber auch "RĂźckwirkungen" auf die Programmierung hat.

....

FORTH kennt auch (original) keinen Heap, sondern es benutzt einen
....
Aber egal wie wir die Segmente jetzt nennen: RAM ist ja RAM. Also die
Frage ist schon, warum spart man (und das war ja Rafaels ursprĂźngliche
Aussage) bei FORTH im Vergleich zu C RAM ein? Und gibts da Messungen
dazu? Ich finde das sehr uneinleuchtend.

Es gibt da sicher Messungen, da kann Rafael sicher mehr dazu sagen.
Das Problem ist nur, dafĂźr eine ausreichende Menge wirklich relevanter
und vergleichbarer Parallelimplementierungen zu finden und die auch zu
vergleichen. Daran wird das wohl scheitern, den Aufwand dĂźrfte sich kaum
jemand leisten wollen. Aber interessant wäre das jedenfalls.

irgendwo die volatilen Register gesichert werden.

FORTH ist eine sog. "threaded language", ähnlich wie die Java-VM oder
andere Systeme, die einen Zwischencode benutzen, allerdings auf maximale
....
Hm, naja aber irgendwann muss der RAM ja allokiert werden. Also

Es gibt ja nicht "de[n] RAM" - da spielt auch noch ein wenig mehr an
Eigenschaften von Programm und Prgrammiersprache hinein.
Im einen Fall hast Du vielleicht einen Zähler mit 1 Byte, der Dir reicht,
im anderen Fall macht der Compiler / Linker einen Speicherbedarf von 4
Bytes draus, weil er keine Bytes "mag" oder auch nur weil er nur 4 Bytes
als kleinste Einheit kennt.

angenommen ich habe eine Schleife die hochzählt und jede Iteration ruft
sie ein Unterprogramm auf. Dann gibts da irgendwo den Wert, den Counter.
Und der muss gespeichert werden, irgendwo im RAM. Ob der jetzt (wenn ich
dich richtig verstanden habe) einmal fest platziert wird und dann nicht
beim Unteraufruf verschoben werden muss oder ob der jeweils gesichert

So eine Konstruktion wird _immer_ mit einem "fest plazierten" Zähler
arbeiten, egal ob der global, C-statisch oder am Stack liegt. Eine solche
Variable fĂźr Unterprogrammaufrufe zu verschieben macht AFAIK keine
Programmiersprache - das wäre wirklich vÜllig sinn- und zweckloser
Mehraufwand.
Was aber bei jedem Aufruf gemacht werden muß, ist die Paramterübergabe
vorher, deren Auswertung und das Anlegen lokaler Variabler während der
Verarbeitung und das Aufräumen am Schluß.
FORTH spart sich halt das Anlegen lokaler Variabler, indem die ebenfalls
wie fast alle anderen Daten bei Bedarf auf den Stack gelegt werden. Das hat
durchaus nicht nur lauter Vorteile.

Gibt's da vielleicht ein einfaches Beispiel, dass verdeutlicht, wieso
man da weniger RAM verwenden muss?

Hab' ich leider keins zur Hand und auch nicht so unbedingt die Zeit dazu.
Vielleicht hat Rafael da was passendes, ggfs. auch aus der Literatur?

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------