64 Bit
-
128MB und n Athlon XP 2000+ passen ja ausgezeichnet zusammen... :p
-
DrGreenthumb schrieb:
terraner schrieb:
Warte lieber: die neuen Prozessoren unterstützen nämlich auch noch die "NX"-Technologie: Hierbei werden NOP-Codes übersprungen, was den meisten Viren/Würmern/etc. einen Riegel vorschieben würde.
Hä? übersprungende NOPs? fehlen da jetzt die Ironie-Tags?? Irgendwie wiederspricht sich das nämlich mit dem Link in deiner Signatur. Demnach müsste man sich lieber jetzt schnell noch Hardware kaufen und danach anfangen zu boykottieren.
Nicht das ich mich damit jetzt auskenne... hab nur gegooglet was denn NX seien soll und fand das hier.
:o, das wusste ich noch gar nicht. Ich dachte, es sollte alles über den Palladium-Chip abgewickelt werden. Abgesehen davon ist NX-Technologie bei SUNs Sparc-CPU's schon seit längerer Zeit standard.
NXmfg
-
Lag der Rekord fuer die Kompilierung des Linuxkernels (2.4) nicht bei unter 10 Sekunden? Bei einer Compiler-Farm natuerlich..
-
Hallo
ich meinte 1 min und 30 s
(Quellcode > 250 000 Zeilen komplette Firmenbuchhaltung)MfG
Klaus
-
Ich behaupte mal die meisten hier können jedes Mhz Rechenleistung gut gebrauchen, schließlich sind wir doch alle Programmierer und je mehr Leistung umso schneller sind die Quellcodes übersetzt.
jo, der daily full rebuild nervt.
aber ansonsten tuts mein celeron 400 ganz fein.
das leigt aber vor allem daran, daß ich c++ programmiere und nicht java.
-
Shade Of Mine schrieb:
Sekunden ist untertrieben.
Aber wenn ein normaler Build (kein Rebuild) 1h30 dauert, sollte man versuchen die Abhängigkeiten etwas zu verringern. pimpl-Idiom ist da ne Möglichkeitund meine heutige erfindung, typedefs entkoppeln.
//windowsfwd.h #ifndef WINDOWSFWD_H #define WINDOWSFWD_H namespace windows{ typedef void* HANDLE; typedef unsigned long wDWORD; }//namespace windows #endifund
//windowsfwd.cpp #include "windowsfwd.h" #include <windows.h> #include <tools/debug.h> template<class A,class B> struct Equals{ enum{VALUE=false}; }; template<class T> struct Equals<T,T>{ enum{VALUE=true}; }; STATIC_ASSERT(Equals<windows::HANDLE,HANDLE>::VALUE); STATIC_ASSERT(Equals<windows::wDWORD,DWORD>::VALUE);jetzt brauche ich in allen meinen header-files, sei es col_iostream von marc++us, sei es ein FastFile.h (memmory mapped file access), sei es, ach, egal, was halt ein member braucht, dessen typ in der <windows.h> steht, nie mehr die teure windows.h zu inkludieren.
bin mal gespannt, wie sich das noch auswirken wird.
-
volkard schrieb:
und meine heutige erfindung, typedefs entkoppeln.
//windowsfwd.h #ifndef WINDOWSFWD_H #define WINDOWSFWD_HDu bist absolut krank! Das war im 100% positiven Sinne gemeint!!

-
volkard schrieb:
das leigt aber vor allem daran, daß ich c++ programmiere und nicht java.
rofl

-
Ich hab irgendwie Talent große Diskussionen anzuzetteln

Wenn ihr mit euren kleinen Kisten zufrieden seit freut mich das, ich hab lieber
mehr Rechenpower und das wollt ich mit dem da oben sagen, schließlich nützt es
euch doch wenig, wenn ihr in euren Quellcodes alle Abhängigkeiten toll minimieren
könnt (ich weiß im übrigen sogar wie das geht, hab ja brav scott meyers und herb sutter gelesen
),
aber mal etwas kompilieren wollt das nicht von euch ist, z.B. der Linuxkernel.Um gleich ner weiteren Diskussion vorzubeugen:
Ihr könnt natürlich über Nacht kompilieren, dann ist es egal ob es 1h oder 2h dauert.
-
Sgt. Nukem schrieb:
volkard schrieb:
und meine heutige erfindung, typedefs entkoppeln.
//windowsfwd.h #ifndef WINDOWSFWD_H #define WINDOWSFWD_HDu bist absolut krank! Das war im 100% positiven Sinne gemeint!!

kann mir jemand erklaeren was Volkard da gemacht hat ?
versteh nicht so ganz, was er mit "typedefs entkoppeln" meint.Meep Meep
-
Meep Meep schrieb:
kann mir jemand erklaeren was Volkard da gemacht hat ?
versteh nicht so ganz, was er mit "typedefs entkoppeln" meint.In Header Dateien hat man ja keine Funktionen stehen - folglich muss dort keine WinAPI Funktion deklariert sein. Allerdings braucht man Typen. Da windows.h alles inkludiert, ist es extrem riesig.
volkard schnappt sich einfach die Typen, packt sie in seine windowsfwd.h Datei und braucht deshalb die windows.h nicht mehr in jeder Header Datei inkludieren. Das kann jetzt zu dramatischen verkürzungen der Compiletime führen - je nach Anwendung.
-
Da gibts auch noch dieses WINDOWS_LEAN_AND_MEAN - define. Aber ich hab mir jetzt nicht angeschaut, was das alles rausnimmt.