Laptop gesucht
-
Also lüfterlose normale Notebooks kenn' ich keine. Netbooks oder "Ultrabooks" wird es geben. Die werden dann aber vermutlich furchtbar heiss, was sehr unangenehm ist (es werden ja schon die Ultrabooks mit Lüfter oft unangenehm heiss - speziell unten aber z.T. auch das Keyboard bzw. der Bereich der Handauflage).
Programmieren über VNC macht man nicht, weil VNC laggt. Auch in schnellen lokalen Netzwerken. Für Remote Desktop gilt das selbe. Ist zwar alles im lokalen Netz deutlich besser als wenn man über's Internet muss, aber ich würde damit nicht arbeiten wollen so lange es auch anders geht.
Und was NFS (bzw. unter Windows wohl eher SMB) Freigaben angeht: das bremst doch auch bloss. Entweder vernichtet man sich dadurch die Responsiveness der IDE, oder aber das Compilieren wird (deutlich) langsamer -- je nachdem wo die Files liegen.
@Kellerautomat
Ich weiss aber auch nicht was das Problem an einem Build der 1/2 Minute dauert sein soll. Wird ja wohl hoffentlich kein inkrementeller Build gemeint sein und kein voller "rebuild". Und falls doch ist es Zeit das Projekt zu überarbeiten. z.B. Precompiled Headers verwenden und unnötige Header Dependencies suchen und entfernen.Und was die Kühlung angeht: wo sollte es denn rausblasen deiner Meinung nach? Oben? zzz
-
hustbaer schrieb:
Also lüfterlose normale Notebooks kenn' ich keine. Netbooks oder "Ultrabooks" wird es geben. Die werden dann aber vermutlich furchtbar heiss, was sehr unangenehm ist
Mit Broadwell wären im Prinzip lüfterlose NBs möglich, immerhin beträgt die TDP teilweise weniger als 5 W.
Allerdings bauen die NB Hersteller die NBs, die dann wirklich diese 5 W TDP CPUs haben, in so dünne Notebooks, dass der ganze Vorteil flöten geht und man wieder Lüfter braucht um die Abwärme loszuwerden. Zumiindest habe ich noch keines dieser neuen Broadwell NBs mit diesen Core-M CPUs gesehen, die dann wirklich keinen Lüfter haben.
Würde man so ein 5 W TDP Broadwell NB anstatt 1 cm 2 cm dick machen, dann wäre das problemlos lüfterlos zu kühlen.
Im Prinzip ist es sogar möglich alles mit einer geringeren TDP Anforderung als 10 W lüfterlos zu kühlen, allerdings braucht man für eine passive Kühlung auch eine entsprechende Oberfläche.
Programmieren über VNC macht man nicht, weil VNC laggt. Auch in schnellen lokalen Netzwerken. Für Remote Desktop gilt das selbe. Ist zwar alles im lokalen Netz deutlich besser als wenn man über's Internet muss, aber ich würde damit nicht arbeiten wollen so lange es auch anders geht.
Okay, ich habe VNC nie zum Programmieren ausprobiert, aber ich hatte das schon immer vor, wenn ich mal so ein Betttaugliches lüfterloses NB finde, aber bisher habe ich keines gefunden das mir zusagt.
Meine große Hoffnung Broadwell, bisher wurde die aber nicht erfüllt.Und was NFS (bzw. unter Windows wohl eher SMB) Freigaben angeht: das bremst doch auch bloss. Entweder vernichtet man sich dadurch die Responsiveness der IDE, oder aber das Compilieren wird (deutlich) langsamer -- je nachdem wo die Files liegen.
Nein, wenn du den Compiler über eine ssh Session anwirfst, dann sind die Dateien für den Compiler lokal auf dem Desktop.
Da bremst gar nichts.Nur dann, wenn du von deiner IDE oder deinem Notebook aus die Binarys starten willst, kann das bremsen.
Aber hier könnte man durchaus tricksen, weil man ja nur die Binarys braucht und nicht auch noch sonstige Daten remote vorliegen haben muss.
-
Auskenner schrieb:
Und was NFS (bzw. unter Windows wohl eher SMB) Freigaben angeht: das bremst doch auch bloss. Entweder vernichtet man sich dadurch die Responsiveness der IDE, oder aber das Compilieren wird (deutlich) langsamer -- je nachdem wo die Files liegen.
Nein, wenn du den Compiler über eine ssh Session anwirfst, dann sind die Dateien für den Compiler lokal auf dem Desktop.
Da bremst gar nichts.Nur dann, wenn du von deiner IDE oder deinem Notebook aus die Binarys starten willst, kann das bremsen.
Aber hier könnte man durchaus tricksen, weil man ja nur die Binarys braucht und nicht auch noch sonstige Daten remote vorliegen haben muss.Lies nochmal was ich geschrieben habe.
ENTWEDER die IDE auf dem Notebook wird beim Zugriff auf die Source-Files ausgebremst (nämlich dann wenn die Source Files am Desktop liegen). Wodurch Intellisense etc. vermutlich gröber laggen wird.ODER der Compiler auf dem Notebook wird beim Zugriff ausgebremst (nämlich dann wenn die Source Files am Notebook liegen). Wodurch das Compilieren ausgebremst wird.
Du kannst dir eine der beiden Variante aussuchen. (OK, beides langsam ginge natürlich auch, dazu bräuchte man bloss einen 3. Rechner. Aber beides schnell geht nicht.)
-
hustbaer schrieb:
Lies nochmal was ich geschrieben habe.
ENTWEDER die IDE auf dem Notebook wird beim Zugriff auf die Source-Files ausgebremst (nämlich dann wenn die Source Files am Desktop liegen). Wodurch Intellisense etc. vermutlich gröber laggen wird.AFAIK werden die Dateien in den Speicher geladen und nur darauf arbeitet Intellisense. Da bremmst also gar nichts, es sei denn ich liege im Irrtum und Intellisense arbeitet auf der langsamen Festplattenebene, was ich aber stark bezweifeln würde.
ODER der Compiler auf dem Notebook wird beim Zugriff ausgebremst (nämlich dann wenn die Source Files am Notebook liegen). Wodurch das Compilieren ausgebremst wird.
Compiler und Source Files sollen Remote liegen.
-
Auskenner schrieb:
AFAIK werden die Dateien in den Speicher geladen und nur darauf arbeitet Intellisense. Da bremmst also gar nichts, es sei denn ich liege im Irrtum und Intellisense arbeitet auf der langsamen Festplattenebene, was ich aber stark bezweifeln würde.
Intellisense muss aber ständig überwachen ob sich 'was an den Files geändert hat. Man müsste es ausprobieren, aber ich vermute dass es merklich bremst.
-
Ach, wenn wir bloß Maschinen hätten, die Milliarden von Rechenschritten pro Sekunde erledigen und Milliarden von Bits pro Sekunde über einfache Kupferkabel transportieren könnten...
Es ist ganz schön traurig, dass heute Software so ineffizient arbeitet, dass selbst einfachste Szenarien wie das Programmieren im Bett kaum möglich sind.
-
TyRoXx schrieb:
Es ist ganz schön traurig, dass heute Software so ineffizient arbeitet, dass selbst einfachste Szenarien wie das Programmieren im Bett kaum möglich sind.
Ein Programm ist halt nur so schnell, wie man es sich einrichtet. Wenn man jedesmal einen kompletten Rebuild braucht, dann muss man halt warten. Mit etwas klügeren Build-Tools ist das aber kein Problem mehr.
-
makefiler schrieb:
Mit etwas klügeren Build-Tools ist das aber kein Problem mehr.
Wie bekommt man das Linken mit GCC denn schneller?
-
Alter Schwede, TyRoXx, du hast so mächtig einen an der Klatsche.
-
-
makefiler schrieb:
TyRoXx schrieb:
Es ist ganz schön traurig, dass heute Software so ineffizient arbeitet, dass selbst einfachste Szenarien wie das Programmieren im Bett kaum möglich sind.
Ein Programm ist halt nur so schnell, wie man es sich einrichtet. Wenn man jedesmal einen kompletten Rebuild braucht, dann muss man halt warten. Mit etwas klügeren Build-Tools ist das aber kein Problem mehr.
Oder man nimmt eine andere Sprache als C++ oder C.
Aber Stroustrup hat ja neulich versprochen, dass er mit dem C++ Standardkomitee daran arbeitet, dass das compilieren schneller gehen soll.
-
Struppi FTW!
-
Upps, ja alter Schwede. Tippfehler. Korrigiert. Danke.
-
Hier sagt er das, dass er sich um die Buildzeit kümmern möchte:
