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

Bob Dawson wrote:
"Paul Nichols [TeamB]" wrote
The only time a VM is necessary, is when you are writing to different OS and hardware, IMHO.

Hard ware could be different than you're writing to for more than one reason, though.

Obviously the hardware might be indeterminant (any of several different CPU architectures underneath)--that would be the normal 'cross-platform' use case.

Or the hardware might be indeterminant in a totally different sense: more like the way a view in a database abstracts away from the underlying table schema. That use doesn't imply cross platform at all.

Views are to perform a consolidations of several tables to allow for viewing on joins that are normal operational processes. I do not see how that relates to a VM at all.

If a VM provides a 'virtual' CPU that one writes to regardless of the actual number of cores underneath, and the VM infrastructure then distributes jobs and orchestrates those cores effectively without the programmer needing to worry about all the details of these asynchonous processes, then that would seem to be very worthwhile. Even though it has nothing to do with being cross platform in the traditional sense.

That could be useful, I agree. But I would rather see an inline operation or compiler switches that would allow you to set or monitor the operations without a JIT compile each time the process ran. VMs have their purposes, but optimization is better determined at coding time when you know where the code is going to be deployed, rather than leaving it to be determined at runtime. There is an exception to this rule however, and I speak about it next.

Since current VMs have to register hardware options at the time of the run or in a read ahead condition, there is always going to be a trade off in terms of performance, due to the fact that at least part of the program is read and ran in a non committal phase or process. However, if we had a VM caching mechanism that would read and write the core processes to a permanent store, after the first run, then VMs would be much more efficient. In that sense, I could see some real benefit. Maybe we will see this in future iterations of VMs. I can see where this would be useful and true programmatic operations could be optimized after first run, cached, and then the code would run more like native instructions for the hardware where it has been deployed (think of it as a real time compile or build after the first run). If VMs reach this level of sophistication, I would withdraw all of my reservations and suggest that this would be the only way to go.

The current VMs (be it Microsoft or Sun or Open Source) are not operating this way today. Perhaps in the near future, as there has been talk of rewriting VMs to do just this.

I certainly do not see why a VM is necessary for a single hardware platform and OS. To me, this makes no sense
whatso thaever.

Take the above as one possible rationale. A VM might be useful for the same reason that a high level language is useful--hiding underlying details

Yeah and that is why so many are tolerating an OS that requires a gig of ram and a 2gz. processor. Sorry, there is no way I can see such a justification, especially considering how limited the operations are that the current OS performs. Does anyone truly believe that Vista makes good use of system resources?

To me this is a problem, not a solution. Many may argue, stating programming should be easier than it currently is. I am not against advances in programming technology, but in the past few years, I see way too many so called programmers that do not even know how to perform a stack dump, write a batch file, or know how to run a debug command. This isn't advancement, this is kiddie scripting. :)


..Anders H. has talked about moving programming languages to the point
where the programmer just indicates he wants something sorted and what the ordering criterion is. The run time then chooses the algorithm and number of processors to devote to the task, so it's rather like an SQL 'ORDER BY' clause--the programmer specifies what the results need to look like, and the implementation details--being fairly mechanical once the business logic is understood--are handled by the compiler and runtime.

Again, to each his own, but I did not desire to be a programmer who has no idea how the code actually works. I see far too much of this today.

This puts developers into a box. Get them out of the box and they are lost. I personally feel you are not free to innovate and improve operations, if you do not have control over how the operations work. Maybe I am just an old timer :).

If some want to work within a box, then there are boxes for them. Personally, I have to know how the guts work, for me to feel comfortable about the underlying operations and frameworks used myself. They may be fine, or they may be inefficient bloatware that are really bogging down system operations or perhaps even violating security protocols. I know that those who write the VMs, etc are suppose to be smarter than the average guy, but that is not always the case.


Good discussion, BTW.
.

Relevant Pages

  • Re: hardware errors, do C and Forth need different things in hardware?
    ... do what the comment says or it is a bug that *always* needs fixing ... maybe even needing hardware traps?" ... Any functioning C compiler will generate code that does exactly what it says. ... Your code is clearly a bug in *some* cases, but since C can't tell if this is a bug or the actual intent of the programmer, C will faithfully compile the code to do what the programmer wants-- just like Forth. ...
    (comp.lang.forth)
  • Re: getting started with uProcesors
    ... then send the code to the uP via the programmer. ... The programming hardware can be $20-30 to build your ... and you plug your micro into it. ... compatibility problems mixing Joe's Ultimate Compiler ...
    (sci.electronics.basics)
  • Re: DEFCON 16 and Hacking OpenVMS
    ... But VMS cannot use the space in other ways than the hardware makes possible. ... Many of the privileged CPU registers ... All of this is hardware limitations, and VMS can't do diddly squat about it. ...
    (comp.os.vms)
  • Re: MacSoup + MBP - numeric keypad = irritation!
    ... every other programmer) means when he says hard-coded. ... not without recompiling the code. ... I'm just explaining what hard-coding means. ... in hardware purely because it's software, ...
    (uk.comp.sys.mac)
  • Re: Limitations of VMs?
    ... Would anyone with direct experience of working with VMs like to comment on this review and/or on the limitations of other VM products? ... Memory or data Intensive applications and/or critical applications can have their own OS dedicated to that one application. ... No other applications outside applications that would normally running on a single instance server. ... Consolidation of Hardware: Instead of 5 servers, each with an OS, you can choose to buy one redundant server with multiple CPUs and lots of RAM and create VMs based upon need on that one box. ...
    (borland.public.delphi.non-technical)