PDA

View Full Version : 64 bit



Tony3d
05-02-2005, 06:23 AM
Is the current release of Lightwave on the Mac 64 bit? If not, will Newtek develop one?

Lightwolf
05-02-2005, 07:13 AM
It isn't and it (practically) can't be on Tiger:
http://vbulletin.newtek.com/showthread.php?t=36295

Cheers,
Mike

marble_sheep
05-02-2005, 07:46 AM
It isn't and it (practically) can't be on Tiger:
http://vbulletin.newtek.com/showthread.php?t=36295

Cheers,
Mike

pssshhh... THAT thread has pretty much degraded into the age-old "mac-vs-pc" debate. lame. :rolleyes:

anyway... the short answer to your question... no it is not, and it won't be until Apple commits to a fully 64-bit os. which will probably take a while because they would run into many of the same issues and kicking/screaming that they encountered during the os 9 - os X transition.

Tony3d
05-02-2005, 07:49 AM
That's extremely disapointing.

marble_sheep
05-02-2005, 07:59 AM
That's extremely disapointing.

I agree. I think it's disappointing on both sides... it's disappointing that apple does not have two versions of OS X (the current one, then maybe a "pro" level 64-bit one) and it's disappointing that Lightwave does not take advantage of the 64-bit elements that are already in place. Heck, they don't even take advantage of many of the underlying technologies that make OS X so great. But... as has been discussed ad infinitum, that would require lots and lots of code changes... a big task.

Scazzino
05-02-2005, 08:37 AM
In Tiger, NewTek could develop a 64 bit LWSN renderer that could be used as a full 64 bit back-end rendering process that communicated to the front end GUI process...

-MikeS

Lightwolf
05-02-2005, 08:59 AM
In Tiger, NewTek could develop a 64 bit LWSN renderer that could be used as a full 64 bit back-end rendering process that communicated to the front end GUI process...

...but how would you create scenes that use more than 4GB in assets?

Cheers,
Mike

Scazzino
05-02-2005, 10:17 AM
The 32 bit front end and the 64 bit back end can communicate through a variety of ways... One possibility would be to have the 64 bit back end handle the entire scene and write to an image buffer in shared memory where the 32 bit front end could access it to draw into the 3D GUI viewport... Then the 32 bit front end would handle communicating with the user and pass the user's commands to the 64 bit back end for manipulating the scene...

Here's some more info...
http://developer.apple.com/macosx/64bit.html
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/index.html

Or, they could even remain with the existing 32 bit code but adjust it to use this clever VM workaround where the application uses 4GB address space, but lets Mac OS X actually keep much more available in RAM and access it through virtual memory without going to disk...
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/indications/chapter_2_section_3.html

But in the end, even if they don't allow over 4GB of scene assets for the scene itself in the GUI, using a 64 bit background render process would allow much more than 4GB for use during rendering, where the RAM use normally skyrockets anyway...

Just some thoughts...

-MikeS

Lightwolf
05-02-2005, 10:32 AM
The 32 bit front end and the 64 bit back end can communicate through a variety of ways... One possibility would be to have the 64 bit back end handle the entire scene and write to an image buffer in shared memory where the 32 bit front end could access it to draw into the 3D GUI viewport... Then the 32 bit front end would handle communicating with the user and pass the user's commands to the 64 bit back end for manipulating the scene...
How can the backend write an image buffer for the frontend to display if it ca't access openGL? Do you suggest NT should write a software based display renderer as well, just because Apple screwed up? ;)
Of course, the 64bit back end could pass over chunk after chunk of geometric and texture data over to the 32bit front end to immediately display using openGL and then discard. Hm, four viewports, displayed one after the other (since you should finish one openGL context before you render into the next one). And for every viewport the backend has to pass on gigabytes of data to the frontend? (After all, we're talking about the huge stuff that needs 64bit).

As for your other suggestion:
"To do this, instead of referring to data using pointers, you use a data structure that contains a reference to a file and an offset into that file."

Great, that meas that NT would have to re-write just about all of their memory handling code. I donn't think that is an option either...
BTW, W2K had a clever workaround like that as well to use up to 32GB of Ram from 32bit code... Hardly anybody used it. (Certainly not NT).

I do see a 64bit render node once NT finished the transition to XCode... but a hook up to a 32bit front end would be a waste of time and money (imho). I bet Apple is getting so much flak about their so called 64bit OS that the next version will have full 64bit support anyhow. So why hold up ressources that are needed in other areas of LW to cludge something in that will be obsolete with the next OSX anyhow?

Cheers,
Mike

Scazzino
05-02-2005, 10:47 AM
Those "options" were to "your" question about a scene with over 4GB of assets... which was not what I was initially suggesting at all...

I was suggesting to rewrite LWSN, as a 64 bit renderer (which you'd need to do anyway once going full 64 bit in the future) that could communicate with the 32 bit front end (as LWSN does now, nothing more than that as far as "hookup")... This would NOT allow over 4GB of scene assets to be used in the GUI or the OpenGL... but it WOULD however allow using well over 4GB of RAM for rendering, which would normally be the first place one would bump up against the typical 4GB RAM limit... ;-)

-MikeS

Lightwolf
05-02-2005, 10:56 AM
Hi Mike

Those "options" were to "your" question about a scene with over 4GB of assets... which was not what I was initially suggesting at all...

I'm quite aware of that... But having those assets within the GUI portion of the app is what counts to a large degree imho.


I was suggesting to rewrite LWSN, as a 64 bit renderer (which you'd need to do anyway once going full 64 bit in the future) that could communicate with the 32 bit front end... This would NOT allow over 4GB of scene assets to be used in the GUI or the OpenGL... but it WOULD however allow using well over 4GB of RAM for rendering, which would normally be the first place one would bump up against the typical 4GB RAM limit... ;-)
-MikeS
Only for huge images outputs or a very high number of SubDs. It would however mean that the strategy LW uses for preview renders would have to change a lot (read: change in architecture), in which case I wonder again if it wouldn't make more sense to introduce a smarter, less brute force, change in architecture to solve those problems in the first place (tile based rendering comes to mind here).
After all, many of the challenges we face with the 32bit limit, especially when rendering, are to a large extent not present on other rendering systems (that have instancig during rendering as well, allow you to keep textures on disk, render print res in tiles/stripes, do micropolygon displacements at runtime within tiles etc...).

And, to be quite honest, if people complain about the Hub already... I can already hear them about a Layout/LWSN connection that is very likely to be flaky at first as well... and will then be stable once Apple brings out the next OS ;)

Cheers,
Mike

Scazzino
05-02-2005, 11:19 AM
It would however mean that the strategy LW uses for preview renders would have to change a lot (read: change in architecture)

Not really, there could be a user pref to enable a 64-bit LWSN to take over F9 and F10 renders or not. Then if enabled, LW would simply submit it as a 64-bit LWSN batch job, and display the result... otherwise it would just render it as it does now internally... No major architectural changes would be needed... ;-)

This type of communication wouldn't be any worse than the current built-in screamernet controller for LWSN...

I'm not saying that this would be a perfect solution, or even an end solution... but it could be a first step toward 64-bit on the Mac. A 64-bit LWSN first, then a full blown 64-bit GUI app when the underlying OS can support it...

Currently, if you did have a scene with close to 4GB of assets, there would be no RAM left to render it... this would at least allow users who need such high assets to get much closer to the 4GB limit within LW and then blow by it when rendering with a 64-bit LWSN...

Or we could all just sit here and wring our hands about how Apple dropped the 64-bit ball... ;-)

-MikeS

harlan
05-02-2005, 02:34 PM
Well actually there is a lot of misinformation going on in the world of 64-bit computing. The need and usage of 64-bit computing varies dramatically between the PowerPC & x86 architectures.

On the x86 architecture, the number of registers & the width of registers change between 32bit & 64bit modes - resulting in two entirely different math & data structures. PowerPC architecture was always designed around 64bit wide registers. Until the Panther & Tiger OSes on the PowerPC platform, the ability to access the full 64bit functionality of the PowerPC architecture wasn't allowed. Under Tiger, a 32bit application has the exact same address & arithmetic functionality as a 64bit application.

A 32bit application on Tiger, written to take advantage of the 64bit address space (mmap, malloc, etc...) will have the same functionality as a "native" 64bit application on the PowerPC platform, and in many cases will actually be faster than the native 64bit application.

That being said, "native" 64bit applications under Tiger, have full 64bit capabilities - the one exception being the GUI code (as it's currently 32bit). As indicated above however, a 32bit GUI can still address the same memory (etc...) as a 64bit application. Why then is the GUI still only 32bit? Tiger gives you the ability to utilize the exact same functionality in 32bit as you would have in 64bit, thus reducing the need to re-code an entire application to 64bit. The PowerPC architecture allows for this, whereas the x86 architecture requires a 32bit emulator in order to run 32bit code, as the registers and arithmetic are completely different between 32bit & 64bit on x86.

LW under Tiger, properly coded to take advantage of the PowerPC architecture, would address the same amount of memory as a 64bit version of LW on the x86 platform. LW's renderer could certainly take advantage of "native" 64bit code on both platforms, but the need to have LW's GUI functionality in 64bit on the PowerPC is completely unnecessary as you wouldn't really stand to gain anything.

LW's focus on optimizing for the Mac platform, in my opinion, should involve:

1. Optimizing of the main applications to take advantage of the 64bit functionality offered by the PowerPC architecture under 32bit code.

2. Make the render engine a "native" 64bit application.

3. Take advantage of Tiger's CoreData. Most of the work involved in CoreData exists directly in the OS; so the application itself only has to go through minor modifications to utilize it.

anyways... people should really read up on the 64bit functionality of both platforms before implying something about the PowerPC architecture based on x86 knowledge. They operate entirely different from each other.

Lynx3d
05-03-2005, 05:53 AM
Well actually there is a lot of misinformation going on in the world of 64-bit computing. The need and usage of 64-bit computing varies dramatically between the PowerPC & x86 architectures.

I agree, but one of us both must be a bit wrong on the abilities of 32bit binaries...


A 32bit application on Tiger, written to take advantage of the 64bit address space (mmap, malloc, etc...) will have the same functionality as a "native" 64bit application on the PowerPC platform, and in many cases will actually be faster than the native 64bit application.

...how so? Isn't malloc part of libc which is part of libSystem? If you want a 64bit malloc you need to use 64bit libSystem, wich means you are creating a 64bit application and cannot use any 32bit library, which means not any other OS X library at all because libSystem is the only 64bit one in Tiger so far.

It's true that (since Panther AFAIK), 32bit applications may use 64bit registers and instructions to modify their data, i.e. do 64bit arithmetic. But they are limited to 32bit address space (that's the definition of 32bit binaries after all, unless i misunderstood about every technical artice out there).
That means, 32bit processes could compute 64bit addresses, but cannot use them to access memory, because the kernel only provides a 32bit address space.
So you have to somehow juggle with several junks of 4GB manually (could be a mess...), or do IPC with a 64bit "worker process" as Apple recommends.

About performance: Since 64bit words use more cache and bandwidth than 32bit words 32bit binaries tend to be faster obviously, opposed to x86 where the availability of another 8 registered often more than outweighs that, or the ability to perform 64bit integer arithmetic, also caches of 1MB or even 2MB come in handy. But all that doesn't help the 32bit PPC binaries to be superiour to 64bit ones if they need more than 4GB RAM...

harlan
05-03-2005, 11:16 PM
Well you're probably right, I'm not the worlds most knowledgable computer guy by any means. My understanding was really based on developer documents that I was reading on 64bit Development for PowerPC and some for the x86 architecture.

The Kernel in 10.4 allows the application to use as much memory as availble in the computer as it uses the long long data types to map the memory. Since the Kernel itself never needs to access more than 4GB of memory, it doesn't really need to be 64bit - as long as it can pass the long long data types (which it apparently does).

Scazzino
05-06-2005, 10:53 AM
Here are some benchmarks for VectorWorks... They mention 64-bit but it doesn't look like they are particularly testing "64-bit" per se (ie 64-bit address space), rather than simply the G5 verses the G4 and Intel processors for pure speed, particularly floating point ops...

Apple G5: Smokes Intel Competition (http://www.architosh.com/features/2004/g5-interview/2004-interv-g5nem-1.phtml)

-MikeS