By Beam Tracer (Beamtracer) (203.109.241.109) on Wednesday, January 01, 2003 - 06:06 am:

Despite Apple not commenting on future product releases, we can be sure they're going to be making machines running on the new 64-bit IBM970 processor. Apple has test versions running in the lab, and a release date should be around mid-2003.

While Windows users of Lightwave are getting excited about future 64-bit processors to come from AMD, my question to Newtek is: Will Lightwave will be ready to run on a 64-bit Macintosh platform?

My question comes from a recent post by Arnie addressing the issue of Lightwave64 on Microsoft Windows:
"The 64-bit LW should be called LW for Win64, since it won't work on a 64-bit unix/linux, but it will work on whatever boxes run Win64. If Win64 becomes a viable platform, LW will be ready for it."

I think the response was phrased purely for the Windows users who were involved in the thread, which is fair enough. I just wanted some clarification on how this relates to Mac OSX, being in the UNIX category.

Is there any extra difficulty in creating Lightwave64 for the Mac than there is the Windows version? Will it be available if Apple released 64-bit IBM processors mid-year?

By ingo (Ingo) (62.109.71.29) on Wednesday, January 01, 2003 - 06:15 am:

Well first, the prozessors are not build into Macs yet, and second i have no clue what advantage a 64Bit system should give us. But lets just wait and see what happens the next days at the MacWorld expo in SF.

By ted devlin (Eblue) (68.46.132.42) on Wednesday, January 01, 2003 - 11:25 am:

my interpretation of arnie's quote, is that what he said there has zero bearing on any possible os x 64 lightwave....

and i would like to further point out that while mac os X does contain Unix, it is Not in fact: "in the UNIX category" for most programmers

and what can you seriously ask of Newtek in this area, when Apple isn't talking about it. There are no documents that an average developer can get his hands on, that explain what can be done to ensure compatibility, let alone efficient usage of such a processor.

I'm sure when 64 bit processors become available on the mac, and apple releases some very important information about them, Newtek will evaluate its position regarding it.
so just keep all that 64bit chat energy stored up till then ok?

By Beam Tracer (Beamtracer) (203.109.241.109) on Wednesday, January 01, 2003 - 03:01 pm:

I thought that Arnie's quote probably doesn't impact on Mac OSX, but just wanted that clarification.

On the Windows side, Microsoft also hasn't officially announced any 64-bit OS either, yet we're already getting some software developers declaring their support for it (Canopus for example.) I don't expect Newtek to discuss details about future products that aren't here yet, except that there was already a declaration that Newtek will be ready when a 64-bit Windows is released and viable. While Apple hasn't yet released any development docs, the question could be answered in a theoretical manner as it was for Windows users.

OK, Mac users: Put up your hand if you're currently running Mac OS X with 2 gigs of RAM. There are quite a lot of you. Macs have been able to handle this amount of RAM for the last 3 years, so I think there are more people on the Mac side maxed out with RAM than on Windows. Lightwave runs better with this amount of RAM.

Well there's only one more step to go... one more doubling of RAM (which doesn't take long in computer years) before we've reached the maximum amount possible under 32-bit systems. It was 6 or so years ago that personal computers were being sold with only 8MB of RAM!!!

When the MacWorld expo happens next week there will not be 64-bit processors released, however it's likely to happen at the mid year Macworld in New York or Boston. It won't be long before Apple releases machines capable of running 4 gigs of RAM, and then we've hit the RAM ceiling.

By ingo (Ingo) (62.109.114.120) on Thursday, January 02, 2003 - 03:22 am:

Aren't the actual Macs capable of running with 4 GB RAM, i see no reason why they shouldn't, despite the horrible RAM prices.

By Jason Hillon (Tumblemonster) (24.245.0.34) on Friday, January 03, 2003 - 03:10 am:

As for the advantage of a 64 bit, it's basically a bigger pipeline. You can therefore push more data/cycle through a 64 bit pipeline than you can through a 32 bit pipe.

Since it's obvious that Apple is taking it's time bridging the megahertz gap, every little advantage helps. Powermac processors are generally faster per mhz already. A bigger pipeline will just solidify that.

By Jason Hillon (Tumblemonster) (24.245.0.34) on Friday, January 03, 2003 - 03:10 am:

As for the advantage of a 64 bit, it's basically a bigger pipeline. You can therefore push more data per cycle through a 64 bit pipeline than you can through a 32 bit pipe.

Since it's obvious that Apple is taking it's time bridging the megahertz gap, every little advantage helps. Powermac processors are generally faster per mhz already. A bigger pipeline will just solidify that.

By Beam Tracer (Beamtracer) (203.109.241.109) on Friday, January 03, 2003 - 03:24 am:

Pushing more data through in 64-bit chunks may help some applications and not others. I would have thought that an app like Lightwave would be one of those which would benefit speedwise, but others question this.

As for longer date pipelines, they actually decrease processor efficiency per clock cycle, purely to get a higher megahertz rating for marketing reasons. Intel started this absurdity, and unfortunately the other consumer processors (including the IBM-970) are following.

Companies such as SUN and SGI make high-end processors with low megahertz clock cycles.

By Michael Fessenden (Mfessenden) (63.89.65.110) on Friday, January 03, 2003 - 09:37 am:

The Mhz rating really isn't the only thing to consider when looking at the relative speed of two machines. Intel P4's may run up into the 2+Ghz speeds, but there is also the bus speed which is a huge factor in the overall speed of the machine.

I think that PC boards run about 2ooMhz (don't quote me on that) and the CPU speed is based on that (so a 2Ghz P4 is chewing through about 10 instructions for every cycle the board makes) The initial PPC 970 is rated at 1.8Ghz, but the bus speed is spec'd at 900Mhz!! That right there should make it considerably faster than a 2Ghz P4...never mind the fact that the 970 is also a 64 bit chip...

Mac bus speeds have always lagged behind PC board speeds. I think that the present generation of Mac boards finally got us up to 167Mhz, which is slow in comparison to current PC offerings.

By Arnie Cachelin (Arnie) (65.184.20.249) on Friday, January 03, 2003 - 11:08 am:

Among the points my statement wanted to make was this most important one: LW, since v6.5, has a "64-bit clean" codebase. This means that the issues involving shipping a version for some given 64-bit OS and HW combination are primarily in the existence of a compiler to generate the app., and then the existence of a market of users willing to buy such an app. I am not convinced that 64-bit processing will bring that much to the performance table. It will require some extra memory to do the same things, and a large number of processes and calculations will not benefit from, and may be slowed down by the doubled size of the basic element. It will be interesting to see how it all shakes out.

By Beam Tracer (Beamtracer) (203.109.241.109) on Friday, January 03, 2003 - 04:02 pm:

Thanks Arnie. I gather that means the "common code base" from which Lightwave is created (before it is ported to Windows and OSX) is 64-bit compliant, but it would still require some effort on Newtek's part to create a workable version for the Mac, or any other hardware platform.

I see the 2 big advantages for going 64-bit to be:
1. Memory (to have 4gig+ RAM)
2. Marketing

As I said on another post, the 2 gigs of RAM that many OS X users are running Lightwave on would have been considered an outrageous amount of RAM a couple of years ago, but now it is quite common. It really won't take long to hit the 4gig RAM ceiling.

Marketing is a big issue. You can see from forums there is a lot of excitement about coming processors and I think when people purchase the new 64-bit consumer CPUs they'll want to run 64-bit apps on them.

It's an even bigger advantage for Newtek if competitors don't go 64-bit. I wondered whether the fact that Newtek previously supported the Digital Alpha processor makes it any easier to create new 64-bit versions of Lightwave? If so, it would make it harder for a competitor like Discreet to follow.

By ingo (Ingo) (62.109.70.73) on Saturday, January 04, 2003 - 05:12 am:

Well Beam, so why dont you buy one or more of that cheap 2000$ 1GB RAM's ?

By Beam Tracer (Beamtracer) (203.109.241.109) on Saturday, January 04, 2003 - 04:25 pm:

By Ed Mag (Ed_M) (205.188.208.43) on Saturday, January 04, 2003 - 06:38 pm:

[[[my interpretation of arnie's quote, is that what he said there has zero bearing on any possible os x 64 lightwave.... ]]]

My thoughts exactly.

[[[and what can you seriously ask of Newtek in this area, when Apple isn't talking about it. ]]]

That's true...

[[[There are no documents that an average developer can get his hands on, that explain what can be done to ensure compatibility, let alone efficient usage of such a processor. ]]]

True... Lord knows I've been scouring the net.

[[[so just keep all that 64bit chat energy stored up till then ok?]]]

That's a good idea. However, there have been a few things of interest that I came across while looking into that a while back over the early part of last year... I don't know how many of the links are broken now though...

[[[ Yves,I would like to encourage you as the autoconf-meister to check for differences and make updates and post improvements as you see fit - for as long as ICU keeps working :-)You really know most about this part!markusYves Arrouye wrote:> Autoconf 2.50 is out. I was thinking that maybe they have updated> config.{sub,guess} and other things that would benefit ICU. I also see that> ICU's config.{sub,guess} sport IBM copyright notices, so I guess they've> been changed. I am actually sure of that, having done the change for Mac OS> X myself.> > Have all the changes been forwarded to the upstream Autoconf maintainers> ? If so, it would be nice to update in order to be able to> autoconf on more platforms. If not, well, maybe we should adapt 2.50 and> send diffs?

taken from here:
http://oss.software.ibm.com/pipermail/icu/2001-May/002949.html


VERY INTERESTING:
http://oss.software.ibm.com/pipermail/icu/2001-May/thread.html

http://www.osdata.com/oses/macosx.htm

I just happened by this little tidbit...

http://www.darwinfo.org/lists/darwin-development/current/3050.html



[[[As for executables compiled for a 64bit memory model, the impactof using 64bits pointers depends a lot on the program. For exampleif we assume that most of Photoshop CPU usage is in processing imagedata, compiling Photoshop for a 64-bit memory model will be aboutas fast as compiling it for a 32bit model using the 64bit registersand arguably quite a bit faster than a pure 32bit version.(this does not take Altivec into account) ]]]



and this:

[[[If I'm reading this right, PPC uses a 16 bit offset from a register to
determine the load/store address. That would mean that the instructions
don't change, nor do their operands when you go from 32 to 64 bit. Only
the data in the registers differs, which would be controlled by whether
you loaded a pointer using a load word or load double word. .... cont. ]]]

found here:

http://www.darwinfo.org/devlist.php3?number=4634

Interesting stuff.....

Anyway, what got me thinking was this bit of info:

[[[Mac OS X, a 64-bit OS, will have the unique ability to run Classic 32-bit Mac OS applications at native speeds—all transparently! Mac OS X will also offer the most advanced Java 2 support. ]]]

http://www.architosh.com/edutainment/macosx/index.phtml

And......

Get this:
http://www.osdata.com/oses/macosx.htm

http://www.osdata.com/system/physical/physical.htm#numbits

[[[Mac OS X is fully 64-bit ready, supports more processors in workstations (up to 4) and takes advantage of them with vector processing via AltiVec processing units. ]]]

http://www.architosh.com/edutainment/macosx/index.phtml

--
Ed

By ted devlin (Eblue) (12.149.3.2) on Monday, January 06, 2003 - 11:47 am:

ed,
it seems at first that you are agreeing with me, but you're not are you? ;)

in a nut shell:
since other platforms are already 64 bit, there is some common knowledge about dealing with it. Allowing for rampant speculation. And it doesn't help that the core of MacOSX is essentially platform/processor agnostic, allowing such feats as Marklar, and 64 bit readiness. But the practical application of a 64 bit Mac os X has not surfaced. There is no such processor, nor a market that can support it. Apple learned well the lesson taught by Lisa, do not make a product that is sufficiently advanced as to be difficult to make, and too expensive to sell. And lets not forget about the all too recent major upheaval of mac os developers. Most of them are still a little sore from the rape due to the last major "change" to the venerable os. Another one so soon after the last would get the cold shoulder for sure.

ed, the info you found, amounts to speculation, and is exactly what i am cautioning against. Alot of it is interesting, but out of context. Its quite possible to turn out a 64 bit version of os X in a few days, we call that version: Darwin. Everything else would have to be re-written, or tuned, before it would work at 64 bit. And here is the most important thing you should take with you, from this post... 3d rendering would not likely benefit much from 64 bit tuning. its an issue of bang over buck. We have rendering code for a processor now, that could quite possibly benefit from some tweaking and tuning, and all of a sudden everybody starts talking about a processor that doesn't exist, doesn't have any support, and may not ever. Now we have the developers pledging vague support for a future widget that has no documentation, and could simply supersede current hardware, we in effect lessen the perceived user importance of making the product work best with current hardware, and undermine the work that should be done Before the release of a 64 bit processor.

In short this thread is a nag ;)

By Beam Tracer (Beamtracer) (203.109.241.109) on Monday, January 06, 2003 - 03:00 pm:

I don't know if it's such a sin to speculate. It alerts everyone to the issue, and gets everyone thinking about it.

The practical application of 64-bit processing with Lightwave has surfaced. RAM. Look at the history of RAM usage, and the rate of increase in RAM over the years for the typical Lightwave user, and you'll see that we will need 4gigs+ of RAM in the near future. It has to happen, even if you currently don't feel you'll ever need more RAM than what you've got now.

The transition from OS9 to OS X was an "upheaval" for developers, though I think the word "rape" is not appropriate in this context. Newtek was one of the first to embrace OS X which was a good move, and that transition was almost 3 years ago.

I don't think it would take a whole rewrite for Newtek to get Lightwave running in 64-bit mode in Lightwave. I don't think any app needs a major proportion of its code rewritten, and Arnie has stated that Lightwave's 'common code base' is already "64-bit clean".

Despite the fact that Apple won't ever make announcements about future products, anyone who doesn't believe that Apple's roadmap includes the IBM970 has their head in the sand. The optimization we need for the current G4 processor is more Altivec utilization. With Altivec support included in the 970 processor, developers can be satisfied that their efforts to optimize for the G4 will also be valid for the next generation of processors.

By Daryl Cornutt (Dfc) (24.90.251.91) on Monday, January 06, 2003 - 08:06 pm:

Wasn't the old DEC "Alpha" version of LW 64bit?

I think, if I remember right...the Alphas were turning out the fastest render.etc..times of any other platform on Lightwave.

And like I said..I believe it was a 64bit cpu if I'm not mistaken.

By ~@~ (Phong) (66.52.181.74) on Monday, January 06, 2003 - 10:55 pm:

> Wasn't the old DEC "Alpha" version of LW 64bit?

NO... because, WIN-NT, was 32bit.

OSF/DU/etc. were 64bit... later, Linux & ~BSD were 64bit.

(imo) The Alpha's floating point helped with rendering.

YES... the DEC Alpha was a 64bit machine (smile) with a nice bus.

Developers who received Beta 3 are the only ones who ended up with a 64bit WIN-NT5 renamed WIN2000.

By Daryl Cornutt (Dfc) (24.90.251.91) on Tuesday, January 07, 2003 - 05:42 am:

Ah...that explains it Phong.

Thanks.

By Beam Tracer (Beamtracer) (203.109.241.109) on Tuesday, January 07, 2003 - 07:58 am:

So how did Microsoft's 32-bit OS run on the 64-bit Alpha processor?

By Will Rosecrans (Forkazoo) (172.193.1.95) on Saturday, January 11, 2003 - 11:35 pm:

Simple. It just didn't use the extra bits for the pointers.

Interestingly, the Alpha is especially suited to running random odd OS's, because it is both bi-endian, and somewhat bittedly agnostic. I guess this comes at least in part from the VAX heritage. (Alpha was basically designed to be the 64 bit replacement for the 32 bit VAXen, so it needed to be able to deal with 32 bit apps.) As for why the beast is bi-endian, I have no idea. It really isn't that important.

Alpha is dead. Long live Alpha.

By Beam Tracer (Beamtracer) (203.109.241.109) on Sunday, January 12, 2003 - 04:21 am:

The best usually doesn't win! It's a pity about the Alpha. Why do people drift towards the Microsoft/Intel duopoly? Linux on Alpha would have been a fine alternative.

My understanding is that the 'endian' order (I believe that is whether the byte order starts from the little or big end) is the most difficult issue that Apple faces if they ever wanted to distribute a version of OSX running on AMD processors. Apps would have to be compiled in the other 'endian' order. Someone with more programming experience may want to correct me there.

By Daryl Cornutt (Dfc) (24.90.251.91) on Monday, January 13, 2003 - 01:41 pm:

Hmm, some interesting asides,

If I remember this right, certain engineers were working on VAX OS, and actually had a 64bit cpu to play with_although I'm not sure this was the alpha cpu?.(I believe the time line was late 70s, or 1980). They were working on 64bit version of VAX OS for this cpu. The company (sorry don't remember the name) sort of dumped on the project and the top engineer for VAX was hired out fromunder them by ...gulp..Bill Gates for MS. This engineer brought much of the engineering talent over with him.

somewhere in this timeline, MS was still in realtionships with IBM (OS2). They released their first "Windows" and IBM was NOT happy about it. (neither was apple for obvious reasons).

Bill had the VAX team working on NT kernel and the kernel for it was such a copy of the VAX kernel, that they got sued. This was settled out of court for an undisclosed amount of money (but seemed to imply it was a LOT of money).

VAX kernel at 64bits did exist at the time MS had hire the team. I guess there are any number of reasons they didn't impliment it this way that make plenty of business sense.

But, just wanted to make the point, that WinNT kernel and VAX kernel are very close cousins! Incestously so...to the point that MS got sued over it. And basically, the first NT was a marriage between a fairly close copy of the VAX kernel and windows 3.1. And that at the time this occured..there was a 64bit version of VAX floating about. And..that the engineers responsible for this 64bit version of VAX..were all working at MS.

That is, if i'm remembering all this right?

Been a while.

By Michael Linde (Mlinde) (4.64.205.42) on Tuesday, January 14, 2003 - 11:18 am:

I may be wrong here, but I had an acquaintence who was a tech at Digital when they were still about, and I think there was a specific version of NT made for the Alpha processors.

In fact, I'm positive there was a special version for the Alpha. Whether it was 32- or 64- I don't know, but much like the PowerPC version of NT, it existed, on it's own CD in the MS Developer's Kit in the mid-90s. The trick of course is, that MS may not have provided the Alpha version of NT to anyone other than Digital, or Digital may have developed it FOR MS. I can't find out now, since the guy I knew was gone shortly after DEC became a Compaq subsidiary...

By Will Rosecrans (Forkazoo) (172.195.105.26) on Friday, January 17, 2003 - 12:45 pm:

Hey, Daryl -- your timeline is pretty off. An interesting aside, but I think you may be slightly mis remembering the order of events, so I want to try and clarify a bit...

having glanced at:
http://www.levenez.com/unix/history.html
http://research.microsoft.com/~gbell/Digital/timeline/tmlnhome.htm

and
http://www.levenez.com/windows/history.html

for quick reference...

First off, nobody had a 64 CPU in the 70's, AFAIK. IBM S/370 was only a 24 bit machine at that point. I don't know when the first 64 bit machine appeared, but it was rather recent. Anyway, the first VAX didn't even ship until 1977. Alpha was announced in 1992. Presumably, there was some work going on prior to the announcement, but probably nothing going as farback as the 80's.

Windows 1.0 was announced toward the end of 83, and appeared in late 85. The first OS/2 didn't appear until 1987.
So, to be clear, MS was working on Windows before the OS/2 project started, and well before DEC had a 64 follow on to VAX.

Windows NT was first announced in 1991, after MS acquired Dave Cutler. (I think that was his name, but I can't recall for sure. He had a name something like that.) Cutler was indeed anti-UNIX and a lot of WinNT is "spiritually decended" from VMS. Given the time frame, it does seem quite possible that the VMS people that MS brought on board were working on what would eventually become the 64 bit Alpha.

But, the reasons that MS didn't make WinNT 64 bits are multifold. First off, WinNT 3.1 only ran on Intel CPU's. It wouldn't have made any sense to try making a 64 bit clean system at that point for a 32 bit chip. Second, up to that point Windows was only 16 bit. The project's stated goal at the outset was to make a modern 32 bit OS. 64 bit just hadn't entered anybody's mind yet.

I wasn't until NT4 that NT ran on many architectures, some of which were 64 bit. (1996) Since, at this point, the Win32 architecture was somewhat established, and the systems that Windows was targeting didn't have enough RAM for it to matter, nobody really cared that Windows stayed 32 bit. Who had 4 Gigs of RAM on their workstations in 1996? Nobody. The real importance of 64 bits at that point was pretty much limited to monster servers.


But, yes, your point that VMS inspired much of how WinNT works is correct. MS even has a pretty decent implimentation of clustering for WinNT, second mainly to the VMS clustering setup.

Anyhoo, hope this little trip down mwmory lane is a useful clarification. Poking through some of the URL's I mentioned was actually quite interesting to me. but then, I do have an old computer fetish. Anybody have one of those early VAX workstations lying around that they want to give me?

By Will Rosecrans (Forkazoo) (172.195.105.26) on Friday, January 17, 2003 - 02:09 pm:

Okay -- I'm stupid. MS actually did have WinNT out for the Alpha within a few weeks of WinNT for Intel. they didn't wait until NT4 like I thought. In retrospect, it was actually pretty goofy for MS to not do a 64 bit WinNT from the start.

By Daryl Cornutt (Dfc) (24.90.251.91) on Friday, January 17, 2003 - 02:14 pm:

Thanks Wil.

Yes, trying to remember off the top of my head

Yes, according to the history of VAX/NT that I read the NT kernel was such a copy of VAX kernel that they got sued. Bill G paid a LOT of money to Digital and settled out of court.

The history article I read also had a detailed comparison side by side of NT kernel and Vax kernel. They were, for all pratical puposes, identical.

I enjoyed reading it very much. Interesting stuff. But, unforunately, it was a while ago and I'ts hard to remember all of it

Thanks for the clarifications/timeline, etc.

And the links!

D

By Beam Tracer (Beamtracer) (203.109.241.109) on Friday, January 17, 2003 - 05:36 pm:

I remember in the late 1980s, the NBC television network had a station identification promo with the slogan "Be There". There was some 3D animation that went with it, that featured a kind of rectangular block with neon tube lighting around it, the NBC peacock logo and the words "Be There!" molded into this object. It spun around on a reflective floor.

I was pretty impressed at the time. Although it was essentially just a spinning logo, I thought it looked real. The logo was animated using a Cray supercomputer that was the size of a large room, and was temperature controlled by "veins" of fluid coolant running over the electronic components.

The animation cost millions of dollars to create. About a year ago I was bored one day and decided to recreate this animation on my Mac using Lightwave (just for the exercise). It wasn't that hard! Didn't take that long, either. I wish I could be paid a million bucks for doing something like this today!

My point is... who would have thought that people would require a computer with the power of a Cray in their homes? It would have seemed far fetched. Home computers at the time had less than 1MB of RAM.

You could extend the thought... what kind of supercomputers are governments and universities using today? There are some very big machines from SGI, IBM and others. This is the sort of power that home users will have in a few years.

If the computer processor power and RAM usage over the last 20 years was plotted on a graph, you'd get a good prediction of when 64-bit machines will be common place. Anyone who doesn't think that 64-bit machines will be commonplace in the next couple of years should look at history.

By Beam Tracer (Beamtracer) (203.109.241.109) on Friday, January 17, 2003 - 05:48 pm: