LinuxWorld Conference & Expo 2003

[AndreasW]

Marc++us schrieb:

Sun hat natürlich dazu was geboten, klar oder? Java auf 64 Bit.

*aufschrei*

Ich frag mich wann die Sache endlich ins Rollen kommt...

[rüdiger]

naja, Linux läuft doch auf 64 Bit Maschinen, sogar auf AMD x86-64 und Itanium und der GCC optimiert auch schon dafür.

Wenn was ins rollen kommen soll, dann doch eher die Hardware zum Kunden. Softwaretechnisch seh ich kein Problem

[Marc++us]

kingruedi schrieb:

naja, Linux läuft doch auf 64 Bit Maschinen, sogar auf AMD x86-64 und Itanium und der GCC optimiert auch schon dafür.

Wenn was ins rollen kommen soll, dann doch eher die Hardware zum Kunden. Softwaretechnisch seh ich kein Problem

Naja, das ist aber sehr optimistisch. Wahrscheinlich rollt dann erst Mal die große Portierungswelle los... bis das 32Bit-Zeugs wieder unter 64Bit läuft...

Mir ist dieser Tage - auch nach einem Gespräch mit ein paar Leuten - in dieser Hinsicht etwas bezüglich .NET aufgefallen - MS spricht doch immer von Plattformunabhängigkeit, nur welche Basis-Plattformen sollen das sein? Es gibt doch nur .NET für Windows. Ich könnte mir aber denken, daß Win64 von MS als eigene Plattform betrachtet wird - d.h. daß .NET dann auf den beiden Plattformen Win32 und Win64 läuft. Das würde irgendwie Sinn machen.

[Gerard]

.NET programme auf ein .NET64 portieren, ne das glaube ich auch nicht aber können die programme dan wirklich von den 64 bit profietieren?
was hatt man den überhaupt von den 64bit auf den desktop (.NET ist doch für den desktop programme)? super ich kamm mir mehr als 4 giga byte speicher zulegen

[Marc++us]

Es gibt kein .NET64 - es gibt nur .NET. Identische API, identische Datentypen - egal ob Win32 oder Win64.

Die Voraussetzungen dafür sind in .NET vorhanden (z.B. die Festlegung der Datentypbreite, etc).

[Korbinian]

hinfahren und nen stand machen, oder hinfahren und spass+information haben? letzteres macht mehr sinn, wär auch ne tolle sache!
auch mal systems oder sowas in betracht ziehen

[Gerard]

Marc++us schrieb:

Es gibt kein .NET64 - es gibt nur .NET. Identische API, identische Datentypen - egal ob Win32 oder Win64.

Die Voraussetzungen dafür sind in .NET vorhanden (z.B. die Festlegung der Datentypbreite, etc).

jo ich meine auch das es kein .NET64 geben wird
zu den punkt datentypenbreite ist festgelgt, bedeutet dass, das ich von jeden .NET programm zwei versionen schreiben muss die für 64 bzw 32 bit optiemiert sind

[rüdiger]

Naja, das ist aber sehr optimistisch. Wahrscheinlich rollt dann erst Mal die große Portierungswelle los... bis das 32Bit-Zeugs wieder unter 64Bit läuft...

das unterscheidet eben auch Linux und Windows, weil Linux wird ja schon effektiv als 64Bit OS eingesetzt seit Jahren. Deswegen sollte die meiste Software auch keine Probleme mit 64Bit haben.

zu den punkt datentypenbreite ist festgelgt, bedeutet dass, das ich von jeden .NET programm zwei versionen schreiben muss die für 64 bzw 32 bit optiemiert sind

jo, wobei das idr. nicht der Flaschenhals sein dürfte

[Marc++us]

kingruedi schrieb:

das unterscheidet eben auch Linux und Windows, weil Linux wird ja schon effektiv als 64Bit OS eingesetzt seit Jahren. Deswegen sollte die meiste Software auch keine Probleme mit 64Bit haben.

Reine Theorie. Das betrifft nur die Serveranwendungen unter Linux.

Die Masse der Anwendungen wurde von den üblichen Softwareentwicklern geschrieben und wird daher unter 64 Bit neu compiliert und dann schön abschmieren, bis sie "hindebuggt" wurde. Die Entwickler werden doch nicht besser, nur weil sie in anderes OS haben.

[Marc++us]

Gerard schrieb:

Marc++us schrieb:

Es gibt kein .NET64 - es gibt nur .NET. Identische API, identische Datentypen - egal ob Win32 oder Win64.

Die Voraussetzungen dafür sind in .NET vorhanden (z.B. die Festlegung der Datentypbreite, etc).

jo ich meine auch das es kein .NET64 geben wird
zu den punkt datentypenbreite ist festgelgt, bedeutet dass, das ich von jeden .NET programm zwei versionen schreiben muss die für 64 bzw 32 bit optiemiert sind

Das verstehe ich nicht. Der Gag (wie auch bei Java) ist doch, daß ich KEINE 2 Programme unter .NET schreiben muß, sondern nur eines. Und wenn ich dort in meinem Quellcode einen 32Bit-Int verwende, so bleibt der in der MSIL als 32Bit-Int. Ich brauche nur eine neue VM für Win64, die den MSIL ausführt. Und wenn ich unter .NET einen long long 64Bit nehme, bleibt der im Code erhalten. Die Optimierung auf die Datentypbreite findet dann durch die VM statt - diese verwendet dann auf einem 64Bit-System z.B. auch für 32Bit-Int 64Bit, aber die Optimierung erfolgt doch ohnehin während der Laufzeit.

Das ist doch der Vorteil von JIT-Compilierung (wie auch Java besitzt) gegenüber klassischer "statischer" Compilierung - die Optimierung bei C++ muß während der Entwicklung "offline" gemacht werden und resultiert in unterschiedlichen Binarys. Bei einer JIT-Compilierung wird die Compilierung direkt auf dem Zielsystem vorgenommen und ganz genau an das Zielsystem angepasst, wodurch sie teilweise besser angepasst werden kann. Vor allem reicht es, eine einzige Applikation (mit MSIL-Code oder Java-Bytecode) auszuliefern.

[rüdiger]

@Marc++us
viele OpenSource Produkte wurden 64Bit fit gemacht, genau wie Endian Probleme gelöst wurden. Natürlich waren die Entwickler nicht schlauer, aber dadurch das es OpenSource ist, wurden eben Anpassungen von anderen vorgenommen.

Natürlich gibt es auch Software, die solche Probleme hat, auch wenn sie OpenSource ist. Aber die meisten (vorallem alle populären) Programme sollten für 64Bit vorhanden sein.