PDA

View Full Version : 64bit implications



stefanj
09-30-2005, 05:30 AM
Hey guys,

For small businesses it's not always easy to know everything about everything, but, more often than not; we just have to. So when Microsoft, Intel, AMD and NewTek all launch this 64bit hype upon us I have to do some research. I've been hearing bits and pieces about it the last two years, but the question has come up lately; should we start using the 64bit version when LW[8.5] hits the stands?

So let's imagine I go out and buy an AMD Opteron (dual core) chip with a new motherboard and a stack of RAM chips. I get XP pro 64, and update to LW[8.5] 64bit. Ok. From what I can tell, this rig would deliver the following benefits:

a) Super high speed loading times on large projects
b) Easier and faster management of large sized projects in Layout/Modeler
c) Rendering, well, I don't know how, but I guess expanded and boosted memory management would boost the rendering process and it's effeciency and speed. But I'm not sure.

In any case, these are just assumtions. I'd like to write down some questions, and hopefully someone on this forum know the answers.

1) How well is the dual core technology of the Opteron chip used by LW, now, and in future versions? It's twice the price of Xeon chips, so there has to be a good reason for buying it.

2) Will the 64bit structure actually help the rendering process?

3) Will certain plugin's (e.g. FPrime) and/or applications (e.g. Modo) not work in a 64bit environment? Or is it just that they will not be able to fully exploit the new infrastructure?

4) If we were to get 64bit systems to use as animation and modeling workstations, we would end up with a collection of 8 32bit computers. Can they still act as rendernodes, or do they have to be upgraded to 64bit systems too?

Well, I guess these questions are pretty basic, but still, these are things I don't know... So any help would be greatly appreciated.


-LSJ

lots
09-30-2005, 07:27 AM
1) Currently Xeons are only single core (though the dual core varient is coming very soon)

So the Opterons are Twice as much, because they're twice the CPU, and then some. (Not to be biased :P) Not to mention they run much cooler... among other things.

2) I could see rendering being more accurate on a 64bit platform. Mostly because of the increased size of the registers on the CPU its self. This will make it easier to calculate large numbers very accurately. Something a 32bit system would have to spend mroe time on. I dont know if this will translate into more speed, but I think it could at least make a better image (I dont have any experience with 64bit rendering though...)

3) WinXP X64 is capable of running a in 32bit mode called WoW64 (Windows on Windows). So far, I have not come across any issues with running my 32bit apps in WinXP X64, so it may not be a problem with modo. However, I hear that FPrime has some issues they are working on to get it ported to the 64bit environment. The speed lost to WoW64 is surprisingly very small. Most of my 32bit apps all run just as fast on 64bit windows as they would on 32bit windows.

Basically, If your program is a properly coded 32bit app, then it should work fine in 64bit windows. Windows XP X64 does not support 16bit code, thus if your program has any 16bit components (Normally found in the installers), then forget about ever running it on 64bit windows.

Also, make absolutly sure that all your drivers exist on 64bit. You cannot install 32bit drivers on 64bit windows.

4) My guess would be you could continue to use the 32bit machines as render nodes. But dont take my word for it, cuz I don't know for sure :)

Riplakish
09-30-2005, 08:05 AM
1) Currently Xeons are only single core (though the dual core varient is coming very soon)

So the Opterons are Twice as much, because they're twice the CPU, and then some. (Not to be biased :P) Not to mention they run much cooler... among other things.



As the AMD64X2s actually have two CPUs on the die, so they can be up to "twice as fast" as regular AMD64 processors.

Actual performance varies, of course, due to ther factors - RAM and disk bandwidth,
bus contentions, etc., and software optimizations are in that list. The renderer seems to have good support for running multiple threads, so you should be able to utilize the CPU power.



2) I could see rendering being more accurate on a 64bit platform. Mostly because of the increased size of the registers on the CPU its self. This will make it easier to calculate large numbers very accurately. Something a 32bit system would have to spend mroe time on. I dont know if this will translate into more speed, but I think it could at least make a better image (I dont have any experience with 64bit rendering though...)


This is a software issue more than a hardware issue. The size of an entity is consistent, so if the code uses a float, you get one level of precision, if it uses a double, you get twice as many bits of precision, if it uses a long double, you get twice as many bits of precision again. However, code that uses a double to store a value, even on a system that supports a long double, will still only get the double precision.

We'll see this raise its ugly head again in a moment...



3) WinXP X64 is capable of running a in 32bit mode called WoW64 (Windows on Windows). So far, I have not come across any issues with running my 32bit apps in WinXP X64, so it may not be a problem with modo. However, I hear that FPrime has some issues they are working on to get it ported to the 64bit environment. The speed lost to WoW64 is surprisingly very small. Most of my 32bit apps all run just as fast on 64bit windows as they would on 32bit windows.

Basically, If your program is a properly coded 32bit app, then it should work fine in 64bit windows. Windows XP X64 does not support 16bit code, thus if your program has any 16bit components (Normally found in the installers), then forget about ever running it on 64bit windows.



This is an API issue, not a code issue. I can write code that uses a short int and happily bang away on a 64-bit box. What you really mean is that 64-bit versions of Windows no longer support the WIN16 API, and that applications that call in to the operating system need to be _at_least_ WIN32 compliant.

You are correct that there are many installshield installers still floating around that haven't made it to the WIN32 API yet.

Similarly, the question came up about plug-ins. Plug-ins will need to be "right sized" to what they're interfacing in. If LightWave buffers are X bits long, then the plugin needs to handle them as if they're X bits long. If a plugin treats a 64-bit entity as a 32-bit entity, you'll get some whacked results, and behavior on different endian machines would probably be different.

So, basically, to matrix it...

32bit Plugin -> 32 bit LightWave -> 32 bit Windows = What you're used to.
32bit Plugin -> 32 bit LightWave -> 64 bit Windows = Works, but you have 32-bit limits, and some extra WIN32->WIN64 translation going on under the hood


No Plugins -> 64 Bit LightWave -> 64 bit Windows = Works, and you get all the benefits of the expanded sizes, where applicable (e.g. if Newtek didn't change a double to a long double, or a long int to a long long int, they'll still be the 32-bit sizes/capacity/precision)


32-bit Plugin -> 64 Bit Lightwave -> 64 bit Windows = Will probably fail (again, depends on the "sizing"discussion, above. Well written code may still work)

64-bit Plugin -> 64 Bit LightWave -> 64 bit Windows = Should be smoking.




Also, make absolutly sure that all your drivers exist on 64bit. You cannot install 32bit drivers on 64bit windows.


This will probably be painful for the next part of a year or so, but its true. Drivers have to conform to the WIN64 driver API.



4) My guess would be you could continue to use the 32bit machines as render nodes. But dont take my word for it, cuz I don't know for sure :)

Again, it depends on what Newtek does and doesn't change. If they don't change
precision values, and only update pointers to 64-bit to take advantage of the address space, you should be golden. If they add the extra bits everywhere to get better precision, there very well could be differences in render output from 32- to 64-bit
systems.

I hate editing a post after I sent it, but one more thought occured to me... My guess is that if they change all of the precision sizes, the Object and scene formats between a 32-bit and 64-bit system would either have to handle the size changes when loaded/saved, or be incompatible.

Similarly, they could up the precision sizes (32-bit systems support 64 bit variables, the manipulation is just more... "interesting"? from a technical standpoint), and let the pointer sizes be native to the platform.

Lightwolf
09-30-2005, 08:34 AM
32-bit Plugin -> 64 Bit Lightwave -> 64 bit Windows = Will probably fail
Just to add a bit... I give it 100%, basically because LW likes to pass pointer around. And how do you pass a 64bit pointer to 32bit software that isn't prepared for it? Exactly! ;)

Cheers,
Mike

Riplakish
09-30-2005, 08:54 AM
Just to add a bit... I give it 100%, basically because LW likes to pass pointer around. And how do you pass a 64bit pointer to 32bit software that isn't prepared for it? Exactly! ;)

Cheers,
Mike

All the world's a VAX,
And all the coders merely butchers;
They have their exits and their entrails;
And one int in his time plays many widths, <----- The Relevant bit here
His sizeof being N bytes. At first the infant, <----- and here
Mewling and puking in the Regent's arms.
And then the whining schoolboy, with his Sun,
And shining morning face, creeping like slug
Unwillingly to school.
-- A Very Annoyed PDP-11 (From the fortunes file on my FreeBSD system)

:agree:

mattclary
09-30-2005, 11:27 AM
So let's imagine I go out and buy an AMD Opteron (dual core) chip with a new motherboard

Or go with the AMD64 X2, pretty sure it's cheaper. The most economical scenario is to top out with an X2 processor on your workstation and build cheap render nodes rather than trying to go dual dual-core Opterons.

As to 64bit, don't do it if you aren't comforatble with it. If you reach a wall for 32bit, you will probably know it when you hit it and can make the move then.

I'm sure that the bigger 3rd party plugin developers are doing beta on LW 64, so don't be surprised if their plugins aren't ready when LW 64 is. Newtek would be foolish not to afford them that opportunity (and consideration).(hint, Newtek)

Riplakish
09-30-2005, 11:49 AM
:agree: I agree. A dual core X2 with 2-4GB of RAM running the 32-bit version will probably give you the best bang/buck/compatability matrix out there.

Kurtis
09-30-2005, 01:53 PM
I'm not a member of the Dev Team, so I can't speak with authoritative detail here, but I can tell you that plug-ins for 32-bit LightWave will not automatically work with 64-bit LightWave. There are changes that will be required from the developers of third-party plug-ins to work with LightWave64. If you are a developer, and you would like more details on what changes need to be made, please contact us, and we will be happy to provide as much information as we can to assist you with the process.

On a side note, LightWave 8.5 32-bit will run on a 64-bit system. So, you will be able to install both 32-bit and 64-bit LightWave on the same system running Win XP Pro x64. This will at least allow you to use your existing 32-bit plug-ins, without maintaining two separate machines.

Oh, and about your hint Matt, there are a lot of not-so-big 3rd-party plug-in developers in our beta program as well. :thumbsup:

mattclary
09-30-2005, 02:02 PM
Oh, and about your hint Matt, there are a lot of not-so-big 3rd-party plug-in developers in our beta program as well. :thumbsup:

:thumbsup:

.................................................. ...............

lots
09-30-2005, 02:22 PM
As the AMD64X2s actually have two CPUs on the die, so they can be up to "twice as fast" as regular AMD64 processors.

Actual performance varies, of course, due to ther factors - RAM and disk bandwidth,
bus contentions, etc., and software optimizations are in that list. The renderer seems to have good support for running multiple threads, so you should be able to utilize the CPU power.

I should have made my self more clear. I was talking about dual core Opterons. I was not referring to the fact that dual cpu/core does not translate to double the performance. Insted I was thinking in terms of cost. For example, the single cored Xeon can be priced at half the price of a dual cored Opteron simply because it is single cored. When you buy two Xeons, don't you end up paying twice the price for not exactly 2 times the performance? :) The same can be said for dual core vs single core I suppose.

Having two cpus or cores is never going to be exactly twice as fast, because not every app is multi threaded. Then there is a certain degree of overhead associated with communication between the cores/CPUs and allocation of resources that needs to be controlled. So it doesnt ever translate to twice the speed.

Anyway the reason for going dual core Opterons is for computing density. With a pair of dual core Opterons, you will have roughly the same power as a 4 CPU system packed into the space of a single desktop box. That means 4 - 8 threads for rendering :)

Also, from a programmer's point of view, dual core should appear like dual single core CPUs (assuming he's got enough abstraction between the programming language and the hardware). Thus I would assume that a programmer that has created a program to work in a multi threaded system, will not have to do anything (extensive anyway) to allow for use in a dual core system. Though I'm sure there are some optimizations that can be brought in to help improve performance. The OS should be handling some of the threading anyway (at least from what I remember from my OS coding class :P)

Riplakish: Thanks for clearing up my 32bit 16bit API disaster :P It is what I meant. I was in a rush this morning and ended up not looking too carefully over what I said before submitting :)

Riplakish
09-30-2005, 06:25 PM
Lots - no problem. As a software developer, variables sizes on different platforms are second only to endian-ness issues :)

Otherwise, I think a two CPU or dual core system should have many of the same bottleneck issues that allow neither to approach true 2x speed. Actually, based on my work with FreeBSD, how the OS schedules the processes and handles locking is _far_ more of an impact than the hardware limitations. With the advent of reentrent kernels, most of the bottlenecks go away. :)

lots
10-01-2005, 08:55 AM
Yeah.. It's been my feeling that software has got some catching up to do with the hardware these days.

Those crazy engineers keep designing new stuff before the old stuff is fully integrated into mainstream computers and software is taking advantage of it :/

Lightwolf
10-01-2005, 09:09 AM
Yeah.. It's been my feeling that software has got some catching up to do with the hardware these days.

Those crazy engineers keep designing new stuff before the old stuff is fully integrated into mainstream computers and software is taking advantage of it :/
Lol... well, cleanly design software shouldn't have much of a problem with a 64bit recompile, and nowdays any new, computationally intensive, software whould be designed with multiple threads as well (Digital Fusion being a very good example).
Then again ... I wrote _should_ ;)

Cheers,
Mike
P.S. Kurtis: I take you up on that offer, I need a 64bit capable system and compiler first though *sigh* :D