Re: What will many cores mean to future Windows releases?

Bob Dawson wrote:
"Farshad" wrote
The "primary goal" of using managed code or intermediate language is to produce a OS/CPU independent executable that will run on any platforms

That's one possible goal, but not necessarily the only goal.

But I do not see the need of a VM outside of abstraction from the underlying OS or Hardware. This takes the extreme of sacrificing performance for a supposed problem, that really should not exists.

If developers cannot take care to write efficient code in language X, that uses physical memory management of the underlying hardware and/or OS level calls, then they will likely not be competent to write VM code.

There are still VM operations in NET and Java that require developers to manage memory or open connections that if not handled properly can crash not only the application running, but the OS itself or other cooperating systems (think of these requiring the manual opening and closing of threads and API calls, like file read and writes, database connections, or native OS calls to get platfrom specific information. All of these require that the developer manually manage these operations ).

Yes, I have seen horrendous C and Delphi codes that leave dangling pointers, allocate specific memory and then fail to deallocate the same, but the coding paradigms employed were so woefully deficient that I would not want to follow behind them with a Managed Code program either. :)

In fact, I think I'd argue that the concept of 'platform independence' as it's generally used today is really something of an abberation. In the area of OSs, for example, consider AmigaDOS, AppleDOS, HDOS, TrsDOS, the Commodore PET OS (whetever it was called), Solaris, OS/2, OS/400, or a host of others. An OS might in theory be a hardware abstraction layer, but in reality, I can't think of another OS besides CP/M that was intentionally created to evade hardware vendor lock in. Mostly, OSs are designed to make it easier to work on the vendors specific platforms. (And the same is completely true of IBM-DOS--that IBM lost control of the platform was certainly to MS's advantage, but the real enablers were the AMI and Phoenix BIOSs.


I agree that optimizations of the hardware can require specific instruction. Precisely lends itself to my rationale. :)

The rationale behind VM enabled platforms, like SmallTalk and later Java. was to abstract the underlying platform specific instructions (hardware/software based). Both of these solutions actually did what they intended to do (Java still does), to make XPlatform development and deployment a reality. The construct was and is to offer an interpolation to arrive at the goal of OS/hardware abstraction.

As earlier stated if the VMs could read the hardware and platform and cache these results so that subsequent operations (after first run), could permanently store these optimizations and optimize this for that platform (hardware and OS), then we could reach a true balance of better than natively compiled and delivered binaries and VM/OS agnostic operations. This I would embrace and never question, since you would naturally achieve higher levels of performance that would be possible than with native compilations delivered as static binaries. We may be approaching this direction with future VM implementations. JITs started this directions, but stopped short of the permanent caching of such information due to the concerns as pointed out by onother poster, hardware changes and kernel and kernel layer updates. I think this could be solved as well just as OS systems update this information upon the new install of hardware and OS updates.

Another VM direction which Java is currently exploring for the EE side of the equation, is to isolate the VMs into their separate memory space, which works simalar to chaining the processes and the application domain, so that each application is separate and distinct from the other, but which can share resources and optimize processing instructions based upon perceived or actual usage.

This is very interesting in theory and could be a boon to server side application processes and could easily be extended to multi-core. My only question is performance. I wonder how long it would take to process the usage and resource shares across these difference Application domains. Of course SAP already does something very similar to this and it works quite well.


And it's pretty much the same in the world of languages--UCSD Pascal and C were both intentionally created as cross-platform systems, but I can't think of too many others.

Others Python, Perl, CAML, Ruby, Java, SmallTalk, Oberon, Ada, etc. Some of these listed of course are meant to run in an interpreter, some were meant for native compilation.

The language itself is irrelevant for multi-platform distribution, the compiler or VM and libraries/copy books are the only consideration for XPlatform development using conventional native compiled programming.

Languages, like OSs, have most commonly been created to
make specific systems easier to work with, not to advance some cross-platform goal. NOr is that a mean or second-rate purpose: I write to the VCL rather than to the WinAPI directly because it's more productive. It's as simple as that.

Languages are usually not developed with a particular OS in mind. Pascal was not written for Windows, any more than COBOL was strictly meant to be a Mainframe language, or C was meant only for Unix, Life for these languages may have began on a specific platform, but the idea of creating a language is to solve specific problems, not to be confined to a particular OS or usually, even hardware.

Even Basic was not originally written for Windows.



So if we're going to question the point of a VM that doesn't offer 'platform' independence, I think we're going to have to question the point of most of the service layer and abstraction layer code ever written. Historically, platform independence has just never really been a central concern for any of it.

Sorry, I do not understand what you are attempting to say here. See above concerning languages.

I don't see anything special here about managed code or a VM runtime: specific implementations will succeed or fail based on cost/benefit tradeoffs.

This is true, of course.

Most of those will have nothing whatsoever to do with being
platform independent.

Then why has Java been so successful, or C/C++? It is precisely because these languages were and are used for XPlatform development that have made them popular, not because they were intended or are used for mono platform development, So the evidence totally argues against this statement.

So I don't know how to call a Framework which produces OS
independent Byte-Code but its vendor provides runtime binaries
only for a single OS. Such a freak may only exist in Microsoft's universe.

Not at all. Consider all the various Java application servers (IBM, BEA, Borland, etc.) that each offer proprietary extensions to encourage code that will only run on that specific server. How is that any different?

This used to be true, but has not been for some time. If an application server has proprietary extensions that abstract it from the certified Java core, it cannot be Java certified. This has been in effect for some time. Of course, too many Headhunters still fall into that misconception. :)

The way or manner in which the Application Server performs its internal operations can be proprietary (as well as the deployment descriptors for EJBs,JMS), but the manner in which a developer writes Java code against that App Server does not vary from one app server to another. The exception used to be portals, but even that has changed now.

.

Relevant Pages

  • Re: My Migrations
    ... I used to say all my dreams were in COBOL. ... Development and deployment platform based on SOA and Smart Client ... All source languages are translated to C#. ... The fact is that MicroSoft DID have some bad products and they still have ...
    (comp.lang.cobol)
  • Re: My Migrations
    ... I used to say all my dreams were in COBOL. ... Development and deployment platform based on SOA and Smart Client ... All source languages are translated to C#. ... The fact is that MicroSoft DID have some bad products and they still have ...
    (comp.lang.cobol)
  • Re: A One-Console Future? No Xbox, No PS3, No Wii? (article)
    ... Just like there's only OS and one hardware platform for PCs... ... massive paradigm shift to the industry,where games would become better ... Console games still tend to evolve pretty fast as compared to other ...
    (alt.games.video.xbox)
  • Re: [PATCH] [REPOST] timer iomem hwrng driver
    ... had a source that provided new data at intervals of time where jiffies ... Of course I should handle the wrap case, which I have already done at ... 64bit on a platform or two. ... actually have the necessary hardware? ...
    (Linux-Kernel)
  • Re: beginner: Java or .NET?
    ... The professional market requires knowledge of platforms, not languages, so when you choose a language, you'll study its platform for your professional work. ... Java is a very clean language, and I would suggest it to beginners. ...
    (comp.lang.java)