pouët.net

Which 64bit supporting C++ compiler are you going
to use when the AMD 64 FX will be released ? :)

btw I'm using VC++ 6.0 right now...

i'll keep my hands off both 64bit and C++ for as long as possible. Using Delphi and Free Pascal now :P

thanks for sharing

As if 64 bit computing is really an issue on the desktop market yet.

well DoomIII (which will be released before E3 next May) already supports 64bit...isn't DoomIII aiming on the desktop market ? :)

is there a desktop os with 64bit support?

32:32 fixed point!! ;)

venom: Doom3 will run perfectly on any 32bit x86 system. 64bit will be no major issue on the desktop market within the next 1 or 2 years (read: until the rise of the long horn... erm ;) yes despite of win xp, second edition).

Can someone tell me a *really* *good* *reason* to use 64bits in the first place?

When computers changed from 16 bits to 32 bits, there really, really was a need for a change. 64k of representable values simply isn't enough.

With 32bits you can represent a very large integer (if you really need a bigger one, you already want to use a specialized integer class).

That 32:32 fixed point thing sounds interesting as a democode hack, nothing else.

The only REAL reason for using 64bits (as I see it) is memory access - harddrives are already well over four gigabytes in size. RAM isn't exactly near four gigabytes yet (in desktop machines). When the change from 16 to 32 bits happened, the need for the change was desperate.

64bit is gay
but as everthing thats gay, it will sooner or later dominate

The reason is memory addresses, not int value ranges. The need for 64bit ints in actual arithmetic calculations is obviously rather seldom. :)

i can see alot of reasons where larger datatypes are useful, as someone pointed out above, 32:32 fixedpoint, alltho someone says its interested for a democode hack ?? i don't know if you call scientific calculations, 3d engines for games for democode hack, i don't. and for z-buffers, even now 32bit zbuffer with 16:16 fixed point sometimes lack the precision.

I will probably use Gcc. there are already OS supporting 64 bits, check out for Windows xp 64 bits edition. Pantaloon is right here, the larger integers are useless, except to address more RAM in pointers. the AMD 64 is however interresting because of its 16 integer registers instead of 7 for classic 32bits x86, and it also adds 8 new sse registers. This is probably the most interresting feature in my eyes of that processor. The issue is now: where is opengl64.dll ?

It's simply faster. REP STOSB was twice slower than REP STOSW which was twice slower than REP STOSD which will be twice slower than REP STOSQ. 8 bytes transfering at once could make my my ISA graphics cards fly :)

Once upon, John Carmack was wishing for 64bit color mode and I was just wondering why would anyone need that? What do you say???

Hmm,. fixed point with 64bit, nice point :) We can return back to oldschool pure integer 3d demomaking and build large worlds with that anymore;)

64bit colour is actually really useful. Sure, you can't see the difference when showing a picture, but when you're blending a shit load of layers, you don't get the shitty loss of detail you would with 24.

OMG, Optimus and back, and what does he say REP STOSQ is faster than REP STOSB :o

That's not real optimus, right, just a troll who guessed his password (girlsareevil)?

Optimus, man, what the fcuk are you talking about ? drunk again ? rep stosq on your isa graphics card, oldskool pure integer what ?? does not compute..

that some people stiill haven't heard of write combining... :)

I am just joking lompas :)

Btw,. you have heard about the Unix 2038 bug, haven't you? (I have heard about that, first in the www.johntitor.com case btw =)))

yep ryg ;)

it's quite funny to hear that some people still beleive that rep movsb is 4 times slower than rep movsd. in fact all modern processors have write combiners and cache, so these kind of optimisation are no longer very efficient. according to :
http://cdrom.amd.com/devconn/events/gdc_2002_amd.pdf

you can see that rep movsd is only 3% faster than rep movb on an athlon xp.

...not to mention that if someone really wants to make such optimizations for modern processors, he would probably need to follow different code-paths for Athlon XPs and P4s, since their internal functionality is tottaly different. He would have to calculate the working data sets so that they can fit in the various caches (and that's the easy part), see to that ops are aligned in such a way so that they keep the P4's long pipeline busy, burn themselves in the effort to avoid memory fetching miss-predictions, work some more to see how they can benefit from the P4's hyperthreading etc etc.

And after doing all that, they would probably need to forget all about it and start from scratch, since new processors would be available that benefit from new and different optimizations.

I say, "grow up". Let the compiler developers do that shitty work, you probably can't get any better than 10% more performance compared to a 'smart' compiler. Unless you have too much spare time in your hands. In which case I believe your efforts would be more beneficial in actually developing a smart compiler in the first place. Isn't programming all about reusability in the first place anyway?

...and I didn't even mention MMX, MMX2, SSE, SSE2, SSE3 (supposedly available in the new P4 Prescott cores next year), 3DNow! Altivec and all those different optimization hacks each processor has.