Geek.com is running an opinion piece on the extensive reliance of programmers today on languages like Java and .NET. The author lambastes the performance penalties that are associated with running code inside virtualised environments, like Java's and .NET's. "It increases the compute burden on the CPU because in order to do something that should only require 1 million instructions (note that on modern CPUs 1 million instructions executes in about one two-thousandths (1/2000) of a second) now takes 200 million instructions. Literally. And while 200 million instructions can execute in about 1/10th of a second, it is still that much slower." The author poses an interesting challenge at the end of his piece - a challenge most OSNews readers will have already taken on. Note: Please note that many OSNews items now have a "read more" where the article in question is discussed in more detail.
Post a Comment
Member since:
2008-03-19
Fans: 0
Member since:2005-08-26
Fans: 5
I installed Windows 2000 Pro on a P3 600E (coppermine) from the late 90's this past weekend.
The box had 384MB RAM, a TNT2, and 9GB drives on Ultra-Wide SCSI2.
I was seriously impressed with how fast, responsive, and darn smooth this box was. I had forgotten how smoothly win2k ran on machines like my old 400mhz K6-2.
So my question is what functional requirement can you do on Windows XP (or even vista) that you couldn't do in some way on Win2k? I'm not talking about eye-candy, funky interfaces, etc. I'm talking about what -kind- of application runs on Vista, but cannot, in any way, ever run on Win2000?
It's a function of time and engineering cost.
Photo management? Picasa.
Mp3 / Audio? iTunes 7.3.2 works on Windows 2000.
Games? This could be handled if they spent the time writing drivers / using technology other than directx. It's an engineering issue.
It seems to me that the core functions of the OS haven't expanded. It's what people expect the OS to do with the software pre-installed out of the box.
Photo management isn't an OS function.
Audio management isn't an OS function.
Could an OS provide hooks to handle such management? Absolutely, but that's not a core OS feature, and an OS that doesn't expose that by nature could have an application written for it that -does-.
I disagree. OS's today don't do a whole lot more than they did 10 years ago. In fact, most OS's today are just now catching up with what BeOS did 10 years ago.
Member since:
2006-11-19
Fans: 1
Seriously, Java and .Net are 200 times slower than C? Where those numbers come from, where is the study?
For the reverse side, there already are: There was a story in OSNews a few years back that showed MS C# compiler actually produced faster code than GCC C++ compiler on Windows on the same scenario (back then). And simple Google searches find similar things for Java, too: http://kano.net/javabench/
I'm not saying Java or C# is faster than C++, and don't completely believe in these benchmarks. But I know that they are at least comparable. As far as you're doing the same work, the results are very similar.
But as mentioned above, if you actually start doing more more work, (as in remote procedure calls, automated web services, virtual methods, reflection, etc) your execution time increases, naturally.
In my opinion, OSNews should increase its requirements a little bit, require some proof in the articles linked, in order not to include these ones.
Edited 2008-04-20 16:27 UTC
Member since:2005-11-15
Fans: 0
Member since:2006-08-26
Fans: 0
It may not be 200 times slower, but it is slower. It's on average in the same order of magnitude as C/C++ across a series of benchmarks, which for most people is about the same speed. For a good idea of actual relative performance, see the Great Computer Language Shootout. The issue of speed being in the same order of magnitude doesn't matter for applications centered around small packets of work interrupted either by I/O or user think time. But even that depends on the application.
In graduate school I did quite a bit of Genetic Algorithm related classwork. This was purely compute intensive code. In some of the more interesting applications the fact that Java is 2x the speed of similar code under C means 2 weeks of runtime instead of 1 week of run time. If the code was largely computational, that didn't do a lot of I/O, I would use Java because it's a very productive language to work in. JDK 4/5 didn't seem to have the same I/O performance as straight C. Having no evidence, I always assumed this had to do with the layers of library code surrounding Java I/O.
If you start adding in issues like memory usage, the picture becomes murkier. Java requires significantly more memory than the equivalent C code. Depending on the version of the VM started up, the difference can be megabytes (for the VM and program) versus kilobytes (for the C code). The libraries layered on top of all this burn even more memory. For example, Rails using C Ruby versus JRuby. They both execute Ruby code, but JRuby deployed in a J2EE environment easily requires 512 of megs of memory to do what C Ruby does in about 20-50 megs of Ram.
Like anything in life, it's a trade off. Java is a very productive language with a huge world of libraries. For many businesses this represents a real cost savings for their custom, line of business applications. It is not the panacea that most Java developers pretend it is. In some cases the speed difference is real and can't be ignored. In some cases Java is actually faster than C due to run-time optimizations that C can't do (as it stands). However, it seems like we have to buy large, more capable servers (in some cases with 4 times the ram and 2 times the speed) just to do the same or a little bit more work than what we did last year. Part of that is the result of these huge frameworks that are not intrinsic to Java but come along for the ride (weather we want them or not).
Member since:2006-10-11
Fans: 0
Member since:2008-04-23
Fans: 0
You're making that up. JRuby actually uses LESS memory than C Ruby. JRuby 1.0 might have used about the same or a bit more, but we've never used ten times as much memory. And JRuby 1.1 consistently uses less memory than C Ruby. Or are you referring to an entire Rails app under JRuby with ten instances (to be able to handle ten concurrent requests) versus a single C Ruby instance (which can only handle one?) Both JRuby and C Ruby must start up multiple instances to handle concurrent requests in Rails. The difference is that JRuby does it automatically (configurable) and C Ruby does not. When you run both with the same number of instances, JRuby will win every time.
Check your facts please before you post comments like this.
Member since:2005-09-28
Fans: 1
Many of us had our first go at running Java desktop apps back in the mid 90s. Unfortunately, Swing was very slow at that point and this created the myth, in the mind of many people, that Java is slow.
I think that Java could have made massive inroads into the desktop if only Sun had worked harder to polish Swing performance in the early days.
Member since:2005-07-24
Fans: 33
Today, Java desktop apps are not exactly slow. But the slowness has been replaced by a tendency to be horrendously irritating. Download LimeWire and you will quickly become afraid to move your mouse. Because every time you move it, say, a quarter inch, you get a new and annoying popup giving you all the gory details about another song you didn't really care about, and blotting out your view of something that you *did* care about.
Member since:2005-07-06
Fans: 1
Member since:2006-03-27
Fans: 0
The only java based, full fledged application I have any experience with is Eclipse and my experience has been that Eclipse is significantly and noticeably slower that other IDEs. It's usable on a fast, modern system with lots of memory but I have Linux loaded on a couple of older, slower boxes with half a gig of memory and using Eclipse on them is downright painful.
I'm also not sure I agree with either the original article or the response above when it comes to operating systems. I use a computer that is on the military's NMCI network on a daily basis. Because of government requirements, it's still running Windows 2k. It's not noticeably faster than similar machines running XP, but neither do I notice any significant decrease in capability.
Member since:2005-11-18
Fans: 2
I'm not saying Java or C# is faster than C++, and don't completely believe in these benchmarks. But I know that they are at least comparable. As far as you're doing the same work, the results are very similar.
It depends on the application, but I largely agree. I wrote a fairly CPU-intensive natural language processing application in both C++ and Java, and the C++ implementation was about 10% faster. Of course, this is in no way a scientific benchmark, but it shows that it does not matter that much (especially compared to Java sans JIT). Of course, the same application is awfully slow in Python or Ruby. Which enforces the old mantra: use the right tool for the job.
Of course, when comparing C++ and Java/C# there are much more interesting facets. For instance, language features like const-correctness, operator overloading, and templates are things I very much prefer in C++.
In this respect, I am very interested in the development of Digital Mars D, because aims to provide a good middle road between C++ and more dynamic languages.
Member since:2007-03-30
Fans: 0
I agree that broad claims such as the one in the post should not be made without a substantial study backing the claim.
That said, I can say that I've written a small data mining app for finding nearest neighbors in a dataset of 1M records. I did the implementation once in C++ using STL, and once in C#. The two implementations took nearly the same time to finish (on average over multiple runs).
That to me says that .NET is not slower than C++ when it gets to number crunching. A different type of app may behave differently though.
Member since:
2007-10-26
Fans: 0
I hope I don't sound like a broken record here, but I think developers should use the best tool for the task. Contrary to what Microsoft or Sun want you to believe, neither .Net or Java is the be-all end-all of programming languages.
I think there needs to be a balance between programming ease and efficiency, were the most processor intensive tasks are coded in C or C++, where simpler features are implemented in higher level languages. A good example of this is Amarok where most of the application is coded in C++, but the lyrics engine was changed from C++ to Ruby. Does that make Amarok slower? I very much doubt it. But it does make it tons easier to develop, maintain and expand.
On a side note, while the argument made against the recent versions of office/windows being slow compared to older version is valid, the blame may not entirely be due to coding inefficiency. The extra features and backwards compatibility have something to do with it as well.
Member since:2005-07-06
Fans: 16
True, but at the same time, I do think that the one thing .NET has as its advantage is the ability to for C++ (and others) to move their code over to .NET and retain their skills - without needing to re-learn everything. That is the one problem with Java, it requires you throw all your existing skills out the window. Its just not viable to take that approach.
One also has to acknowledge that .NET is more than just a competitor to Java, it is also a competitor to win32, it is ultimately going to be the future of development on Windows.
True; personally, I think that programmer ease should be at the top though; if something can be better implemented, better maintained and less issues crop up (memory management), it should result in more reliable products. When it is easier for the programmer to do his or her work, the less likely they are to make mistakes. I'd sooner have less 'teh snappy' in favour of more stability and security.
Well, for me, I think, if Microsoft ported the whole Office suite to .NET, and made .NET available on Windows and Mac OS X - then I think that the performance price would be worth paying. Although one would want to be optimistic, personally, I think that Microsoft is running out of things to add and/or change to Office to make it worth while upgrading to the next version.
Member since:2007-04-29
Fans: 0
This is NOT an advantage, different platforms require different approaches and therefore different skills. I am currently maintaining a asp.net website which is coded by a guy who obviously loves cgi (everything is writelined and no inheritance was used, ever.). This is horror for me, and everyone after me. I'm rewriting the code now so it uses controls like asp.net was designed to do. Use the right tool for the job and use it right (most people forget that last part).
Member since:2005-07-06
Fans: 1
Member since:2006-10-08
Fans: 6
You're right. The way from C to C++ may be a bit complicated, but from C++ to Java it isn't that hard. The most important thing when you've learned C++ isn't the language itself - your shills usually are OO-oriented, and you recognize the means of the language, its contructs, its grammar and so on. This knowledge is mostly very generic (!) and you can use it with any further language you like.
A good programmer isn't a person who knows one language from the inside and from the outside, but he's a person who can translate a given problem into an alrorithm, and then map this algorithm onto the desired programming language (or best language for the given task).
Member since:
2007-05-20
Fans: 0
I doubt it.
I doubt it too. By the moment they would reach whatever level of completeness they would set to, they would be bloated and "slow" in their own way.
And yes, I would never compare Win95 with a todays OS. Win95 would run one app fast, what about running 10 apps fast, or 20 apps, 3 compiles, 5 web sites and 3 databases? What about crashes? Speed is not everything. You can never actually forget about the computer and focus on the job, until your computing experience becomes reliable.
Member since:2005-08-09
Fans: 0
I agree that an "older" OS might not be able to multitask well. However, it might also be cheaper and actually manageable to move some of those apps to other computers..
I don't do lots of programming, but do many of us run 20 apps, 3 compiles, 5 browser windows, and 3 databases at one time on one computer? Not only must we have the right OS for the job, but the right hardware.
You could run the some of those on another computer connected to a network (e.g., databases on a server) and off-load that "load" from the "desktop."
Opinions are just that, and we should remember they are very subjective. Regardless whether one is faster or not, I might still program in X. If my program in X "works" for many, it is irrelevant that it was written using X or for the Y platform. Remember, when did the "user" ever sit and time two different apps to see which was faster to determine which software program they used? Speed is one issue, there are many others.
As has been said regarding classical guitar playing, "Faster playing is just that...faster." I would say that faster isn't always better--before you argue, can other hardware or software do something you do on yours (hardware and software) faster? If so, why aren't you switching?
Just my 2 cents.
Edited 2008-04-25 20:19 UTC
Member since:
2006-11-15
Fans: 0
Member since:
2006-02-01
Fans: 0
Yes, managed code executes slower than native code, but in a great many cases, this really doesn't matter. GUI programmes spend the majority of their time doing nothing, waiting for user input. Sending some data across a network could easily take several orders of magnitude longer than processing that data, even if you're using managed code. And in the cases where it does matter, most managed languages make it easy to call native code to do the hardcore number-crunching.
No, the problem with managed environments is memory use. A poorly coded native app can eat memory (hello, Firefox!), but with managed apps memory use really is beyond the joke. Banshee, written in C# and running on Mono, is currently using 75MB on my system. Azureus, written in Java, is using 92MB. Memory use for Beagle (C#/Mono) is more than ten times that of Tracker (C), in my experience. And this just gets worse when running in a 64-bit environment.
Lastly, I have to take issue with this from the article:
Without wishing to start a flame war, it's simply not true that C++ is slower than C. In fact, if you let the compiler get clever with templates, it can sometimes be faster.
Member since:2006-10-15
Fans: 1
Awesome post! You are absolutely right. And to echo what everyone else has said, use the right tool for the job.
Two additional points:
1. Writing software is becoming increasingly complex. Lots of VMs and scripting languages remove the complexity and give benefits that are much more important than processing speed: added security, development speed, etc.
2. Similarly, programming is increasingly more accessible. People value dev time over CPU time (and claim they'll go back and "fix it later" ;-). I'm already afraid of what many programmers screw up in PHP... please don't suggest C to them!
Swig is always there for you if you need to make the code faster.
Member since:2005-07-06
Fans: 2
Agreed. However C++ gives you many more options for shooting yourself in the foot and producing very slow code if you don't know what you're doing. So while it's certainly possible to write C++ code that is as fast as C, it isn't necessarily easy.
Member since:2005-07-06
Fans: 0
... I call such code C-Plus-Minus.
C code rewritten in C++ with minimal mocking around. (No virtual functions, overloading, etc)
- Gilboa
Member since:2005-07-06
Fans: 2
C code rewritten in C++ with minimal mocking around. (No virtual functions, overloading, etc)
The exact opposite approach can cause just as much performance problems, if not more. Things like creating a class when you could use a simple varible (I've seen plenty of classes which where essentially a complicated wrapper around a double), and then using dynamically allocated stl vectors containing members of that class when a statically allocated array of doubles would have worked just as well.
Admittedly many of these things can in many cases be defended as "good design" in some sense, and as such aren't always a bad idea. However you have to be aware that all these things come with a performance penalty. So you have to balance the good with the bad. One of the advantages with C++ is that you have this choice.
The problem is people hear unqualified statements like "C++ is just as fast as C" and think that any C++ code they write will always be 'fast' simply because C is 'fast'.
Member since:2005-07-06
Fans: 0
I fully agree.
I work in a hybrid C/C++ group.
Kernel code and OS abstraction libraries are written in C while service wrappers and the actual applications are written in C++.
AFAICS OO seems to be drawing (good) programmers into a lot of data management and packaging games - read: a trivial pass-a-structure-pointer throughout your code (in C) problems - tend to turn into a nasty (and slow) data packaging and repackaging problem. (in CPP).
In our CPP developer's defense, they are very performance conscious and rarely wrap a single boolean variable with a 1000 line long class. (Hence, large chunks of their code is C-Plus-Minus).
... Just don't get me started about .NET/C#. (Other groups are using it; performance is horrible; switching back to CPP...)
- Gilboa
Member since:2006-06-22
Fans: 0
No you are wrong about the memory usage. Granted some managed apps may have this problem. But this is not necessarily true.
Memory allocation to managed code is managed by the runtime (.NET / Java etc) and it sometimes allocates memory to an application and does not reclaim it back until some other application on the system needs to use this memory, if the memory is unused then it keeps it so that things remained cached.
Yes some programs have memory leaks but *don't* go by what your task manager says, when checking the memory usage of managed code.
Member since:2006-03-20
Fans: 2
Even entirely disregarding memory leaks, a managed program will have a much higher memory footprint than a non-native compiled program. There are three main reasons for this:
1) A virtual machine with JIT means you *cannot* demand page. In other words, if you have 20 processes that each load the same 10 shared libraries which for the sake of argument are 10 megs in size.
In a VM you'll have 20*10 megs for each chunk of JIT'd code, plus the interpreter's memory overhead.
In a native compiled language, the OS is smart enough to share all the compiled code between all the processes, so you only use 10 megs for *all* the proceses. (Ok, this isn't an entirely accurate view, but it's a good first approximation.)
2) Garbage collectors run every now and then. This means that the memory usage piles up as you create and forget about objects. Sure, you don't leak memory any more, but you need room for the garbage waiting to be collected. Research papers [sorry, no links at the moment, but they're around] show that to be effective, a garbage collected system needs between 1.5 to 5 times the amount of RAM, depending on the exact collection algorithms and usage patterns of the program. The garbage has to sit around somewhere in the time between you finishing using it, and the GC kicking in and cleaning it up.
3) Finally, this isn't an intrinsic property of a VM environment, but the languages that run inside a VM tend to emphasize making lots of little objects. This leads to everything from lots of garbage being created (see point 2) to memory fragmentation causing increased heap size (or increased CPU time, if you have a compacting/copying GC).
So, while VM-based languages certainly have their place, pretending that they're as memory efficient as their natively compiled counterparts with manual memory allocation is rather a crackpot notion at this time.
Member since:2006-08-02
Fans: 0
Member since:
2008-04-07
Fans: 0
Member since:
2005-07-07
Fans: 2
I believe this statement that I've quoted from the article exemplifies how retarded that article is. The most obvious fact is that the author overstates the performance impact of the shift to more modern programming languages. Java and .NET hardly increase the runtime requirements by a factor of 200 as is implied by the author. Writing code in C does not automatically mean your code is fast and tight.
On the other hand, his statement about the performance penalties associated with the move to C++ form C is utterly ridiculous. Ignoring virtual functions and polymorphism, C++ is not slower than C. In fact, thanks to templates that are evaluated at compile time, it can frequently be faster. Just look at a comparison between std::sort vs qsort. For example, see http://theory.stanford.edu/~amitp/rants/c++-vs-c/ where the standard C library gets blown away by STL's sort. In fact, the STL sort beats the hand optimized C sort too.
C++ is not perfect. But in comparison with C, you get typesafe inlines (which replace #defines), safe strings, polymorphism, and template metaprogramming which when judiciously used greatly increase your program's execution speed. Yes, C++ is a few orders of magnitude more complex than C, but the gains in productivity and runtime performance are more than worth it.
In closing, the article is based on a false premise. Namely that the shift to type safe, sand boxed programming languages has caused a significant amount of bloat in software. To back his claim up, the author has just pulled a few numbers out of his arse that are so far off target that they only serve to make him look like an imbecile. Software bloat is there because users demand more features. Your software from the mid-90s will run faster, but they don't support Unicode, aren't anti-aliased, and don't sport the "Wow" effects that many users seem to like.
Member since:2005-07-06
Fans: 0
Simplified? Yes.
Retarded? No.
I agree.
The test is far too ancient and their hand-written code is not-what-I-call optimized, so I wouldn't put too much weight behind this benchmark.
It is true that CPP -can- be just as a efficient as C.
... But as I said in another post, the main problem is over-object-orientation. Even good CPP programmers tend to fall into the same usual pit-holes: turning trivial problems into massive class/data (re)packing issues.
C supports CPP-like in-lines just fine. Macros are no longer needed. (Though macros have the built in benefit of having access to your current stack)
Safe strings carry an additional over-head; I wouldn't use them if I was to design a high performance string manipulation system. (But that's me)
In my eyes, templates are a good example what good and bad about CPP: On one side it makes you're life far easier - while on the other, much like over-loading, it makes the code unreadable. (Go figure out what A++; means...)
A. Office 2K/Windows 2K supported unicode just fine.
Heck, even Office 97 (!!!!) had preliminary unicode support.
B. Be that as it may, Office 2K7/Vista is -not- 50 times better then Office2K/Windows2K - and I refuse to believe that feature bloat is the only reason for it.
- Gilboa
Member since:2005-08-09
Fans: 0
Aargh! If I hear this argument once more, I'm going to kill a kitten.
I will figure out what A++; means right after I have figured out what incr(A); means, OK?
http://www.curly-brace.com - Introduction to Computer Programming for the Scientifically Inclined
Member since:2005-07-06
Fans: 0
Ummm. Oh, OK.
C doesn't mix data and code making it possible to understand what a certain code is doing (and even fix bugs) -without- having to learn (by heart) the data model beneath it.
A = B + C will always be scalar. (either integer or pointer math). Same cannot be said about CPP's A = B + C when at least one is a class.
I don't have a debugger; I depend on having to find bugs by reading the code. (Over and over and over again).
Good luck trying to do the same when you encounter a crash within STL.
I assume that this insult/joke/trolling/what-ever is supposed to solidify your (weak) argument?
- Gilboa
Member since:
2005-07-06
Fans: 0
We need people who are willing to spend the extra few weeks or months it would take to develop and maintain code using something that’s close to the machine.
Yes, that would be good, especially if they would work for free. It is also not a matter of weeks or months, it is more likely a matter of years for more complex applications. If you don't rely on frameworks you will be testing the same thing over and over again in each new application you write. Running in virtual machines makes it easier to develop to a more consistent target, and that too keeps costs down.
If development of an OS takes one, two, or five years may not be a big problem for an OS vender, as if he is a successful one, he will sell so many licences that development costs hardly matters, compared to e.g. marketing, but most software that is developed are not sold as schrink wrapped packages or bundled with new hardware.
The majority of all software developed is developed in house, and here only a few copies of the finished product will be made. Here it is absolutely essential to keep development costs down or that in house development project will get canceled very quickly.
Member since:2005-09-27
Fans: 1
DING DING DING You are correct!
Lets do some simple numbers. Average Programmer salary of $50,000+average benefits($15,000) so a programmer cost a company $65,000 a year so that is $31.00 an hour of Cost just for a developer who can do his work without extra overhead (management, power, parking, office space for his butt...)
So he could write his program in a higher level language say in one year. Or write it in a lower level language in one 1/2 year. Cosing $65,000 for an app vs. $97,500 with a $32,500 in cost of an application. Take into account that most of the system times are idle. So you the time performance that is noticeable to the end uses are not in factors of 200x but in 4x (if it can do the processing faster then the person can react to it then it doesn't count). So for $32,500 you now have a programer as far as the end users care the apps runs 4 times faster. Or you can spend an additional $20,000 and upgrade the servers to run 4 times faster and you still better off.
Code performance is really an academic topic. And for most apps not an issue unless it takes a noticeable amount of time to process.
Member since:
2006-09-01
Fans: 3
Member since:
2006-05-26
Fans: 12
So I'll cover this one: whatever you think about how good/bad/ugly Win9x was, it was NOT merely the same thing as Windows 3.1 that ran over an old DOS shell. Certainly, it had a lot of backwards compatibility with older MS-DOS, and that was both the big advantage and disadvantage, and also allowed it to run on older machines with a lot less memory, because the code they had running in 16 bit code was a lot of known-working smaller, more optimized (and less portable) 16 bit code that also allowed a lot of backwards compatibility with 16 bit Windows applications. This also included the backwards compatibility advantage/disadvantage of the Win16Mutex (I forget the official formal name) that kept more than one process from doing things at the same time that wouldn't be backwards compatible due to the model of how Windows 3.1 applications worked with cooperative multitasking. Of course, the very obvious downfall of this backwards compatibility mutex was that if one process was ill-behaved and had something happen while it held it, the whole system was effectively dead in the water.
The curious thing is that there have been benchmarks done with the Windows variants (NT and Win9x) that demonstrate for a lot of the threading primitives, Windows NT was faster! However, because of how things were (at that time) outside the kernel for GDI in NT, Windows 9x was likely more responsive on the same hardware, as long as the applications were well-behaved. The reality is that what the MS-DOS shell he claims was what it ran under, was really more of a boot loader to bootstrap Windows 9x, and once its job was done, it was gone. Even though from a technical point for stability, etc. that NT was better to run than Windows 9x, Windows NT simply wouldn't run (more like a slow execution) on low-end hardware nearly as well, because lower-end hardware didn't have the larger CPU caches, and didn't have enough RAM to keep as much of the larger system in the active working set: thus, it was a more practical tradeoff (besides the backwards compatibility issue) for the standard consumer that insisted on running all or most of their old stuff as-is (WoW wasn't able to do a lot of the older stuff).
Member since:2006-03-27
Fans: 0
Very right. I didn't expect a statement suck "Windows 9x was based on DOS" on a serious OS site like this.
There's another point: looking like being based on DOS was helpful for the home/lowend market (people felt safe about their old DOS games and apps), but scared away the corporate market and pushed it to the more pricey NT. Cool commercial strategy.
Member since:2005-08-22
Fans: 0
The reality is that what the MS-DOS shell he claims was what it ran under, was really more of a boot loader to bootstrap Windows 9x, and once its job was done, it was gone.
That's not really true. If you check the Caldera antitrust lawsuit against MS, you can see evidence against it. They modified DR-DOS to identify itself as MS-DOS 7 and to log all calls to int 21h (basically, calls to ask DOS to do something), then ran Win95 on top of this. They found that DOS was still used rather extensively - DOS was used for pretty much everything it was capable of doing.
Member since:
2005-07-16
Fans: 0
However, I can't help but wonder: if BeOS (or the Amiga, or whatever) had been allowed to continue its development, reaching feature parity with the likes of XP/Vista and Mac OS X - would it still be as lean, slim, and fast like we remember it now?
In fact, we do have an example of such a thing: MacOS X. Remember, it's directly based from NeXTSTEP -- which ran perfectly fine on a motorola 68030 machine !
It was even using DisplayPostScript, ie true wysiwyg, etc.
So what would have happened with BeOS or Amiga ? the exact same thing. And I don't think we have a bad deal out of it -- it's not like there is no added functionalities gained with the increase in CPU power.
Member since:
2006-07-26
Fans: 0
There is a term of theoretical limit. If we need to add two numbers, theoretical limit is one instruction. If we need to convert video from one format to another, it will be much more, we can calculate from mathematical algorithm. Everything above is just a practical cost. Any level of virtualization adds more into this overhead. It is good, if it adds some benefits, not just an overhead. In most cases, it does not, it just takes your processor speed, your memory, battery life, paying out developer's laziness.
Member since:
2005-07-06
Fans: 0
The problem isn't the language, the real problem is "featurism".
http://catb.org/jargon/html/C/creeping-featurism.html
Member since:
2007-03-20
Fans: 0