64 Bit Raytracing In Cinema 4D R9 ?

[Per-Anders]

haven't there been enough threads about 64v32bit already? if anything you could expect to see a slowdown if c4d used 64bit double precision floating point operations (that's twice the ammount of memory to chug around for a start), the main advantage will simply be access to more memory, if the processors become faster than 32bit counterparts then you'll see a speed up, but not because of supporting more memory or using 64bit precision.

[Simon Wicker]

from the look of the realsoft website they are actually talking about their rendering precision not that the application has been rewritten to run under a 64bit OS. the last time this came up was when lightwave announced they were using a 128bit renderer at which point maxon yawned and mentioned casually that if you count the numbers in the way they are doing cinema has been a 256bit renderer for some time.

64bit will be interesting for people that need to work with large datasets but considering that no adobe app can yet address more than 2gb of ram you can see how long its going to take before we actually get applications that can really make use of a 64bit architecture.

cheers, simon w.

[martinweber]

I see there's a lot of confusion about what 64bit architecture means. Simply put, the CPU registers are 64bit (thus the integer data processing) and the adressing is 64bit.

So what does that mean for renderers? Nothing, really. Renderers use floating point operations that are on current CPUs either single precisision (32bit) or double precision (64bit). Any modern renderer usually uses double precision floats so you get 64bit precision already (per channel naturally).
Modern 32bit CPUs usually also can adress more than 2GB of RAM (that's the 32bit adressing limitation) through extensions. So nothing to win here either. 64bit integer calculations are also possible with 32bit CPUs (that's what the 64bit registers would be good for).

So what's to loose with fully 64bit systems (I talk OS + Apps all beeing 64bit)? The smallest adressable unit is 64bit - so that twice the memory and bandwith of 32 bit systems. That's not necessarily true - but highly optimized code places data at those boundaries to speed up data access. So that's now twice the data to channel trough your memory controller(s), the caches and the pipelines.

So is 64bit bad? No, definitely not. It's just there's no real need for it in most cases. You won't probably experience slow downs with 64bit systems but expect them to need more resources.

[bcbarnes]

While I agree with most of what assoc says, there is one interesting point that was incorrect. 64bit technology as implemented by the AMD64 also means more integer and floating point registers (i.e. 16 of each instead of 8). In addition, Microsoft is supposedly moving away from using the X87 for floating point (which is slow) and going toward SSE/SSE2, which is faster.

This means that if an app is floating point bottlenecked, and can be ported to AMD64, it should get some relief.

BTW - I just moved my C4D from a K7 running at 2Ghz to an Opteron system running 2.2Ghz, and one particular render that was heavy on radiosity went from 6m47s to 4m20s. I then added a second 2.2Ghz Opteron, and the render went down to 2m17s. This is all runninng 32 bit software/OS code.

[martinweber]

Well, the AMD64 improvements are a point of discussion. AMD64 CPU's are known for their excellent floating point performance. No doubt about it. Comparing them to the x87 co-processor (yes, they designed it as a seperate processor with it's own socket to plug in) is not really fair. The x87 has an stack based approach implemented in early 1980's and hasn't been improved a lot since then (unless you consider the inclusion into the main CPU from 386 on as considerable improvement). Any respectable compiler is using the SSE2 registers for floating point optimizations ever since.

As especially Cinema 4D is highly optimized for IA32/SSE/SSE2 it would be interesting how it compares to modern AMD64 CPUs. Do you know cinebench results for those? I've also experienced a boost from HyperThreading support in Cinema.

The increased number of registers is a moot point - intel increased the number of internal registers considerably (shadow registers). Additional registers are great but what's the point if no compiler makes use of them (as apps are still compiled for IA32 with the restricted adressable registers).

It would also be interesting to see the effects of a fully 64bit system (OS and Apps compiled for 64bit) on render performance.

Well, you still have to keep in mind that the AMD64 architecture is not complete 64bit but has large parts remaining 32bits IA32. Their stuff is good though - otherwise intel would not license it for the new 64bit extensions of their CPUs. I think AMD nailed it right with their approach of a soft migration to 64bit. Intel failed miserably in this area.

[martinweber]

Well, I have to correct myself: The 387 co-processor was integrated with the 486 and not the 386.

And I was probably exaggerating that every compiler is using SSE2 ever since those extensions became available. What I wanted to say is that any application developer that depends on fast floating calculations is trying to provide at least a SSE2 optimized version of the application (like Maxon does).
Sure the 387 numeric data processor was improved with (almost) each incarnation but the primary design of the stack registers made it impossible to bring the performance up to the state of the art. So intel indroduced a different way of highly efficient floating point calculations with SSE2.

Well, I see this is going way too technical now as the original question was about 64bit rendering - which Cinema does for a long time already.

What's still remains is how the current renderer performs on different systems. The CPU might be a main culprit in render speed but I think the memory access is critical too and AMD might have an advantage with the high bandwidth memory controller of the Opterons integrated into the CPU.

[flingster]

would be nice to see from a memory point of view...large amounts of scene data and large image sizes just don't mix currently. but there have been lots of threads on this around.

[Thalaxis]

haven't there been enough threads about 64v32bit already? if anything you could expect to see a slowdown if c4d used 64bit double precision floating point operations (that's twice the ammount of memory to chug around for a start), the main advantage will simply be access to more memory, if the processors become faster than 32bit counterparts then you'll see a speed up, but not because of supporting more memory or using 64bit precision.

1) Maxon has stated a few times already that they do use double precision data in their renderer
2) Opterons have 2x as many floating point and general purpose registers in 64-bit mode
3) Opterons have a 64-bit integer pipeline that hoses performance when running 64-bit arithmetic in
32-bit mode (the hosed performance is a result of compromises they made for compatibility with x86)

[Thalaxis]

Modern 32bit CPUs usually also can adress more than 2GB of RAM (that's the 32bit adressing limitation)


32-bits = 4 GB, not 2 -- the integers used for addresses are unsigned.


So what's to loose with fully 64bit systems (I talk OS + Apps all beeing 64bit)? The smallest adressable unit is 64bit - so that twice the memory and bandwith of 32 bit systems.


Not true... most software running on 64-bit systems that doesn't have a requirement for large amounts of
addressable memory uses 32-bit addressing to reduce the application memory footprint, and thus
alleviate the load on the busses.

[Thalaxis]

Well, you still have to keep in mind that the AMD64 architecture is not complete 64bit but has large parts remaining 32bits IA32.

That's not true at all. It's a 64-bit chip. The "32-bitness" is a masquerade for the sake of backward
compatibility.

[Per-Anders]

my point was that double precision on 64bit is double the memory of double precision on 32bit.

[Thalaxis]

my point was that double precision on 64bit is double the memory of double precision on 32bit.

According to the IEEE standards, double precision = 64bit, single precision = 32bit.

Of course, if you meant that double precision requires 2x as much memory as single precision and I
just misunderstood you, then you were entirely correct. :)

[Per-Anders]

you're right. my mistake.

[martinweber]

right, my fault: 32bits is naturally 4GB.

I don't want this to become a 32bit vs 64bit war. I've just researched a few facts and I think we all agree that 64bits will be the future. I think when you choose an Opteron now you don't gain much but you also don't have any disadvantages. I think the Opteron is really fine CPU.

To clarify some points that have been a bit vague so far regarding registers. AMD64 can leavarage its additional registers only in long mode. That has to be set by the OS. Just like protected mode on all x86 architecture from 386 onwards.

Generally speaking, 64bit results in double sized adresses and values. AMD did some really nice work on that. Operands can use the REX prefix to load values in 32 bit only. So the code size does not increase that much. Furthermore does the availability of 16 GPR (general purpose registers) often result in less instructions. So the code is not double the size but is expected to be only est. 25% bigger than the same 32bit code. Additional decoders have been implemented to compensate for that. What remains is increased cache pollution.

Additional to 16 GPRs (over 8 in IA32) AMD implemented 16 registers for SSE/SSE2 (8 in IA32). AMDs implementation is not as fast as intels on 128bit SSE operations but it's very fast for 64bit operations. Compilers are still not able to vectorize C/C++ code very efficiently so most of the time the SSE code will use 64bit - no real world disadvantage here too. I think x87 floating point calculations will not play any role in the future. Both intel and AMD try to get away from them - so AMD64 just provides them for compatibility (8 registers at 80bit as ever).

On a sidenote: the Itanium (IA64) has 128 GPRs in comparison to 8 on IA32 and 16 on AMD64.

What bothers me more and more the power those beast require (both intel and AMD). Gotta get lost of 100 Watts transformed to heat in a quiet manner!

[AdamT]

Let's not underestimate the importance of 64 bit operation, speed aside. The 2 Gb memory limitation is already a serious problem for large scenes. Yeah, I know about the 3 Gb switch in Windows, but it doesn't work on my system and it's still not enough.

[Thalaxis]

right, my fault: 32bits is naturally 4GB.


I figured it was just an oversight on your part -- since a signed integer ranges from -2 to 2-1 GB (0 is
a number, after all :)).


I don't want this to become a 32bit vs 64bit war. I've just researched a few facts and I think we all agree that 64bits will be the future. I think when you choose an Opteron now you don't gain much but you also don't have any disadvantages. I think the Opteron is really fine CPU.


Somehow, I doubt that you'll get any disagreements there. :D
Well, except from Intel, that is ;)


Generally speaking, 64bit results in double sized adresses and values.


Addresses. It doesn't require doubling up on values, and even in AMD64 running in long mode, you
have to specifically select long mode to run in. It defaults to 32-bit mode (I forgot what that was called),
and even if you need to use the memory, you can still use 32-bit ints and floats if they're sufficient
for your needs.


Additional to 16 GPRs (over 8 in IA32) AMD implemented 16 registers for SSE/SSE2 (8 in IA32). AMDs implementation is not as fast as intels on 128bit SSE operations but it's very fast for 64bit operations.


That's quite true; AMD's SIMD implementation isn't actually SIMD. It sidelines SIMD instructions into
serialized FP instructions instead of running them as SIMD instructions, so it doesn't actually run them
in parallel.

There is a rumor floating around that AMD plans to rectify that in the near future (i.e. the next
core revision), but I have yet to see any confirmation on that.


Compilers are still not able to vectorize C/C++ code very efficiently so most of the time the SSE code will use 64bit - no real world disadvantage here too. I think x87 floating point calculations will not play any role in the future. Both intel and AMD try to get away from them - so AMD64 just provides them for compatibility (8 registers at 80bit as ever).


I think you're right; SSE2 bypasses the x87 stack (which results in a lot of headaches for the
compiler and scheduler), and I don't think x87 instructions are even available in Long mode.


On a sidenote: the Itanium (IA64) has 128 GPRs in comparison to 8 on IA32 and 16 on AMD64.


Yes -- Intel was hell-bent on addressing the floating point and register starvation issues of their x86
flagship when they launched that project, and it shows. :)


What bothers me more and more the power those beast require (both intel and AMD). Gotta get lost of 100 Watts transformed to heat in a quiet manner!

You're not alone... AMD's latest core revision is cooler than the 130 nm version, and the information
Intel's released about the future of the Pentium-M and Itanium lines indicates that they also share
that concern. Besides, the big growth markets now are mobile and handheld, and I don't think we'll
be seeing any Prescotts in a handheld anytime soon ;)

[martinweber]

AdamT: True, but that's not really a CPU related problem as modern Xeon processors can address 36 GB of memory. The troubles come with the OS and applications that are not ready for it. Look at Maya 6.5 - they now can access a whooping load of 2.6 GB on WinXP. So what's the point of more addressable memory?

BTW: Where are the motherboards that support more memory?

And then there's still intel EMT64 extensions if you want to stick with Pentiums and Xeons.

From Intel's FAQ:
Q9: Is it possible to write software that will run on Intel's processors with Intel® EM64T, and AMD's 64-bit capable processors?
A9: Yes, in most cases. Even though the hardware microarchitecture for each company's processor is different, the operating system and software ported to one processor will likely run on the other processor due to the close similarity of the instruction set architectures. [...]

That's my complaint about AMD64 not being "true 64bit" as most of it is an extension of the IA32 instruction set.


Next stop: 64 bit drivers - without that there's no true 64bit OS. Well, can't take that long, can it? :D

[edit: had to fix all those "adress" spellings ;)]

[AdamT]

I haven't checked in a while, but I know my dual Xeon mobo supports up to 8 GB of memory.

[Srek]

I haven't checked in a while, but I know my dual Xeon mobo supports up to 8 GB of memory.
Yes. Xeons can use 34 Bit adressspace, but only very few (and extremely expensive) operatingsystems (MS Advanced Server / Datacenter Server) as well as Apps support this.
Cheers
Srek

[Thalaxis]

AdamT: True, but that's not really a CPU related problem as modern Xeon processors can address 36 GB of memory. The troubles come with the OS and applications that are not ready for it. Look at Maya 6.5 - they now can access a whooping load of 2.6 GB on WinXP. So what's the point of more addressable memory?


The Xeon 36 GB addressing is segmented, not contiguous. It's really a 4 GB segment + 4 bits for
segment addresses, so the most an application could potentially use is 4 GB. With a 64-bit OS,
an application could if necessary use as much memory as is available, far more than just 4 GB.


BTW: Where are the motherboards that support more memory?


Those boards cost almost as much as a full-fledged gaming rig, and usually don't even have AGP
slots in them. They're made for servers.



And then there's still intel EMT64 extensions if you want to stick with Pentiums and Xeons.


From the user's point of view, the difference between AMD64 and EMT64 is nothing more than
branding. Well, that and the fact that Intel is shipping more product than AMD (simply due to
production capacity), and AMD's solution has a much better memory subsystem. :D


That's my complaint about AMD64 not being "true 64bit" as most of it is an extension of the IA32 instruction set.


That still applies only when you're using a 32-bit OS on an AMD64 system. If you're running a 64-bit
OS with 64-bit software, it's a 64-bit system from the ground up. But 32-bit software will still only "see"
the 32-bit x86 programming model, or else it wouldn't be capable of binary compatibility with the x86
stuff out there now, so 32-bit software will ALWAYS leave performance on the table by avoiding the
extra resources the Opteron/Athlon64 has.


Next stop: 64 bit drivers - without that there's no true 64bit OS. Well, can't take that long, can it? :D


64-bit Linux has been around for a while... and WinXP64 RC1 hit the streets two or three weeks ago,
complete with 64-bit drivers.

[kuui]

also dont foget that even if u have 4 gbyte of RAM in your board along with the fitting CPU, windows won't give out more than 2 gigs to a single process, with the /PAE option you can push this to 3gbyte but i heard from stability problems with this option

[Newstream]

Hi !
I know this is an old thread but I've been testing C4D 64-bit with 4 gigs on Windows 64bit system for the last couple of days and I have to say that C4D-64 is really awesome because complex architectural scenes that would typically display that dreaded "not enough memory" window at render time are now being eaten for breakfast like its nobody's business. :bounce:
Hats off to Maxon for releasing this 64-bit version of C4D!
It's great stuff!

Cheers / Alex

[flingster]

Hi !
I know this is an old thread but I've been testing C4D 64-bit with 4 gigs on Windows 64bit system for the last couple of days and I have to say that C4D-64 is really awesome because complex architectural scenes that would typically display that dreaded "not enough memory" window at render time are now being eaten for breakfast like its nobody's business. :bounce:
Hats off to Maxon for releasing this 64-bit version of C4D!
It's great stuff!

Cheers / Alex

this is something i want to move towards hardware wise..
i'm now slightly worried about plugins like jenna/xfrog being not available as yet if ever.
but definitely something i want/need to do really.
ditools is available, but i've not tested it on a sidenote.

[Newstream]

this is something i want to move towards hardware wise..
i'm now slightly worried about plugins like jenna/xfrog being not available as yet if ever.
but definitely something i want/need to do really.
ditools is available, but i've not tested it on a sidenote.

Hi Flingster,

I too was a bit worried about missing plugins at first but it really isn't a big problem (depending of course what sort of things you do with C4D) because you can have both 32-bit and 64bit versions installed at the same time on XP-64. You can fiddle around with the scene in 32bit mode using all existing plugins, do a "current state to object" , "make editable" or bake parts that were created with third party plugins (like jeena mesh-arrays for example) After saving the scene one can reopen it in C4D-64 and let it take care of business. The only times I've encountered when this technique doesnt work or when one loses something on the way is when dealing with third party shaders.

/ Alex

[flingster]

yeah i guess... i'm already doing this to an extent with some older stuff anyways...its just handy to visualise some stuff all in one scene and nice not to always have geometry when it can still be part of heirarchy rather than made editable...but good point maybe i should be less worried about this...good advice..cheers.

[sketchbook]

good god, it's a geek fest!

so for us computer dummy's, what type of system do we need to buy with what OS, which will allow c4d to access much more than 2 GB memory? this is my biggest issue with cinema. constant OOM errors.

[Per-Anders]

o_O okay, don't quite understand that post constructure.... (bearing in mind this is a very old thread from back when there were a lot of threads and posts about 64bit floating around).

[-/\-Scott-M-C4D-/\-]

Constructure if you were a girl i would understand, but am not into that 3 bloke thing or two for that matter :P
But i think i get your point.
Nice to see my old thead pop up again

[Newstream]

edited......

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.