[sidenimjay]

i have seen a tremendous speed difference in performance between the
64bit linux and 64bit windows running on vista.


i just got a new laptop and have installed ubuntu64 and vista ultimate

vista ultimate had around a 132 benchmark on the test scene that ships with maxwell, and
the same machine in ubuntu 64bit had around a 75 to 90 bench

i have not run this with the previous checks of limiting the threads or such
but just found it curious that the performance from the same machine
was so great with a different os ...

is the linux version as optimized as the windows version? does it vary by the particular linux flavor? should i use redhat or suse instead of ubuntu?

i can rerun the tests again to provide more accurate info

[GavinScott]

Just a guess guys...Maxwell doesn't require 64bit precision internally...so, you're pushing around a lot of unnecessary data in the form of pointers that take twice the room they do on 32bit.

In general program always run slower when compiled for 64-bit mode, mainly for the reason JD points out. All memory addresses get twice as big and take up twice as much memory, cache, memory bandwidth, etc.

With Windows it's a bit more complicated as in 64-bit mode you get more registers and a few other processor features so the problem isn't as bad as it is for most RISC architectures for example.

But generally the rule is that your program will run slower unless it needs more than 4GB of memory (maybe 2GB in Windows since >2GB is a bit of a hack in 32-bit Windows). If you gotta have 8GB of memory to get the job done, then 64-bits means you can get it done where you couldn't in 32-bits (or it would be dog slow because of swapping etc.)

So in most environments people run their applications in 32-bit except for things like database servers (Oracle etc.) that run way faster if you can give them more then 2 or 4GB or ram to play with. 3D applications are on the edge where sometimes >4GB of ram is needed and worth the cost, but a lot of the time if your problem fits in 2GB or less then you're much better off with a 32-bit version of the app.

A program that uses integer math *might* make use of having native 64-bit registers in 64-bit mode, but virtually all 3D stuff is floating point where there's virtually no advantage to compiling in 64-bit mode, since the 64 (or more) bit floating point hardware was already available in 32-bit mode.

So when it comes to 64-bit software, don't do it until you have to, and that generally means when you get a big win from being able to have one program using >2GB or RAM at a time.

64-bits just means bigger, not faster.

But sometimes bigger is exactly what you need too.

G.

[glypticmax]

I use Win XP 64. Can't live without it.
Rhino 4 (32 bit), C4D R10 64 with Mograph and Maxwell Studio 64 .
Even with the so-called "3 Gig Switch" set, 32 bit will not allocate more than 2 gigs of RAM per operation, according the MS site that addresses such issues.
So if you need more than 2 gigs for something like meshing, opening heavy meshes or certain opertions in Rhino, like I do, 64 bit may be for you.
If 32 bit is sailing smoothly for you, 64 bit may be a waste of time.
I also like the fact my vid card has 64 bit drivers. That helps a lot.
My puny dual core/4 gig set up seems very happy with Maxwell 64, but I am interested to see if some tweaks are forthcoming.

[Tim Ellis]

Cheers Tom.


Tim.

[b-kandor]

I'm wondering if the xp64 with quadcore (or greater) slowdown is an official bug? I just got my q6600 processor today and ran an identical test (benchwell) in both 32 and 64bit windows versions . Result: the 64 bit test took 4.22 times longer (93 mins to 22 mins). Clearly something is wrong, no?

[GM5]

I'm wondering if the xp64 with quadcore (or greater) slowdown is an official bug? I just got my q6600 processor today and ran an identical test (benchwell) in both 32 and 64bit windows versions . Result: the 64 bit test took 4.22 times longer (93 mins to 22 mins). Clearly something is wrong, no?

I second that! I have a dual quadcore and can confirm the 4x slowdown using M~R 64 (on Windows XP 64). I have run benchmarks with the same system comparing VRay 64 vs VRay 32 - the 64 bit version is a bit (pun intended) faster. There must be a bug with the way M~R 64 handles multiple cores.

[b-kandor]

It's strange because the cores (in my case 4 cores) are working at 100%. It's almost like they have the same seed or something....

[ivox3]

It's good to not be alone on this ......

Misery loves company...

[GM5]

It's strange because the cores (in my case 4 cores) are working at 100%. It's almost like they have the same seed or something....

I noticed that also. I didn't think all 8 cores were being used due to the lack of speed but they were all pegged at 100%.

[Mihai]

I'm wondering if the xp64 with quadcore (or greater) slowdown is an official bug? I just got my q6600 processor today and ran an identical test (benchwell) in both 32 and 64bit windows versions . Result: the 64 bit test took 4.22 times longer (93 mins to 22 mins). Clearly something is wrong, no?

Are you sure the two renders (32, 64) reach the same quality level? I mean just by looking at the renders do they have equal noise amounts? Could you please run two renders on the 64 machine setting threads to 1, and another with threads set to 4 and visually compare the results?

[b-kandor]

Ok, I will do that, but my previous test was the benchwell test scene rendered to exactly sl15 in both cases.

Just to be clear, this is what I did:

In winxp64 using the 64 bit version of maxwell 1.5 it took 93mins to reach sl15.

On the same machine but rebooted into winxp32 using the 32 bit version of maxwell 1.5 it took 22 mins to reach sl15.

In both cases all four cores were pegged at 100% and threads were set to 0.

This is my hardware:

q6600 @ 3.0ghz
P5B deluxe wifi ap
4gb of OCZ platinum ddr2 800
quadra FX1500


Kandor

I

[b-kandor]

Update, I'm running the 1 thread test on the benchwell scene in xp64 - and it looks like it will finish in 65 min. I'll try the 4 thread test after and I have a funny feeling it's going to be identical.

(ps. I think my 93 min test mentioned above must have been before overclocking so disregard that number)

[Mihai]

Thanks! When you run the 4 thread test, please set threads to 4, not 0.

[b-kandor]

Yes I'm running that test now, and the difference between 4 threads and 0 threads is remarkable to say the least. It looks like the 4 thread test will finish in 40min. (still twice as long as win32) but much better.

I've done a lot of tests and decided to put the numbers in a spreadsheet. The amazing thing so far is that the fastest time on my quadcore (64bitmr and 64bit winxp) is by setting threads to "2"

*refresh to see udpated table


Here is the one thread test:
http://npara.com/images/win64-1thread-sl15.png

Here is the 4 thread test:
http://npara.com/images/win64-4thread-sl15.png[/img]

[Mihai]

This is strange, I see you made two tests for 64bit (Maxwell also 64bit), one overclocked, one not overclocked. The one that wasn't overclocked was 1h 04m and the overclocked test was 1h 51m. Are you sure that's right?

Can it have something to do with the overclock, some step down feature in the motherboard that throttles back the CPUs if they get too hot?