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

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

Daniel Johnson wrote:

On 2005-09-17 16:27:08 -0400, TheLetterK <theletterk@xxxxxxxxxxxxxxxxxx> said:

It is the driver that must implement the functions in a consistent manner.

DirectX 8 cards *do* support DirectX 9: they don't magically grow new features, but they work with the new DirectX.

Yes, note the 'in hardware' at the end? It meant 'supports hardware accelerated DX9 features'.


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.


[snip]


Apple's repeated CPU speed problems are a good illustration why you should care.

And if they had switched to some sane platform back in 2000 it wouldn't have been a problem. But, instead they decided to stick with chip manufacturers that focus on embedded processors and server chips.


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. They should have depreciated Carbon back in 2001 and had it removed in Tiger. Classic should not have existed after Jaguar.


[snip]


Today we rely on compilers being optimized; it's the same issue.

Exactly the same issue. Glad you realise the absurd nature of your claim.


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?


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.


Why not simply build platform-agnostic core libraries and utilities and recompile on the off chance you need to switch platforms?


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.


It makes absolutely no sense to compromise the design of everything on the platform to encourage bad code out of third party developers.


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...


[snip]


They are an OS vendor: they sell Mac OS X.

That only runs on their hardware. Sounds like a system vendor to me.


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.


[snip]

They also sell hardware but this does not mean they don't have problems because they are locked in to PPC. They certainly do!

They obviously are not locked into PPC; otherwise we wouldn't be seeing those DTKs.


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.


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.


[snip]

Compiling to .NET bytecodes *is* "compiling for a platform". The platform is .NET. You are committed to MS, but you were committed to them anyway if you used their APIs. You just aren't committed to a CPU.

You are committed to whatever CPUs Microsoft decides to build a runtime for. Just happens to be the handful of platforms Windows supports.


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. 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.


[snip]

Oh, I think you will find it more difficult than that. Once the Intel machines start rolling out, we will see how much software gets updated- and how much it costs to get those updates.

Sure, it probably will cost a lot--but not because of Apple's methodology. Because third party developers will use this opportunity to milk more money out of a limited customer base. These developers could very easily release free patches containing the new binaries.


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.


[snip]

Yes. Code written to the VM with a safe language is much better about this.

Alright; so we not only get to optimize compilers (because you still have to build the VMs for all these platforms), but we also get to optimize a VM for multiple platforms? It sounds like you are doubling your workload just so you can coddle third party developers and allow them to write bad code.


Just so you can switch CPU hardware. Bad code has nothing to do with it. 
Bad code is simply a byproduct of this switch.


[snip]

That may be, but the proper analogy is optimizing a *compiler*. You only do it once then all your apps benefit.

You'll have to optimize the compiler anyway. Unless you plan on magicing a VM into existance? Won't you need to include compiler optimizations for multiple platforms as well? Won't this also mean catering to the lowest common denominator?


.NET compilers do not optimize. They emit unoptimized MSIL and the JITter optimizes it.
Yes; but you have to *optimize the runtime*. To do this, you will also have to *optimize the compiler* for each of the target architectures. 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.


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.



[snip]

It's what companies want. It's what they need. Without this, they have to into software development on a continuous basis.

But it is NOT what home users need. This is why I am a firm believer in seperation of the home desktop and business desktop.


Okay. There are advantages to building a specialized OS, but it costs a lot of software compatibility. It's not obvious to me that it is worth it.

.

Relevant Pages

  • Re: Off Topic: Request for Code Review
    ... Yes, I deveop on Windows and yes, all the GUI parts of the code are Windows ... C++ interests me as a language and the cross platform ... how the old Microsoft style can be replaced with a modern C++ style. ... switch to C# - I'm not one of those people either. ...
    (comp.lang.cpp)
  • Re: Should Apple do away with OS X?
    ... Mild annoyance is not enough to justify a platform switch, ... then neither Windows nor OS X would exist. ... I've met some people who, as soon as I mentioned that I was using a Mac, ...
    (comp.sys.mac.advocacy)
  • nor flash fmd driver
    ... downloded files and contacts are kept intact..ie in a mobile, ... switch off and switch on everything will bw there.But if we press the ... these.Is it anything to do with FMD(flash media driver) or rtc ... i am using maistone ii and how can i add stratad.dll to my platform ...
    (microsoft.public.windowsce.platbuilder)
  • Re: The Real IIrony, M$ in the sights of the EU again
    ... >>> trying to compete in the much smaller Mac market. ... >> In which case they can go switch to the other 90+%. ... > another platform at will. ... >> And Ford has a monopoly on Ford cars. ...
    (comp.sys.mac.advocacy)
  • Re: what is the function of audit and account deamons
    ... Ive yet to find an all sun shop where solaris specific features can be focused on. ... when there are multiple versions interacting the use of platform specific extensions is not only confusing, it can be problematic, for example rbacs, sudo, extended file modes. ... its not much use today as people just dont worry about how much time a user uses as theres such an abundance of cpu time available, however there was a time when cpu time was precious. ... many people advocate using accounting as some kind of security monitoring tool, i dont, and would like to see the practice abandoned. ...
    (comp.sys.sun.admin)