hallo,
frage:
sind linux editoren leistungsfähiger als windows-editoren?
wenn man z.bsp ein 1 gb grosses file bearbeiten will, kann man das ja auch
auf der kommandozeile machen in linux > vim, pico
oder grafisch mit gvim
windows hab ich jetzt keine ahnung
hat wer erfahrungswerte, ob unter linux die editoren sich mit "grossen" files leichter tun?
gruss günter
Andreas42 
ghartl1 „editoren“
Hi!
hat wer erfahrungswerte, ob unter linux die editoren sich mit "grossen" files leichter tun?
Ehrlich gesagt, hab ich keine Idee, wie man das halbwegs objektiv "messen" soll.
Meiner Meinung nach kommt jeder vernünftige Editor mit großen Dateien klar. Das man dies Windows abspricht, liegt an dem "unvernünftigen" Zeugs, das MS Windows beigepackt hat (Notepad&Co).
In meinem beruflichen Umfeld müssen wir auf Editoren zur Quelltextbearbeitung zurückgreifen, die unter Windows laufen, wenn das ERP-System nicht unter Unix oder Linux läuft (da setzt man üblicherweise VI ein; bei den zunehmenden Installationen auf Windows-Servern hat man diesen "Luxus" nicht).
Da ergibt sich quasi zwangsweise das jeder so seinen Lieblingseditor unter Windows hat und das ist dann natürlich ein "vernünftiger" Editor.
Im Umfeld das ich überblicke sind da Ultraedit, Textpad, Notepad+ und einige andere verbreitet. Bei denen setze ich ganz platt voraus, dass sie mit großen Dateien keine Schwierigkeiten haben.
Ultraedit ist mein Haupteditor (an dessen Grenze bin ich noch nicht gestoßen) und Textpad kann das ebenfalls (da hab ich die Testversion genutzt). Als ich Fernwartung gemacht habe, war das größte Drama, wenn auf der Kiste nur Notepad oder Wordpad verfügbar war.
Für Fälle, wo ich schnell mal einen Editor herunterladen muss, nutze ich da dann den kostenlosen WinVI (www.winvi.de).
Unter Linux setze ich auch einfach voraus, dass die in der GUI nutzbaren Standardeditoren der Distribution keine Probleme mit großen Dateien haben, notfalls nutzte ich halt VI im Terminal. Wobei ich zugeben muss, dass ich VI auch nur rudimentär bedienen kann. Ich bin halt doch inzwischen Mausschubser und hab VI nie richtig "gelernt" (ich hatte nie den Zwang nur mit ihm arbeiten zu können).
OK, was soll ich also auf die ursprüngliche Frage antworten?
Tun sich Linux-Editoren mit großen Dateien leichter als Windows-Editoren? Aus meiner Sicht ist das hauptsächlich eine Sache der Programmierung der Editoren, nicht des Betriebssystems.
Ich beantworte die Frage daher mit Nein.
Allerdings hat MS den Ruf von Windows-Editoren mit Notepad&Co ganz generell für alle Zeiten tiefgreifend versaut, was ich gerade wieder durch deine Frage als bestätigt ansehe. 
Bis dann
Andreas
Borlander Andreas42 „Hi! Ehrlich gesagt, hab ich keine Idee, wie man das halbwegs...“
Tun sich Linux-Editoren mit großen Dateien leichter als Windows-Editoren? Aus meiner Sicht ist das hauptsächlich eine Sache der Programmierung der Editoren, nicht des Betriebssystems.
So schaut es aus :-)
Unter Linux setze ich auch einfach voraus, dass die in der GUI nutzbaren Standardeditoren der Distribution keine Probleme mit großen Dateien haben
Leider nicht. Da ich häufiger Textdateien im Bereich von mehreren Hundert MB bearbeite musste ich leidlich feststellen, dass dies nicht automatisch der Fall ist. Sowohl gedit (Gnome) als auch mousepad (XFCE) tun sich schwer mit so großen Dateien: gedit zeigt zwar netterweise einen Fortschrittsbalken beim Laden der Datei an, braucht aber eine Ewigkeit um eine gerade mal "nur" 330MB große Datei zu laden: ziemlich genau eine Minute - und das auf relativ aktueller Hardware und selbst wenn die Datei sich schon im Datenträgercache befindet :-( Bei mousepad geht es schneller, aber ohne eine Rückmeldung während des Ladens.
Mit dem von mir für viele einfache Dinge bevorzugten geany (übrigens auch für Windows verfügbar) geht es deutlich schneller. Gerade mal 3s. Hab es zum Vergleich auch noch mal mit einer 400MB Datei probiert die nicht im Cache liegt: Da waren es 5s. Dafür greift sich geany allerdings auch gleich mal eben die doppelte Dateigröße an Arbeitsspeicher (tatsächliche Belegung!), gedit und mousepad belegen nur die Dateigröße an RAM. vim ist schnell und genügsam, belegt aber trotzdem RAM entsprechend der Dateigröße...
Gruß
Bor
Andreas42 Borlander „So schaut es aus :-) Leider nicht. Da ich häufiger...“
Hi!
Danke, das ist gut zu wissen. Ich bin wirklich davon ausgegangen, dass die grafischen Editoren, da nicht schwächeln.
Wenn ich es genauer überlege, habe ich mit Dateien im 100MByte (und mehr) Bereich nur beruflich zu tun (Logfiles oder mal eben "schnell") erstellte Trace-Protokolle. da nutze ich dann (falls Unix/Linux) VI oder View. Bei den Windows-Systemen muss ich das i.d.R. mit Ultraedit oder WinVI untersuchen. Und die sind zum Glück schnell genug im Umgang mit großen Dateien.
Bis dann
Andreas
ghartl1 Andreas42 „Hi! Danke, das ist gut zu wissen. Ich bin wirklich davon...“
@borlander
meintest du den vim auf der kommandozeile?
der ist schnell..klar
und der gvim auf der gui?
Borlander ghartl1 „@borlander meintest du den vim auf der kommandozeile? der ist...“
meintest du den vim auf der kommandozeile? [...] und der gvim auf der gui?
Den teste ich gerade auch mal. Hab mir gerade mal gvim bzw. um genauer zu sein vim-gnome nachinstalliert: Startet genau so schnell wie das "original" vim :-)
Gruß
Borlander
Borlander Andreas42 „Hi! Danke, das ist gut zu wissen. Ich bin wirklich davon...“
Richtig langsam wird es wenn Du dann noch Syntax-Highlighting an hast. Dann kann man bei vielen Editoren zusehen wie der Text aufgebaut wird :-|
torsten40 Andreas42 „Hi! Ehrlich gesagt, hab ich keine Idee, wie man das halbwegs...“
UltraEdit ist wirklich ein toller Editor, grade für grosse Textdateien. Dabei ist ansich völlig egal, das Ding öffnet alles. Auch die FTP Zugänge für Webserver, um Configs zu bearbeiten, einfach genial das Teil :)
Da es UE unter Windows und Linux gibt, denke ich nicht, dass es da zu grossen Unterschieden kommt.
fishrman ghartl1 „editoren“
Ich arbeite nicht mit Programmcodes oder Datenbanken, sondern großen Textdateien.
Ewig habe ich gesucht und probiert. Ob nun Textverarbeitung oder Editoren, immer hat was gehakt.
Nun habe ich VIM gelernt (mit vimtutor viel einfacher als man denken möchte) und will nichts anderes mehr haben. Egal wie groß die Dateien sind und wie alt der Computer ist, VIM ist wirklich sehr komfortabel und raketenschnell.
ghartl1 fishrman „Ich arbeite nicht mit Programmcodes oder Datenbanken, sondern...“
die erfahrung hab ich auch gemacht..ist halt anfangs "gewöhnungsbedürftig " :-))
ghartl1 Nachtrag zu: „die erfahrung hab ich auch gemacht..ist halt anfangs...“
die frage, die sich aufdrängt...
wie verwaltet vim die dateien?
wenn ich eine 10 gb grosse datei habe und nur 4 gb ram?
lädt der nur einen abschnitt in den ram?
tun das die anderen auch?
oder anders gefragt, wieso ist vim gegenüber den anderen so schnell?
weil er auf der kommandozeile arbeitet?
Andreas42 ghartl1 „die frage, die sich aufdrängt... wie verwaltet vim die...“
Hi!
Naja, es gibt durchaus nicht wenige Tipps um die Arbeitsgeschwindigkeit vom VIM mit sehr großen Dateien zu erhöhen. Offenbar findet ih nicht jeder in jeder Situation schnell.
http://www.vim.org/scripts/script.php?script_id=1506
http://vim.wikia.com/wiki/Faster_loading_of_large_files
Hmm, hier geht es direkt um deine Frage:
http://vim.1045645.n5.nabble.com/Can-vim-view-VERY-large-files-w-o-having-to-load-entire-file-into-memory-td1186583.html
beantwortet wird sie aber nicht...
Um jetzt genaues sagen zu können, müsste man in die Quelltexte schauen (und diese auch noch verstehen können). Klar ist allerdings, dass er mit dateien klarkommt, die größer als der vorhandene Arbeitsspeicher sind. (Für mich ist das eine der Eigenschaften, die ich bei einem "vernünftigen" Editor voraussetze.)
VIM basiert auf VI und der stammt noch aus der Zeit, als 4Gbyte eine unvorstellbare RAM-Größe waren. Damals gab es aber natürlich schon Dateien die Größer waren. Ergo musste VI schon i Kern damit klarkommen.
Ich schätze das der Trick ist, die große Datei stückchenweise zu laden. Viel mehr bleibt ja auch nicht übrig.
Ich denke, dass alle Betriebssysteme beim Lesen einer Datei, die freie Positionierung des Filepointers erlauben, d.h. ich kann dem Betriebssystem sagen: gehe an Position X und lade von dort nn Bytes aus der Datei. So kann man z.B. schnell vom Anfang einer Datei zum Ende "springen", da dabei nicht die ganze Datei geladen werden muss.
Bei Änderungen dürfte man die Sachen beschleunigen, indem man den eingelesenen und geänderten Teil im Speicher nicht sofort in die eigentliche Datei zurückschreibt, sondern in temporären Dateien speichert. Man muss sich dann nur merken, dass dieser Teil in der temp. datei T1 steht und nicht in der Hauptdatei, wenn man diesen Teil wieder Laden will.
Erst beim eigentlichen Speichern der Änderungen baut man die neue Datei aus den unveränderten Teilen der alten Datei und den temp. Dateien neu zusammen. Das kann dann zwar dauern, aber darauf ist der User ja dann gefasst.
Bis dann
Andreas
Borlander Andreas42 „Hi! Naja, es gibt durchaus nicht wenige Tipps um die...“
So kann man z.B. schnell vom Anfang einer Datei zum Ende "springen", da dabei nicht die ganze Datei geladen werden muss.
Kommt drauf an was man als zum Ende springen interpretiert. Das ggf. vorhandene unsichtbare EOF-Zeichen ist ja für den User nicht so interessant an zu schauen. Bei den meisten GUI-Editoren bedeutet das i.d.R. ein Anzeigen der letzten n Zeilen der Datei, wobei n gleich die Zeilenanzahl des Anzeigebereichs ist. Bei naiver Herangehensweise würde man hier nun vom Dateiende aus rückwärts nach den Zeilenumbrüchen suchen. Da es allerdings extrem teuer wäre Byte-Weise die Datei von Hinten zu lesen muss man da deutlich mehr Implementierungsaufwand investieren. Ich da dann eher Blockweise von Hinten anfangen, wobei die Blöcke im Idealfall so groß sein sollten dass eine komplette Bildschirmseite reinpasst: Damit wäre dann nur noch ein Plattenzurgiff notwendig. Bei beliebig langen Textzeilen lässt sich das natürlich nicht garantieren. Also wird das ganze schon irgendwie fummelig ;-)
Gruß
bor
Borlander ghartl1 „die frage, die sich aufdrängt... wie verwaltet vim die...“
wenn ich eine 10 gb grosse datei habe und nur 4 gb ram? lädt der nur einen abschnitt in den ram? tun das die anderen auch?
Editoren die für die Arbeit mit sehr großen Dateien ausgelegt sind machen das auf jeden Fall so, dass u.U. nur Teile der Datei im Arbeitsspeicher vorgehalten werden. Generell schneller wird der Editor dadurch aber nicht. Das Anzeigen der ersten Bildschirmseite kann natürlich schneller erfolgen. Informationen wie die Anzahl von Zeilen, oder die Anzahl von Zeichen stehen allerdings erst zur Verfügung wenn die komplette Datei einmal durchlaufen wurde. Scrollen durch die Datei wird tendenziell auch langsamer als wenn die Datei komplett im Speicher liegt...
fishrman ghartl1 „die frage, die sich aufdrängt... wie verwaltet vim die...“
Ich hab jetzt mal spaßeshalber eine 200MB große Lorem Ipsum Datei erstellt. Ich habe 500 MB RAM.
Der Editor Geany (den ich auch sehr gerne nutze) geht dabei doch sehr in die Knie. VIM macht 1.048.000 Änderungen in Hastenichgesehen Sekunden. Ich denke die GUI macht schon ne Menge aus.
Borlander fishrman „Ich hab jetzt mal spaßeshalber eine 200MB große Lorem Ipsum...“
eine 200MB große Lorem Ipsum Datei erstellt. Ich habe 500 MB RAM. Der Editor Geany (den ich auch sehr gerne nutze) geht dabei doch sehr in die Knie.
Kein Wunder: Wenn Du nur 500MB RAM hast und geany dann 400MB (doppelte Dateigröße, siehe oben) davon haben will dann wird es fast zwangsläufig lahm ;-)
fishrman Borlander „Kein Wunder: Wenn Du nur 500MB RAM hast und geany dann 400MB...“
Na dann hol ich mir nen Rechner mit 32 GB RAM und in Zukunft ist es mir egal mit welchem Editor ich arbeite.
Xdata fishrman „Na dann hol ich mir nen Rechner mit 32 GB RAM und in Zukunft...“
Sollte ein "guter Editor" sowas nicht von der Festplatte erledigen lassen und nicht vom RAM?
Zumal ja eine, große und wichtige, Textdatei im flüchtigen RAM nicht sicher aufgehoben ist, gerade bei der Bearbeitung..
Ein Geschwindigkeitsprobelm muß es bei einer einfachen Textdatei, auch wenn die groß ist nicht geben..
Ein effizienter Editor sollte so einen Algorithmus doch haben, der die Datei auf der Festplatte bearbeitet und weitgehend nur selber im RAM agiert..?
Ist ja keine fette Textverarbeitung mit allen möglichen Funktionen und Formatierungen, die
-- der normale User sowieso nur zu 1% nutzt.
Ein Glück aus dem Editor mit den gerade dieser Text geschrieben wird sind die
sinnfreien*
Textverarbeitungsfunktionen raus und
-- es ist ein echter und guter Editor geworden :-)
*Die elementare Funktion eines Editors,
auch kurze Zeilen
untereinander zu schreiben - ist wieder da :)
Borlander Xdata „Sollte ein "guter editor" sowas nicht von der Festplatte...“
Zumal ja eine, große und wichtige, Textdatei im flüchtigen RAM nicht sicher aufgehoben ist, gerade bei der Bearbeitung..
Du kannst die Datei doch einfach speichern? ;-)
Ein effizienter Editor sollte so einen Algorithmus doch haben, der die Datei auf der Festplatte bearbeitet und weitgehend nur selber im RAM agiert..?
Häh? Ein direktes sofortiges Schreiben der Änderungen würde sehr deutlich vom üblichen Bedienkonzept eines Editors abweichen, d.h. sich anderes verhalten als der Benutzer es erwartet. Der beste Algorithmus wird aber auch nichts helfen wenn Du am Anfang der Datei ein Zeichen einfügst oder löscht...
Xdata Borlander „Du kannst die Datei doch einfach speichern? ;-) Häh? Ein...“
Danke für deine Antwort.
Hab keine direkte Bearbeitung gemeint, sondern - der Editor soll die große Datei nicht in den knappen RAM laden, wenn dies möglich ist.
Es ging um den geringen RAM Verbrauch des Editors, insbesondere bei großen Dateien.
Bin etwas ins Schleudern gekommen weil der geringe RAM des Rechners eine Rolle Spielen soll.
Die Lanze gegen Textverarbeitungen kam, weil ich mit Word mal Schwierigkeiten hatte ein
Bewerbungsschreiben zu bearbeiten.
Es war nicht möglich die Anschrift der Firma zu ändern ..
Dieses Sch... Word hat immer eine Leerzeile "produziert". *
Hab es dann mit einem Editor Erledigt
und die bewundert die mit einem modernen Word arbeiten können.
* Genau wie am Anfang der neue Editor hier im Forum.
Mir liegen einfache Editoren ohne viele Automatismen oder Formatierungen.
Die Features der neuen Office Systeme sind etwas für Profis und Schreib-Büros ;-)
Hab sogar schon Klagen von Studenten gehört wenn wieder einer mal etwas im neuesten Powepointx oder docx
Gespeichert hat und die Libreoffice User -- und umgekehrt Verluste haben oder manches ganz weg ist.
PS:
Allgemein sind Editoren für Programmierer interessant, falls diese c Pascal oder gar Ada konditioniert sind.
Für Buchautoren soll wohl das komplizierte? LateX das Beste sein.
Sorry, meine Antwort hat etwas gedauert - hab gerade das neue Ubuntu 12.10 auf einem ollen Rechner im Test.
Borlander Xdata „Danke für deine Antwort. Hab keine direkte Bearbeitung...“
der Editor soll die große Datei nicht in den knappen RAM laden, wenn dies möglich ist.
Sowas macht die Implementierung auf jeden Fall deutlich komplexer: Siehe dazu auch meine obige Diskussion mit Andreas.
Man könnte natürlich die Datei beim Öffnen einmal durchlaufen, sich die Position der Zeilenanfänge merken um sich im Folgenden bei der Anzeige primär auf den Datenträgercache zu verlassen (der natürlich deutlich langsamer ist als direkt zugewiesener Arbeitsspeicher). Wobei man sich dann allerdings trotzdem die Änderungen an der Datei im Arbeitsspeicher verwalten müsste (was nun wiederum deutlich komplizierter ist). Zusammenfassend kann man sagen: Um weniger Arbeitsspeicher als die zu bearbeitenden Daten groß sind zu belegen muss man als Entwickler mit einer deutlich komplexeren Implementation leben und als Nutzer mit einer geringeren Geschwindigkeit (wenn auch nicht zwingend spürbar).
Dieses Sch... Word hat immer eine Leerzeile "produziert". [...] Genau wie am Anfang der neue Editor hier im Forum.
D.h.: Der Absatzabstand war ungleich 0 oder der Zeilenabstand ungleich 1.
bewundert die mit einem modernen Word arbeiten können.
Ich mache sowohl das eine als auch das andere. Je nach Anwendungszweck ;-)
Hab sogar schon Klagen von Studenten gehört wenn wieder einer mal etwas im neuesten Powepointx oder docx Gespeichert hat und die Libreoffice User -- und umgekehrt Verluste haben oder manches ganz weg ist.
Sowas sollte man auch vermeiden...
Für Buchautoren soll wohl das komplizierte? LateX das Beste sein.
LaTeX ist definitiv eine schöne Lösung für sehr umfangreiche Dokumente. Vor allem auch durch die saubere Trennung von Inhalt und Layout :-)
Mir liegen einfache Editoren
Also auf Features wie Syntax-Highlighting würde ich auf keinen Fall verzichten wollen. Für riesige Dokumente ist Syntax-Highlighting aber leider regelmäßig eine extreme Bremsen. Bei denen kann man aber meist drauf verzichten.
Gruß
Borlander
neanderix Xdata „Danke für deine Antwort. Hab keine direkte Bearbeitung...“
>Allgemein sind Editoren für Programmierer interessant, falls diese c Pascal oder gar Ada konditioniert sind.
Nicht nur für die. Ganz generell nutze ich für jegliche Form von Quellcode keinen Texter, also nicht OO.writer oder MSO word, sondern einen Editor.
Wenn es ganz komfortabel sein soll, befindet sich dieser Editor in einer IDE ;)
>Für Buchautoren soll wohl das komplizierte? LateX das Beste sein.
Ich empfinde das gar nicht als kompliziert, nur als gewöhnungsbedürftig. Und nein, ich habe nicht viel Erfahrung, ich habe vor gut 4 monaten mal erste "Gehversuche" gemacht, leider seitdem keine zeit mehr gehabt (beruflich bedingt).
Bin sogar drauf und dran, ein anstehendes berufliches Projekt mit LaTeX statt Word abzuwickeln... ein Handbuch mit Inhaltsverzeichnis und reichlich Screenshots, das ganze auch noch ISO 9xxx gerecht.
Volker
Borlander fishrman „Na dann hol ich mir nen Rechner mit 32 GB RAM und in Zukunft...“
dann hol ich mir nen Rechner mit 32 GB RAM und in Zukunft ist es mir egal mit welchem Editor ich arbeite.
Nicht wenn Du Textdateien bearbeiten willst die Größer als 32GB sind...
Dank bezahlbarer 8GB DDR3 Module sind 32GB RAM inzwischen aber durchaus eine Überlegung wert. Aktuell habe ich "nur" 16GB :-o
Xdata Borlander „Nicht wenn Du Textdateien bearbeiten willst die Größer als...“
Erst jetzt gesehen
16 GB RAM :-)
Wird man zwar nicht immer brauchen
-- aber es beruhigt ungemein.
Gehöre zu denen die immer mit RAM geknausert haben.
Aber wenn man einmal ein System erlebt hat, was etwas mehr RAM hat ....... :)
Bringt mehr als 4 Kerne oder CPUs mit hohem Takt. Übrigens ..
Die neuen ivy Chips sind, gefühlt, ein Quantensprung.
Auch mit nur Celeron, da macht Computern wieder Spaß.
Eine große zu editierende Datei verliert da ihren Schrecken.
Borlander Xdata „Erst jetzt gesehen 16 GB RAM :-) Wird man zwar nicht immer...“
Wird man zwar nicht immer brauchen -- aber es beruhigt ungemein.
So schaut es aus. Wobei man den Speicher auch durchaus sinnvoll nutzen kann, wenn man z.B. große Datenbestände zum arbeiten in eine RAM-Disk lädt. Das ist dank der Nutzung als Datenträgercache allerdings auch nur in Extremfällen nötig. Hab es gerade mal ausprobiert: Beim ersten Lesen einer 1,4GB Datei von Platte bekomme ich 96MB/s. Beim zweiten Versuch 1,4GB/s und ab dem dritten dann 1,5GB/s. Bei längerer Systemnutzung habe ich häufig 70% des RAMs als Datenträgercache genutzt. Das sorgt dann schon für ein schnelles System. Einziger "Nachteil": Die Nutzung einer SSD für das System macht dann keinen so dramatisch spürbaren Unterschied mehr aus ;-)
Auch 16GB sind allerdings nicht unfüllbar :-|
Bringt mehr als 4 Kerne oder CPUs mit hohem Takt.
Kommt auf den Anwendungsfall an.
Eine große zu editierende Datei verliert da ihren Schrecken.
Jein. Mit dem "falschen" Editor muss man auch mit dieser RAM-Ausstattung lange warten. Selbst bei Dateien aus dem Cache :-(
Grundsätzlich kann ich viel RAM allerdings nur empfehlen. Zumindest so lange es günstig verfügbar ist. Für meine 4x4GB hatte im letzten Jahr gerade mal 65 Euro (bzw. ~72 incl. Versand) bezahlt. Das machte die Entscheidung einfach. 8GB Module waren damals noch richtig teuer, warum ich dann auch auf einen Vollausbau verzichtet habe. Inzwischen haben die sich fast den 4GB Modulen angenähert. Ob es sich allerdings lohnt noch mal 80-90 Euro drauf zu legen um 32GB statt 16GB RAM zu bekommen sei dahingestellt...
Gruß
Borlander
Xdata Borlander „So schaut es aus. Wobei man den Speicher auch durchaus...“
Danke für die Info.
Vermutet hatte ich schon, so "richtige" Editoren besser sind als vorhandene Standard Teile. Erstaunlich wie interessant ein vermeintlich einfaches Thema wie Editoren ist.
Viel RAM scheint auch bei neuen Motherboards sinnvoll zu sein. Bei AsRock heißt es XfastRAM, andere Hersteller haben wahrscheinlich auch ähnliches. Soll sogar möglich sein über 4GB RAM bei "32Bit" sinnvoll nutzen zu können.
Eine Entlastung der, durch die minimale "OnBoard" Elektronik, unausgereiften SSD(s) ist besonders sinnvoll!
Borlander Xdata „Danke für die Info. Vermutet hatte ich schon, so "richtige"...“
AsRock [...] XfastRAM
Noch nie von gehört. Was soll das bewirken?
Soll sogar möglich sein über 4GB RAM bei "32Bit" sinnvoll nutzen zu können.
Mit PAE ist das möglich, nur nicht bei Desktop Windows. Hatte meine Workstation vor dem Einbau der SSD (auf die kam dann erstmalig ein 64Bit OS) auch noch eine ganze Weile mit PAE-Kernel laufen. War kein Problem. Auch beim Notebook mit 8GB RAM habe ich keinerlei Leidensdruck zum Umstieg auf 64Bit ;-)
Xdata Borlander „Noch nie von gehört. Was soll das bewirken? Mit PAE ist das...“
Wie genau das geht ist mir auch nicht ganz klar, es soll wohl eine Hardwaremöglichkeit sein RAM effizient zu nutzen der ansonsten noch nicht genutzt wird.
Geht aber wohl nur mit den neuen ivy Chips und auch schon mit der Sandy Bridge.
Eine Art effiziente und inteligente Nutzung von RAM ..
Laut Werbung selbst Surfanwendung bis zu 5 mal schneller ....
Mein Leidensdruck ist sogar bei 4GB RAM gering.
Wird nicht mal halb genutzt.
Dennoch irgendwie neu bei einem ehemaligen RAM "Schottten" wie mir;-)
Borlander Xdata „Wie genau das geht ist mir auch nicht ganz klar, es soll wohl...“
[AsRock XFast RAM] Wie genau das geht ist mir auch nicht ganz klar, es soll wohl eine Hardwaremöglichkeit sein RAM effizient zu nutzen der ansonsten noch nicht genutzt wird. Geht aber wohl nur mit den neuen ivy Chips und auch schon mit der Sandy Bridge.
Siehe http://www.asrock.com/feature/xfastram/. Scheint eine Software zu sein die eine bis zu 28GB große RAM-Disk oberhalb des 4GB-Bereichs anlegt. Gibt es auch schon anderweitig. Also eigentlich nichts wirklich Neues ;-)
Xdata Borlander „Siehe http://www.asrock.com/feature/xfastram/. Scheint eine...“
In der Werbung hört sich alles immer so neu und schön an;-)
Neu wär es Swap oder Ramdisk in nicht genutzten Bereich einer Grafikkarte auszulagern.
Ramdisk oder Pagefile mit DDR5 ..oder auch nur eine SSD die eigenständig wie eine normale Festplatte ist..
Hab, ganz früher mal Win95 in einer RAM Disk oder so laufen lassen.
Die hohen Festplattenpreise bringen einen auf ganz eigenartige Ideen ;-)
Borlander Xdata „In der Werbung hört sich alles immer so neu und schön an;-)...“
Swap oder Ramdisk in nicht genutzten Bereich einer Grafikkarte auszulagern. [...] mit DDR5
Durchaus eine interessante Idee. Schneller als der normale Arbeitsspeicher wird das aber definitiv nicht. DDRx ist da auch wieder eine Werbegeschichte und der Transfer in den Graka-Speicher ist relativ teuer und langsam (mit ein Grund warum sich GPU-Berechnung nicht für alle Dinge eignen). Und die dadurch verfügbare Speichermenge ist überschaubar...
Hab, ganz früher mal Win95 in einer RAM disk oder so laufen lassen. Die hohen Festplattenpreise bringen einen auf ganz eigenartige Ideen ;-)
Damals war RAM doch noch richtig irrsinnig teuer. Und ein paar wenige MB hätten es nicht ansatzweise mit Plattenpreisen aufnehmen können.
neanderix ghartl1 „editoren“
Auf beiden Plattformen gibt es gute und leistungsfähige Editoren.
ich nutze unter Linux mit KDE "Kate".
Auf Windows hat es mit Notepad++ angetan.
Ultraedit ist zwar nich leistungsfähiger und hat sogar eine Makrosprache, aber: werstens kost der Geld und zweitens brauch ich das nicht.
Volker
