Cheetah3D 5.2 64 bits (OSX10.5 and up)

DarthSidious05

DarthSidious05

0
Messages
672
Cheetah3D 5.2 64 bits (OSX10.5 and up)

Now that it's more or less been confirmed that Cheetah 5.2 will require OSX 10.5 and up in order to support 64 bits, I'm still unclear on all the advantages of Cheetah supporting 64 bits versus 32?

Only reason I ask, I have 10.4 that supports all of my classic software which was an investment, and wasn't quite ready for a new computer, as I read 10.5 won't work well with older macs, G4's, PPCs, etc and crashes many times on such hardware while not supporting "Classic" (OS9).

And while 5.2 is being mentioned, list what you're hoping to see in 5.2:

I was hoping particles would appear soon, along with the new pose Tag.
 
10.5 works just fine on older Macs -- assuming it will install on them. (I think you need an 867MHz G4 or better.) If anything, it runs faster than Tiger. The big change is Apple ditching Classic. You could always go dual boot for those occasions when you need classic -- boot into Classic proper.

I'm still unclear on all the advantages of Cheetah supporting 64 bits versus 32?
Click to expand...

The key advantage is more memory (if available). With 32-bit you're essentially limited to 3GB per application. I doubt most C3D users bump into this issue too often.

Other advantages are speed (e.g. the webkit JavaScript engine is notably faster in 64-bit, and C3D uses it for executing scripts) and "cleanliness" -- Apple is heading for all 64-bit pretty aggressively both in terms of its own apps and in its APIs.

Moving forward -- Grand Central Dispatch is going to be pretty important for 3d. Intel is currently talking about 40-80 CPU architectures in its pipeline.
 
64-bit code has access to more and larger cpu-registers.

I think even the FPU works as a normal register-based FPU in 64-bit mode. (x86-32 FPU is stack-based)

It could very well lead to a substantial performance increase for the rendering.
 
Yeah, the IA32 architecture is horrible, and AMD's 64-bit approach* was much saner, which makes coding at low level in 64-bit a huge advantage (the same thing isn't true on the PowerPC-side... so 64-bit won't offer the same performance advantage for PPC folk as for Intel -- PPC chips have had tons of registers and been 64-bit internally since day one).

Note that SSE3 or whatever is -- I think -- the same for 32- and 64-bit CPUs so I'm not sure you'll get as big an advantage as you might hope, given that a lot of math will get piped through here.

* Intel ignored 64-bit for the x86 platform and instead developed "Itanium" (which has turned out to be Intel's Copland), meanwhile AMD produced a 64-bit architecture that was backwards compatible with the x86 (AMD's chips are essentially RISC chips that pretend to be x86s in 32-bit mode), and when these started making Intel look silly, Intel essentially adopted AMD's standard. Ironic, huh?
 
Last edited:
Hi,
I just want to mention that 5.2 won't be 64bit. But it will make internally a hugh step into that direction.

Cheetah3D 5.1 also doesn't use the webkit javascript engine yet. It uses a quite old spidermonkey javascript engine. But I'm currently in the process to replace it with the Javascriptcore (Webkit) javascript engine with it up to date with a nice JIT compiler.

Today I would say 30% of the bug reports I get are caused by out of memory bugs. So it is a very very serious problem today. Especially the latest macs which already come with 4 or 8 GByte of ram have no problem to surpass the 3 GByte limit. Since they are fast enough to handle such scenes. With a G4 or G5 you probably won't reach that limit since the CPU is to slow to work efficiently with such big scenes.

So the 64bit with is solely because of that crashes the most important feature on my todo list.

Last but not least does most rendere run 10-50% faster in 64bit mode and I hope that Cheetah3D will see a similar speed gain in 64bit. So I'm quite curious for the 64bit compile by myself.:smile:

Bye,
Martin
 
Martin said:
Hi,
Today I would say 30% of the bug reports I get are caused by out of memory bugs. So it is a very very serious problem today.
Click to expand...

It depends on if the crashes are due to legit use of memory. A run-away allocation bug in some Javascript would only last longer if more memory was available.

I hope you mean that the WebKit JS engine has a smarter GC that will collect cyclic memory references. :)

So there are actually people doing such big projects that several gigabytes are needed to work and render it? Cool.
 
podperson said:
10.5 works just fine on older Macs -- assuming it will install on them. (I think you need an 867MHz G4 or better.) If anything, it runs faster than Tiger. The big change is Apple ditching Classic. You could always go dual boot for those occasions when you need classic -- boot into Classic proper.



The key advantage is more memory (if available). With 32-bit you're essentially limited to 3GB per application. I doubt most C3D users bump into this issue too often.

Other advantages are speed (e.g. the webkit JavaScript engine is notably faster in 64-bit, and C3D uses it for executing scripts) and "cleanliness" -- Apple is heading for all 64-bit pretty aggressively both in terms of its own apps and in its APIs.

Moving forward -- Grand Central Dispatch is going to be pretty important for 3d. Intel is currently talking about 40-80 CPU architectures in its pipeline.
Click to expand...

Thanks Podperson. I have 1.2 Ghz up from the originally painful 400 Mhz, but that's the fastest I think it'll go. Will consider 10.5 depending when Cheetah goes 64 bit exclusive, but will put it off as long as possible.

Martin said:
Hi,
I just want to mention that 5.2 won't be 64bit. But it will make internally a hugh step into that direction.

Cheetah3D 5.1 also doesn't use the webkit javascript engine yet. It uses a quite old spidermonkey javascript engine. But I'm currently in the process to replace it with the Javascriptcore (Webkit) javascript engine with it up to date with a nice JIT compiler.

Today I would say 30% of the bug reports I get are caused by out of memory bugs. So it is a very very serious problem today. Especially the latest macs which already come with 4 or 8 GByte of ram have no problem to surpass the 3 GByte limit. Since they are fast enough to handle such scenes. With a G4 or G5 you probably won't reach that limit since the CPU is to slow to work efficiently with such big scenes.

So the 64bit with is solely because of that crashes the most important feature on my todo list.

Last but not least does most rendere run 10-50% faster in 64bit mode and I hope that Cheetah3D will see a similar speed gain in 64bit. So I'm quite curious for the 64bit compile by myself.:smile:

Bye,
Martin
Click to expand...

Thanks for that update on 5.2. I'm relieved to hear I may still be able to use it in Tiger for at least 5.2. Before you move onto 64 bits, my only wish (besides particles), is:
1. Pose Tag feature for Tiger and up. (ability to copy/paste pose tag too)
2. If possible, the copy/paste keyframes feature.
3. Would be the mirror pose feature Podperson mentioned elsewhere.

If those features could be squeezed into before Cheetah goes 64 bits, that would be awesome :icon_thumbup::icon_thumbup:; those features would definitely make a huge difference for what I'm working on using Cheetah. Thanks Martin.
 
podperson said:
Yeah, the IA32 architecture is horrible, and AMD's 64-bit approach* was much saner, which makes coding at low level in 64-bit a huge advantage (the same thing isn't true on the PowerPC-side... so 64-bit won't offer the same performance advantage for PPC folk as for Intel -- PPC chips have had tons of registers and been 64-bit internally since day one).

Note that SSE3 or whatever is -- I think -- the same for 32- and 64-bit CPUs so I'm not sure you'll get as big an advantage as you might hope, given that a lot of math will get piped through here.

* Intel ignored 64-bit for the x86 platform and instead developed "Itanium" (which has turned out to be Intel's Copland), meanwhile AMD produced a 64-bit architecture that was backwards compatible with the x86 (AMD's chips are essentially RISC chips that pretend to be x86s in 32-bit mode), and when these started making Intel look silly, Intel essentially adopted AMD's standard. Ironic, huh?
Click to expand...

Pod,

whilst I am aware that it is a simplistic question, do you believe that PPC architecture is "better" than Intel architecture ?
 
You must log in or register to reply here.
Back
Top