pouët.net

Go to bottom

AMD 64 FX

category: general [glöplog]
Which 64bit supporting C++ compiler are you going
to use when the AMD 64 FX will be released ? :)
added on the 2003-11-20 17:00:15 by 0x$$ 0x$$
btw I'm using VC++ 6.0 right now...
added on the 2003-11-20 17:01:15 by 0x$$ 0x$$
i'll keep my hands off both 64bit and C++ for as long as possible. Using Delphi and Free Pascal now :P
added on the 2003-11-20 17:09:35 by Duckers Duckers
thanks for sharing
As if 64 bit computing is really an issue on the desktop market yet.
added on the 2003-11-20 17:21:36 by tomaes tomaes
well DoomIII (which will be released before E3 next May) already supports 64bit...isn't DoomIII aiming on the desktop market ? :)
added on the 2003-11-20 17:32:01 by 0x$$ 0x$$
is there a desktop os with 64bit support?
added on the 2003-11-20 18:25:55 by bhead bhead
32:32 fixed point!! ;)
added on the 2003-11-20 18:28:26 by loaderror loaderror
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).
added on the 2003-11-20 19:26:00 by tomaes tomaes
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.
added on the 2003-11-20 21:36:56 by uutee uutee
64bit is gay
but as everthing thats gay, it will sooner or later dominate
added on the 2003-11-20 21:43:37 by elkmoose elkmoose
The reason is memory addresses, not int value ranges. The need for 64bit ints in actual arithmetic calculations is obviously rather seldom. :)
added on the 2003-11-20 22:15:47 by ryg ryg
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.
added on the 2003-11-21 09:19:34 by pantaloon pantaloon
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 ?
added on the 2003-11-21 10:18:20 by nystep nystep
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 :)
added on the 2003-11-21 16:04:59 by Optimus Optimus
Once upon, John Carmack was wishing for 64bit color mode and I was just wondering why would anyone need that? What do you say???
added on the 2003-11-21 16:06:29 by Optimus Optimus
Hmm,. fixed point with 64bit, nice point :) We can return back to oldschool pure integer 3d demomaking and build large worlds with that anymore;)
added on the 2003-11-21 16:08:15 by Optimus Optimus
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.
added on the 2003-11-21 17:21:48 by psonice psonice
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)?
added on the 2003-11-21 19:07:26 by uutee uutee
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..
added on the 2003-11-21 22:03:43 by Navis Navis
that some people stiill haven't heard of write combining... :)
added on the 2003-11-22 01:10:22 by ryg ryg
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 =)))
added on the 2003-11-22 14:45:36 by Optimus Optimus
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.
added on the 2003-11-22 19:25:31 by nystep nystep
...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?
added on the 2003-11-23 00:30:14 by moT moT
...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.
added on the 2003-11-23 00:32:36 by moT moT

login

Go to top