3. Programmieren für 64 Bit

Programmieren für 64 Bit

  • ?

    mich würde ma interresieren wieso bei bool nicht auch 1 byte reicht. char braucht das für 256 buchstaben und klar, bool braucht 0 und alles was größer und kleiner ist, aber wäre es nicht auch mit weniger speicher zu bewerkstelligen?

    0
  • J

    Und bei MS compilern bleint int und long immer gleich gross, egal ob für x86 oder x64/IA64 compiliert wird.

    Und .NET 2.0 programme laufen unverändert auf x86/x64/IA64. Weder der Programmierer noch der Anwender bekommt davon was mit. Du musst auch hier keine zwei (bzw. drei) EXEn erstellen (was Du bei C++ machen musst).

    Du solltest aber beachten, das MS bei x64/IA64 nicht mehr alles so unterstützt wie bei x86 (z.B: keine Treiber mehr für Access-Datenbanken).
    Siehe:
    http://blog.kalmbachnet.de/?postid=61

    PS: Gehört eigentlich in Compiler-Forum...

    0
  • B

    TravisG schrieb:

    mich würde ma interresieren wieso bei bool nicht auch 1 byte reicht. char braucht das für 256 buchstaben und klar, bool braucht 0 und alles was größer und kleiner ist, aber wäre es nicht auch mit weniger speicher zu bewerkstelligen?

    also bei mir ist ein bool auch genau 1 Byte gross. es gilt ja char <= bool (kleiner GLEICH). Das liegt ganz einfach daran dass man eben festgelegt hat, dass char die Einheitsgroesse ist.

    Wenn du aber gemeint hast, warum ein bool nicht nur 1 Bit reicht: stimmt schon, theoretisch wuerd das reichen. Aber keine moderne CPU wuerd das unterstuetzen. Wenn ein bool nur 1 Bit gross waer, muesst die CPU immer gleich ein ganzes Byte aus dem Speicher laden um darauf zuzugreifen. Die kann gar nicht anders.
    Stell dir das nur mal vor, wenn eine CPU auf jedes einzelne Bit im Speicher einzeln zugreifen koennte. Dann muessten Speicheradressen gleich um ein Vielfaches laenger sein, und dass wuerd die CPU wieder ausbremsen.

    0
  • N

    Gast1089 schrieb:

    Und char ist als 1byte Variable definiert.

    naja, es gibt so komische prozessoren von texas instruments, da sind chars 32 bit breit weil alle maschinenbefehle mit 32 bit operanden hantieren. ..aber der begriff 'byte' bedeutet ja nicht zwangsläufig 8 bits (hab ich hier im forum gelernt 👍 )

    0
  • ?

    Blue-Tiger schrieb:

    TravisG schrieb:

    mich würde ma interresieren wieso bei bool nicht auch 1 byte reicht. char braucht das für 256 buchstaben und klar, bool braucht 0 und alles was größer und kleiner ist, aber wäre es nicht auch mit weniger speicher zu bewerkstelligen?

    also bei mir ist ein bool auch genau 1 Byte gross. es gilt ja char <= bool (kleiner GLEICH). Das liegt ganz einfach daran dass man eben festgelegt hat, dass char die Einheitsgroesse ist.

    Wenn du aber gemeint hast, warum ein bool nicht nur 1 Bit reicht: stimmt schon, theoretisch wuerd das reichen. Aber keine moderne CPU wuerd das unterstuetzen. Wenn ein bool nur 1 Bit gross waer, muesst die CPU immer gleich ein ganzes Byte aus dem Speicher laden um darauf zuzugreifen. Die kann gar nicht anders.
    Stell dir das nur mal vor, wenn eine CPU auf jedes einzelne Bit im Speicher einzeln zugreifen koennte. Dann muessten Speicheradressen gleich um ein Vielfaches laenger sein, und dass wuerd die CPU wieder ausbremsen.

    nein ich meine ein byte. ich dachte bool wär größer als ein byte. naja hat sich erledigt

    0
  • D

    Die einzigen Vorteile die man dadurch hat ist doch schneller mit ints die über die 32 Bit Grenze hinaus gehen rechnen zu können(wenn es denn mal sowas im Anwendungsbereich gibt) und genauere Fließkommazahlen zu haben oder?
    Ich frage mich grad wie die ihre "bis zu 30% schneller" Spiele rechtfertigen hier:
    http://amd64downloads.filecloud.com/dreadnought.asp

    Ich sehe nicht so richtig, warum bestehender Code schneller wird, nur weil die Fließkommazahlen genauer werden(die haben vorher ja auch ausgereicht) oder man mit größeren Zahlen rechnen kann.
    Programmiert man sowas sonst mit selbstgebastelten genaueren Fließkommazahlen oder wie?

    Hab auch mal gelesen, dass das dem mmx/3dnow Kram ganz gut bekommen soll, liegt das daran oder eher ein reiner Marketinggag?

    0
  • H

    TravisG schrieb:

    ich dachte bool wär größer als ein byte. naja hat sich erledigt

    Ist es teilweise auch. Ich kenne Compiler für normale 32-Bit Intel-CPUs, die 32Bit große bools erstellen.

    0
  • D

    Bei 32 bit Integern und einer 64 bit CPU könnte man gleichzeitig auf 2 Integer operieren.
    Wenn man zB eine Addition hat von 4 Werten würde eine 32bit CPU 2 Taktzyklen benötigen:
    1. a + b = x
    2. c + d = y
    Aber eine 64bit nur ein Zyklus.
    1. ac + bd = xy

    naja so in etwa, kenn mich mit maschinennaher Programmierung nicht aus.

    0
  • A

    dreaddy schrieb:

    Ich frage mich grad wie die ihre "bis zu 30% schneller" Spiele rechtfertigen

    ich kenn mich da nicht aus, kann mir aber vorstellen, dass ne 64bit cpu mit nem 8 byte double besser umgehn kann, als ne 32bit cpu..

    und nein, ich glaube kaum, dass man bei spielen selbstgebastelte zahlenklassen verwendet. allerdings passen eben "in einem durchgang mehr bits in die cpu".

    ist eigentlich interresant, ich glaub, das probier ich mal mit meinem amd64 aus..

    0
  • ?

    Ist doch recht einfach zu verstehen, wie das kommt. Für 64 Bit Werte sind diese Prozessoren sowieso schneller. Für 32 Bit Werte steht die doppelte Anzahl an Registern zur Verfügung. 😃

    0
  • P

    Auf normalen den AMD 64-Bit Maschinen sind aber Fließkommazahlen nicht anders als auf 32-Bit Maschinen. Da kann keine Verbesserung her kommen.

    0
  • J

    Optimizer schrieb:

    Für 32 Bit Werte steht die doppelte Anzahl an Registern zur Verfügung.

    Ich glaube Du hast keine Ahnung...

    0
  • A

    Ponto schrieb:

    Auf normalen den AMD 64-Bit Maschinen sind aber Fließkommazahlen nicht anders als auf 32-Bit Maschinen. Da kann keine Verbesserung her kommen.

    ich weiß ja nciht, wie es auf win ist, aber bei (linux) mir gibt es float mit 32 bit und double mit 64 bit..

    ich glaube mal gehoert zu haben, dass in vielen spielen nur double verwendet wird, da float zu ungenau ist..
    kann mich aber in diesem punkt irren..

    mfg aman..

    0
  • C

    Artchi schrieb:

    Nö, size_t repräsentiert die größte mögliche Größe auf einem Compiler. In C++ Standard gibt es keine Vorgaben, wie groß Typen sein sollen. Es gibt nur die Vorgabe:

    bool <= char <= int <= long <= size_t

    So in etwa... 🙄

    die standards (weder für C++ noch für C) machen keine aussage über die größe von size_t im vergleich zu den normalen integertypen, außer dass size_t ein typedef auf einen der grundlegenden integralen typen ist. den einzigen hinweis gibt die definition des sizeof operanden, denn dessen ergebnis ist vom typ size_t. außerdem existiert ptrdiff_t - das vorzeichenbehaftete gegenstück zu size_t - welches das ergebnis von pointerdifferenzen ist. daraus kann man folgern, dass sizeof(char*)<=sizeof(size_t) - wenn ein flacher adressraum zugrundeliegt (es sollte nicht vergessen werden, dass ein segmentierter adressraum ausdrücklich zugelassen ist, und dann ist diese folgerung nicht mehr zutreffend).

    0
  • ?

    Jochen Kalmbach schrieb:

    Optimizer schrieb:

    Für 32 Bit Werte steht die doppelte Anzahl an Registern zur Verfügung.

    Ich glaube Du hast keine Ahnung...

    Hallo geht's noch? 👎
    Lies lieber mal das: http://de.wikipedia.org/wiki/AMD64#Architektonisches

    Hieraus ergibt sich

    Die orange hinterlegten Register R8...R15 und XMM8...XMM15 stehen ausschließlich im 64-Bit-Modus zur Verfügung.

    Hui. 😮 Außerdem besteht AFAIK die Möglichkeit, ein 64 Bit Register als 2 32 Bit Register zu verwenden. Zumindest war es bei der ganzen x86 Architektur immer schon möglich, das halbe und viertel Register anzusprechen.

    0
  • D

    Hm hatte ganz verdrängt das doubles ja 8 byte groß sind ^^
    Ja gut dann ist es klar, dass der Compiler da was draus bauen kann, was direkter und damit schneller geht als auf 32 Bit Möhren.

    0
  • J

    Optimizer schrieb:

    Hallo geht's noch? 👎

    Ich gebs zu: meine Reaktion war etwas übertrieben...
    Aber rechen doch mal nach... dann wirst Du feststellen, dass ich nicht ganz falsch lag...
    Und von 32 nach 64 bit einfach davon auszugehen, dass dann "doppelt" so viele Register zur Verfügung stehen, deutet einfach darauf hin, dass man die Architektur der x64 nicht verstanden hat.

    0
  • D

    Jochen Kalmbach schrieb:

    Optimizer schrieb:

    Hallo geht's noch? 👎

    Ich gebs zu: meine Reaktion war etwas übertrieben...
    Aber rechen doch mal nach... dann wirst Du feststellen, dass ich nicht ganz falsch lag...
    Und von 32 nach 64 bit einfach davon auszugehen, dass dann "doppelt" so viele Register zur Verfügung stehen, deutet einfach darauf hin, dass man die Architektur der x64 nicht verstanden hat.

    Dann erzähl doch mal wie es richtig ist.
    Ich würde jetzt auch sagen das man doppelt so viele Register zur verfügung hat als auf einer 32bit CPU.

    0
  • N

    hey leute,
    ob 64- oder 32-bitter hat doch nix mit der anzahl der register zu tun. das heisst doch nur: "der prozessor kann 64 bzw. 32 bits parallel verarbeiten". es heisst auch nicht dass alle datenleitungen nach aussen geführt werden o.ä....

    0
  • A

    Ist doch auch von CPU-Architektur zu CPU-Architektur unterschiedlich. Z.B. haben die 32bit ARM-CPUs (StrongARM, XScale usw.) schon vor 20 Jahren 16x 32bit-Register gehabt. Und? Wenn die ARMs 64bittig werden, werden die dann 32x 32bit-Register haben? Schwachsinn! Wenn dann wird ARM jedes Register erstmal 64bit breit machen, und ob es MEHR Register werden, ist doch eine Design-ENTSCHEIDUNG und ist nicht implizit durch die 64bit gegeben.

    Wenn man wissen will, wieviel und wie groß die Athlon64-Register sind, dann doch bitte einfach in die entsprechende Doku des Prozessors schauen und nicht davon ausgehen, wie es sein könnte.

    0
Anmelden zum Antworten