Linked by John O'Sullivan on Fri 17th Oct 2003 17:48 UTC
"640K ought to be enough for anybody." Bill Gates, 1981. "64 bit is coming to desktops,there is no doubt about that, But apart from Photoshop, I can't think of desktop applications where you would need more than 4 gigabytes of physical memory, which is what you have to have in order to benefit from this technology." It seems to me that by the time it ships, Longhorn will need 4 gigs of RAM.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
I realise we can't go back to the days of the real programmers (Apologies to embedded folks, you still have 'em), but I'm not sure we should all be so eager to rush towards the day where the actual hardware a program will run on is viewed as an irrelevance when considering how to design a program (Java might be an example).
In think you have confused bloat with features. Bloat refers to a feature size comparision, and the size of the code is unjustifiably large for what the application does. Sure, therei some bloat out there, but by in large, most code is fairly tight.
As for the comment regarding Java, the fact is that Java will enable larger and more complex applications to be developed without the downside of this complexity resulting in buggy code, and no, hiring more programmers doesn't fix a problem, in some cases it makes it worse.
Java will also remove many of the security and memory related issues that plague applications today. If you remove the need to manually manage memory, you reduce the chance of bugs entering the code. If you let something like a virtual machine sort that out, the virtual machine will also provide a much more robust protected environment for applications to run in so that issues such as virus's, memory leaks, buffer over-runs and so forth become a thing of the past.
As a group have proven via their implementation of the Doom/Quake engine in managed C++ as shown by the article: http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseSt...
Once running, the performance penalty is so small, one can place it in the pathetic region of performance loss:
"A large body of C code can be ported to run in the CLR without a lot of work," says Arvesen. "The performance was sufficient – 85% of the speed of the unmanaged code, based on benchmarking. The testers didn't report noticing the performance difference.
"We are still free to use natives like STL in managed code. Our C++ skill set carries forward when creating managed applications with Managed Extensions for C++.
"The experience overall was very good and we felt productive porting and extending the code. It’s nice to mix native and managed code, to have control over memory management, and to use existing libraries as well as .NET Framework classes, all in the same application."
This is a game using a tonne of mathematical work for the graphical effects, something that manage code is not extremely strong at. Considering that somethign like Word, Excel, PowerPoint or Access would never use those sorts of functions, the liklihood 95% performance equal to unmanaged code is very high.