Re: Apple's poor positioning for the age *after* x86

Daniel Johnson wrote:
On 2005-09-20 15:24:20 -0400, TheLetterK <theletterk@xxxxxxxxxxxxxxxxxx> said:

Daniel Johnson wrote:

On 2005-09-18 13:45:17 -0400, TheLetterK <theletterk@xxxxxxxxxxxxxxxxxx> said:

Oh, this is silly. You know what I'm on about: The OS will be able to support abstracting CPU like we can do GPUs now, or better. The technology is there.

Yeah, as long as Microsoft writes a runtime for said platform. Which makes the whole issue rather moot. 


Moot for consumers but not for Microsoft!

Now, you can see the fly in the ointment when I put it that way: how is MS supposed to get developers to care? This can't work without them on board.

Apple's technique is to kill the old architecture so developers have no choice. MS can't do that; what they can do is entice developers with great new technologies available exclusively on .NET.

And they are. Consider the big fuss MS made recently about "LINQ". This technology could be implemented for a native compilers, but it won't be. .NET only.

[snip]

They didn't do that because they wanted to. They did it because it is far too hard to switch. Even now it will be a stretch; too much Carbon software, never mind the remaining Classic users.

They switched to PPC from x86 and SPARC.


Apple switched from 680x0 to PPC, and is now switching to x86. I don't see how SPARC gets into it.
Because OS X and Classic Mac OS have no relation? OS X was an x86 and SPARC platform, primarily, in the time before it was ported to PPC (it was called OpenStep back then).


They should have depreciated Carbon back in 2001 and had it removed in Tiger. Classic should not have existed after Jaguar.


That is even more aggressive than Apple! I think they'd lose a lot of apps if they removed Carbon now; conversion to Cocoa is much harder than going from Classic to Carbon.
That's why Carbon would have been depreciated back in 2001 and not removed until '05. It would have given developers 4 years to convert their apps. New OS X apps would not have been developed using Carbon.


I'm afraid I have lost track of your rhetorical gyrations. What's this to do with my claim?

Won't you need to optimize the runtime for every architecture you choose to support? Won't that mean optimizing the compilers in addition to the runtime?


No. .NET compilers do not optimized; only the runtime does.
Yes, and that runtime has to be built using a compiler (unless you plan on writing it in binary?). I'm not talking about .NET compilers, I'm talking about the compiler you use to build the runtime.

You have to implement the runtime for every architecture, and that means doing optimizer work, but Apple's technology has the same drawback. It's not such a serious problem: you only have to do it once (for .NET) or only a few times (for Apple) per architecture.
Keeping the .NET runtimes updated will be a continual effort (unless they don't plan on keeping full support for any but one architecture?). It will definitely be worse than Apple's method, which is substantially worse than Gentoo's.


You can't have true hardware independence because you are always going to have to port a VM to a new architecture.


Having to re-implement the VM is not a serious obstacle.

It is if you want decent performance. Why do you think Java runs like a dog? They realized the only way to achieve platform independence was to develop a software platform for the lowest common denominator.


Java runs like a dog because Java has a very rigid memory management policies. If they are what you want, you can run very fast. If not, you just lose.

This has been a problem for "safe" languages, but progress is being made. 
No, hardware is becoming faster.

.NET 1.0 was already quite a bit better than Java with first-class value types and delegates. .NET 2.0 is adding VM level generics for even more control.

Also one proven trick to help with this problem is to rewrite small performance critical bits in some faster language. This is how Apple does Quartz, for instance. It's C with an OO wrapper in Cocoa. 
Won't this kill your architecture independence?


This kind of thing makes porting harder, but better the platform vendor should do this than the developer. This is essentially why Cocoa apps are easier to port to Intel: Apple owns many of the bits that are written in plain C or in assembly, and can port them themselves.
You do realize that *nixes have been doing the same thing your talking about with .NET for 20 years no, right? I still don't understand why you would want to use a JITC instead of one-time compilation at install time. Just release applications as encrypted source packages, and compile for each architecture on the box itself. Then the vendor just has to maintain a few core libs on multiple platforms. Much less work than maintaining a well-optimized multi-architecture runtime. Solves the lowest common denominator problem (hardware specific functions won't bave to be ignored), and the end user would never know the difference.


[snip]

You'd have to predict where you are going to switch to, to do this with Apple's toolchain.

This isn't a problem for Apple since Apple knows what platforms they're going to switch to long before they switch platforms. It would be an issue for Microsoft, yes. But for a vendor that sells both the hardware and software? Not at all.


I wonder about that. Apple did about much as humanly possible to prepare for the latest shift.. but back before the G5, when the G4 was stalled out for so long (at about 500 MHz, wasn't it?)... they did not jump ship to Intel. It would seem like it would have been wise to do so.
It would have been wise to do that back in 2000 when they had a platform that had been running on x86 for the last 7 years. They could have had it ready for release long before XP hit the market, and captured some marketshare with it. Might have done so more effectively by EOLing the Mac brand name and refreshing NeXT.


It seems like Apple's knowledge of where they were going did not allow them to go quickly.
No, they were trying to save their brand name and maintain backwards compatibility.


[snip]


How did "bad code" get into it?

Well, you ARE encouraging developers to write slow, bloated code in an effort to achieve an irrelivent goal... 


That is not so. Except for the irrelevant part. :D

[snip]

They are also a system vendor, but clearly the concerns I am raising apply to them. They keep having to switch CPU architectures!

Yeah, from m68k to x86, from x86 to architecture independence, then to PPC and x86... Seems fairly nimble to me.


They did not switch from 680x0 to x86. They have never had architecture independence. Not yet.
Yes, yes they did. Nextstep was originally written for m68k. It was ported to x86 back in 1993 (Nextstep 3.3, I have a copy in fact). It eventually ended up becoming an architecture-independent operating environment that ran atop Windows NT, SunOS, HP-UX, and Nextstep. Why do you think Rhapsody was originally demoed and developed on x86 boxes? Why do you think they've been able to maintain an x86 version all this time? Because there was almost no work involved in doing so, since support was already there.

OS X has no continuity with Classic Mac OS. There are some technologies that moved over (Apple's apps, Quicktime, etc), but the OS is clearly derived from Nextstep/Openstep.


[snip]

They are locked; those DTKs are to unlock them by getting universal binaries out there.

Those universal binaries have been supported by NeXTstep/OS X for... uhh... over a decade now.


No. Mac OS X has not supported them until very recently.
I doubt that very seriously. The functionality might have been hidden or locked, but I imagine the support was still there. They would have had to go out of their way to off the technology, and why would they do this?


With modern VM technology, Apple would not need the DTKs.

Yes, instead they would end up with slow applications. You end up having to develop a platform for the lowest common denominator; or you simply limit yourself to a set of hardware, just like you were limited before this venture.


I think that the slow applications problem is being overcome. Already the latest VMs are better then the ones that convinced you this stuff is unworkable, and better ones still are coming soon.

The performance problems Java demonstrated in the late 90s were real, but they are by no means insoluble. As long as MS has the time to overcome them, they will prevail in the end.
It's a pointless endeavor though. Why go through the trouble? So you can switch architectures at the drop of a hat? Why would I care? It serves no function other than an impressive point for Microsoft marketing people trying to foist .NET off on everyone. Yes, Win32 needs to die. Yes, .NET is a good sucessor. But not because of the supposed architecture independence, which will never be used.


[snip]

Sure. This technology is advantageous to Microsoft, Apple, and other OS vendor. They get to support the hardware they want to.

Except none of these companies will implement this like what you are claiming.


MS is doing it right now. .NET 2.0 is the next step; Vista the one after. This stuff is on the way.
Sure. But I'm never going to be able to run .NET 2.0 code on PPC. Or SPARC. Or PA-RISC. Or any platform other than x86, IA64, and whatever Intel releases after these. It serves no function because Microsoft will never develop a runtime for anything but the same platforms they've been blessing for years.

The technology may well be able to do what you say. But it will never be implemented the way you say it will be because of management decisions.


It's platform independent for the sole reason of being able to claim that .NET is platform independent. It's a feature implemented for marketing purposes, not some pressing technological need.


If by "it" you mean ".NET", it is certainly not "platform independent". It is part of Windows. 
Architecture-independent, sorry.


It fills a number of needs, some more pressing and some less. This is, for MS, a less pressing need right now, but it will matter someday, I think.
I don't think anyone will ever give a damn about architecture-independence. Especially since Microsoft will never go for architecture-independence beyond the same architectures they would have supported with Win32 had .NET not existed.


[snip]


With VM technology, you would *already have* the "updated binary".

And it would be *half the speed* of the software on OS X. This kind of widespread compatibility comes at the cost of performance. Is it worth it, on the off chance that you might need to switch CPU architectures? Not in my opinion.


I am not proposing that you write to a compatibility layer, Java style. What I am looking forward to is a managed user-space. And that user-space will be Windows.

This does not give you platform independence at all. It gives you hardware independence. Very different.
hardware platform. Platforms are, by definition, layered. When I say 'platform independence' I mean 'hardware platform independence' or 'architecture independence'. I'm just too lazy to type it all out. Sort of like how people use 'RHEL' instead of 'Redhat Enterprise GNU/Linux'.


[snip]

.NET compilers do not optimize. They emit unoptimized MSIL and the JITter optimizes it.

Yes; but you have to *optimize the runtime*. 


Yes, you do.

To do this, you will also have to *optimize the compiler* for each of the target architectures.


No, just the runtime.
So you'll go through all this trouble to write an optimized compiler, and build it with some slapped together compiler targets at a half-dozen architectures? Here I thought you had to actually optimize the compiler for the target architecture to generate well-optimized binaries...

Again, I do not speak of .NET compilers. I'm talking about the compiler Microsoft is going to use to build the runtimes for all these architectures. They will have to maintain both, and that will not be easy. GNU has been trying this for decades, and there is a reason GCC doesn't perform well on anything but x86.


A task that will continually increase in difficulty. I'm not talking abotu the applications, I'm talking about the logistics of implementing the type of platform you suggest.


This is no worse that the logistics of something like GCC. Better, in fact, because you are probably not going to ever target as many architectures as GCC does.
Yes, but you'll still have to do most of the work they do. You'll also want something that is more well optimized than gcc/x86 is. For all of the target architectures.


[snip]

So it is easier: instead of writing several optimizers for your different languages, you just write one optimizer for MSIL.

Then you have to optimize the runtime to interpret the MSIL, then optimize the compiler for each target architecture to compile the runtime to run as quickly as possible (since performance will be sluggish enough from the get-go). When you are dealing with three architectures (two of which are fairly similar), this isn't really much of a problem. When talking about seven or eight... Well, it becomes a real problem. Especially after 15 years of each architecture adding new features and branching off. 


Not to put too fine a point on it, but you are just making stuff up here.

The runtime does not interpret MSIL, it JITs it. There is only one JITter, and it has an optimizer, and that does have to be written, but it's not such a huge deal to do so.
Alright; this is a part of the runtime. Neither of us debate the fact that this will have to be optimized. Now, how are you going to build the runtime? Magic?


Because the runtime is not an interpreter, the efficiency of the compiler that compiles it is less important. It will affect the time required to JIT code, but not the time required to execute programs. You could certainly get away with something highly portable like gcc for that.

[snip]

.

Relevant Pages

  • Re: how to get Ultrix on MicroVax 3100?
    ... and of OpenVMS Alpha required for new hardware support -- with the advent ... and in the various platform consoles, ... :>one bit because the architecture ... :the CPU driver were different. ...
    (comp.sys.dec)
  • Re: building universal static libraries
    ... ppc side i want to use the 10.3.9 sdk, but on the intel side you *have* to use ... option more than once, for each architecture? ... Support for the -isysroot flag is available in the GCC 4.0 ... compiler but is not documented in the compiler man page because support for ...
    (comp.sys.mac.programmer.help)
  • Updates on the X64 port
    ... support cross compilation for the minix platform. ... platform and that too till version 2.3.3 which does not support x64. ... I was also considering modifying the ACT compiler and updating the EM ...
    (comp.os.minix)
  • Re: There Will Be No 64-Bit Delphi Compiler Even Ten Years From Now
    ... > which is a flaw of the tool, not the platform. ... > possible to create a compiler that can target any given version of the CLR; ... a tool can support new language features not yet developed. ... > implement the next generation of language features into their compiler. ...
    (borland.public.delphi.non-technical)
  • Re: Python and Flaming Thunder
    ... SPARC, ARM, no other CISC or RISC architecture. ... single language compiler instead of three dimensional compiler that ... GCC is (cross platform, cross target platform, cross language). ...
    (comp.lang.python)