Last message on previous page:

Yes, most of us are working with 32bits on a 64bit chip. The thing is, moving to 64bit windows doesn't make things faster. Indeed, I haven't seen anything that suggests x86-64 is faster then x86-32. What I have seen are driver issues when moving to x86-64. I hear Vista64 is better then XP64, but I don't run either to test.

Yes, most rigs are able to run 64bit code. Most rigs however don't even begain to use the power that they are capable of. Increasing clock speed, or adding extra cores to the chip will increase performance. The biggest benefit so far to x86-64 is the extra memory registors. And even then it will be awhile before most people need 4GBs+.

Why do you keep saying that the only benefit would be the extra memory registers? I don't see how that follows. Where is GreatGrapeApe when a moron like me doesn't understand something like this? lol
I understand that the 64 bit OS's are capable of opening up more memory to the system, but it still doesn't answer the question as to WHY 64 bit wordlengths wouldn't increase performance significantly(with the proper implementation-64 bit software, hardware, and OS)?
I mean, if this is the case, then why even move from 16 bit to 32 bit? Why even make 64 bit chips if they weren't fundamentally more powerful?
I worked on the Mk41 VLS (vertical launching system) in the Navy and we had two main computers: the YUK-22 (8 bit) and the YUK-44 (16 bit). There was a HUGE difference in system load and execution times with the 44's just like there were huge gains made between 16 bit and 32 bit CPUs.

Because AFAIK, the memory registors are the only real difference between x86-32 and x86-64. I don't think the chips themselves are any wider inside. Think of this. The Intel chips that support and don't support x86-64 were one number off. Intel for awhile was making chips that HAD 64bit support, but had that support turned off. If the chip was wider inside, then how do you turn off half the chip? Its easier to do if you are simply ignoring the extra memory registors.

They are the same chip, but the x86-64 chips simply have more memory pointers.

Because 64-bit processing isn't inherently that different. It's not faster, it doesn't have more cache. The only difference the _64 marker implies is that the address bus is built to handle 64 bit chunks of data. It doesn't even need to handle these 64-bit chunks as fast as the 32-bit version does, although thankfully most processors are close or better. This doesn't cause a performance boost because no program needs more than 32 bits worth of address space -- and most use less than 16 bits <i>still</i>, with only the most recent games really requiring the 30th, 31st and 32nd address bit.
Most modern home computers can't even benefit from the extra address space : we simply don't have many applications that need 2^32 or more units of RAM. In fact, many programs would end up with (slightly) worse performance in a purely 64-bit environment, as they must read an extra 32 bits of data for every memory pointer.
Why doesn't the extra word length help other devices? Outside of pointers, which must be integers, everyone else has the option of using floats for any value likely to exceed 2^32nd. The x86 architecture has had eight 80-bit float registers since the 486 came out, though the x87 marker. More recent processors come with eight 128-bit float registers thanks to the SSE functionality with the Pentium III. We've really been using 128-bit computing for the last ten or twelve years.

The transition from 16 bit to 32 bit code occurred for the very same reason : 65 MB of memory was no longer enough for most applications.

In the future, 3.8 gigabytes won't be enough. Rather than wait until we reached that particular marker, both AMD and Intel have integrated 64bit support in their current CPUs. This way, all that needs to be changed in most computers -- specifically, those created in a timeframe such that they're likely to be able to physically fit 4 GBs of RAM -- is the software. This way, there's nearly no risk of expensive hardware being made useless when new software is required; only the new software must be updated.

Since the changes required for the 64-bit architecture are both minimal and of minor cost, this was a very viable solution for everyone involved.

Vastly different circumstances -- early computers did not have the same floating point capabilities in addition to integer power. And a Core2Duo with 5 gigabytes of RAM will certainly perform better than a Pentium 4 with 3.8 gigabytes of RAM.

Microsoft got rid of the 9x kernel for one very good reason, development. Having to write things that are compatiable to two different kernels is a royal PITA. Ever since MS made Win95 and WinNT3.5, they've been moving to a merged kernel. XP was the finalization of that merged kernel as each O/S moved closer and closer together. Microsoft is trying to move everyone to one platform to save money for everyone, not just themselves.
I didn´t want to point that one out in too much detail. Saying it´s a byproduct actually means the same thing as saving money. I actually believe some people can draw basic conclusions themself. Do you think i should edit my post to make it more idiot proof? 8O

The word-size of the machine usually only defines the size of its general purpose registers i.e. for integer and memory addressing operations.
However, floating point and SIMD registers are already 64, 80 or 128bits wide so moving to a "64bit" chip will not effect the performance of FP/MMX/SSE beyond adding a few more architectural registers in the x86-64 ISA (a few percent speed up at most). Doubling the size of your integer units will make long multiplies 4x faster and long addition\subtraction 2x faster, but 32bit already gives us +/-2x10^9 and most software doesn’t even need that much scale or precision so will not benefit at all. In cases where programmers have needed to use larger values they have generally used the SSE or FP units which are faster (and already > 32bits). So 64bit gives you the ability to address more memory at the expense or making code and data structures bigger and thus needing more cache and memory bandwidth (in fact under x86-64 the default data size is still 32bit to alleviate this problem), it was never about performance in the first place.

Multicore, on the other hand, is about performance. However, it’s to do with the hardware manufactures running out of cost effective ways to use their exponentially increasing transistor budgets so they have made their problems the programmers instead. Unfortunately, Amdahl's Law comes along and bites you on the ass since most home user software is largely sequential in nature. It’s great for servers where you can do the same thing x1000 client connections but even then it is not easy to get right. The problem is that the applications used to benchmark multicores on web sites all generally fall in the category of “embarrassingly parallel” in nature. It’s not very hard to render two different frames or even parts of the same frame in a 3d render program since there isn’t really any interaction between your threads (each pixel or frame is generally independent of the others). Most algorithms are no where near as amenable to multithreading since they have a lot of shared state that must be synchronised between the threads. This is both error prone (and exceedingly hard to debug) and computationally expensive. You only have to read the multithreading news groups for a short time before some Muppet post something like

“Hi, I have just spent the last 6 months multithreading our app. I can get both cores to 100% but its slower than before. Why? P.S. My boss said I will not have job next week if I don’t get it fixed. Help me!”

The problem is that the overhead of synchronisation increases dramatically as the threading becomes finer grained and unfortunately the benefit of multithreading becomes less and less the more course grained it is for a lot of algorithms, so it’s a catch 22 situation. Often the multithreaded version can even be slower on real world hardware! The trick is learning when not to use it or to switch to a different algorithm (if there is one) that is more amenable to this approach. However, this may in turn be a slower approach (per core) and you may not break even until you have 4x the computing resources. 2x the cores to make something 10-20% faster or 4x the cores to make something 50-80% faster is not really efficient is it? That is of course assuming you have 2 or 4 cores and nothing else is using them at the time (which the programmer can’t tell in advance)… Shared caches help reduce overheads but synchronisation will never be as fine grained, hardware accelerated or as low latency as between the execution units of a chip so why do people believe that compliers or programmers will have any better luck with threads than with the superscalar architectures they already have? It is not a case of being hard (like an exam) it’s often just impossible.

As for software today, most programmers use threads to make their code simpler since as hard as multithreading is, it is still simpler than asynchronous IO. So they use threads (which only exist to multitask CPU time) to multitask IO or just make the program more responsive or because they look cool on your CV. This kind of threading is just another form of programming inefficiency (except perhaps for servers, services and OS code that may need to service many requests at once) and is not a good thing to see.

Yeah but no but

Yes x64 requires more memory...and on a desktop OS for people playing games makes no difference

Far Cry has 64bit and thats got extra levels and stuff

Bottom line:
Windows sucks :evil

Ok, I think that I understand now. Basically, all the extra cores and extra bits are just bullshit marketing hype. It's kind of what I thought in the beginning. Sounds to me like the chip companies are just throwing more cores/more bit marketing down our throats because of a potential that will probably never be realized anytime soon. Remember: MORE CORES: DO MORE!!!
I didn't realize the general complexity of the issue and how CPU's work in general but I think that I have a better understanding of it now. Thanks.

Nope.

After we run into programs or individuals multitasking so much that they need more than 4 gigabytes of memory, 64-bit processors will have a huge performance difference. If Fardoomcrysis 2 runs optimally at 5 gigabytes of memory -- not a bad assumption in two to four years -- you'll never be able to get it to run optimally on a 32-bit processor. Depending on what version of Windows you're running, you might be stuck with less than 3 gigabytes of addressable memory, barely hitting the minimum requirements This isn't exactly a small performance drop, as anyone that's tried running Stalker with a half gigabyte of RAM could tell you.

If you multitask, at all, you will see some benefit. You do multitask, even if you don't notice it -- Microsoft Windows itself has several threads running, which can take up so processing power. If you use any programs with multiple, non-interdependent subprocesses, including most games, you'll see huge benefits.

A little harsh....

Don't get me wrong, we will need 64bit soon (and already do in the server space) its just not going to speed your CPU up. It just allows you to use >4GB without windowing and pagetable hacks like AWE & PAE. This is why windows hasn't really gone 64bit on the desktop, the software is here (XP/2003/Vista x86-64) it is just 99.9% of users don't need it (yet). As for linux... The situation isn't really any better since you from asking the question "Does my hardware work with windows x86-64?" to "Does it work with linux at all?" The answer to both questions is usually "Yes! But...", linux users are just more used to the buts, and beta driver code, and drivers hacked from productA to productB with limitations etc (gerneraly just a bit more tech savy). Multicore also is a great help in certain tasks, in others its not worth the effort or not really possible to any great extent. So even if all the programmers out there didn't write sloppy, badly documented, inefficent and buggy code (and thats a big if) they still wouldn't be able to multithread a great proportion of software.

Microsoft got rid of the 9x kernel for one very good reason, development. Having to write things that are compatiable to two different kernels is a royal PITA. Ever since MS made Win95 and WinNT3.5, they've been moving to a merged kernel. XP was the finalization of that merged kernel as each O/S moved closer and closer together. Microsoft is trying to move everyone to one platform to save money for everyone, not just themselves.
I didn´t want to point that one out in too much detail. Saying it´s a byproduct actually means the same thing as saving money. I actually believe some people can draw basic conclusions themself. Do you think i should edit my post to make it more idiot proof? 8O

The thing is, what you cut out of your post in the above reply is that you stated that it was better to have two different kernels when it is not. A single kernel means less development time and only certain services will need to be added to turn a workstation O/S into a server O/S. Likewise, trying to move the O/S to strictly 64bit means less development issues again compared to trying to do both 32bit and 64bit. Microsoft is trying to make thing easier for everyone, but there is still a push back that is occuring because people don't want to learn how to develop things differently (this happened back when Windows 95 and Windows NT 3.51 came out with trying to get people to start doing 32 bit programming instead of 16 bit programming).

Check out this link. It's from a blog of one of the developers of Photoshop, on why the CS3 version is 32-bit and not 64-bit. A quick summary - yes, they could use more ram that way, but since all pointers would then be 64-bit, the memory bandwidth kills them. He claims that currently, Photoshop is so optimized that they simply cannot feed multiple cores enough data to keep them maxed at 100% usage.

http://blogs.adobe.com/scottbyer/2 [...] swhen.html

Then check out this link, talking about Valve moving the Source engine to use multiple cores. Again - it sounds easy, but to fully utilize multiple cores (and not design it for a specific number of cores) requires very very difficult changes in the architecture.

http://arstechnica.com/articles/pa [...] ticore.ars

Multithreading something that doesn't "naturally" want to be that way can give you great returns, but can be very difficult. The problem is synchronizing the two cores - they're constantly swapping out different programs as the OS schedules different programs to run, which means that if you give the same amount of work to both cores, one will always finish before the other - and then need to sit around doing nothing, waiting for the other one to finish.

You're -always- multitasking. Dual cores are a good thing right now. One core for your game, the other to run the 57 other processes Windows has running.

Thanks! That was really interesting. I'm looking forward to a rewrite of the Steam engine, as Valve make CS and HL don't they? Great fun to play

If you want a LEAN OS, try the BE-OS. It can make applications run 1,000 x faster just like you expect the E6600 to run 1,000 faster than the 386. I believe there are other lean OSs like an early version of Linux or a Real-Time OS. So yes, there is a way to make a fast PC look fast. See how many FPS you can get running Quake-1 on a 8800GTX and a clean install of DOS.
But yes, I agree current OSs are way too bloated, even the Mac OSX. You may also be shocked if you looked at how primative and limited a C64 is now (in ULTRA LOW RES).

No offence buddy, but even Linux is far from perfect. First reason for me would be gaming. Forget it on Linux. For anything elses, it's much less (generally) intuitive then under Windows. Even if I consider myself quite good on a computer, I wouldn't be able to do much under Linux. I would have to learn too much new stuff to be efficient for quite a long time.

The move to 64-bit apps is in developpement right now. I myself use both WXP 32-bit and Vista Home Premium 64-bit. Altough there's no 64-bit apps to speak of right now, it'll come before we can expect it I think. This is because software developper are very conservative and really don't want to risk loosing money. As soon as the 64-bit market will be big enough, you'll see 64-bit apps start popping out. With poeple going to 64-bit more and more under Vista this market is about to be ready for prime time.

Then again, I might be wrong. I just hope not.

I forgot this one. Will it go available to previous version of HL2? I'm just awaiting to see the performances gains with the extra register available and everything elses. That's if there is any gains at all.

Last question. Will it require a patch or a new install to be available on my 64-bit Vista????