Customer satisfaction in pre Fiorina times definitely was the cornerstone of HPs success.
HP always was more expensive than the competition, but you got really what you paid for.
Printers, which were expensive, but literally lasted forever. Calculators HP was king there with products which represented the best you could get at that area.
Same goes for the workstation, which were top notch quality. A processor line, which rivaled with the best (PA-RISC), the list is endless.
They asked for high prices, high prices were paid, because the customers knew, they werent let down by the design and durability as well as the company behind it.
Well, nowadays, HP rivals with Dell and others by putting out mediocre PCs. There printer division still is the cash cow, but given the circumstances, they will lose the market in the long term to Canon.
Their laser printers already are rebranded Canon printers.
PA-RISC dead on the altar of the almighty Itanium.
The merger as usual basically cost the best heads in engineering on both sides which either were gone or fled because their friends were gone.
HP nowadays is a pale shadow of what it used to be.
Either they go back to their core strengths, reinvent themselves in a totally different field, like IBM did, or they go the way of the dodo.
Btw. they are currently trying to make a quick buck by being one of the outsourcing providers. But HP is one of the biggest outsourcers themselves, so why shall customers trust them in this regard? There are others which dont just play middlemen.
Points1 and 2 are valid
if you want to do high performance computing.
#3 is not.
If you need fast 2d rendering, use Java2d and use windows, or have a good graphics card handy and use the -Gjava2d.opengl=true flag.
In both cases the hardware acceleration of your card will be used.
As for fast 3d, you can have several options, either use Java3d or the JavaOpenGL bindings.
Heck there have been programmed 3d games with that stuff, so if you have a speed problem there, you definitely have to check your card.
(The OpenGL bindings basically just root into OpenGL with a thin layer on top of it)
Given that I am not an english speaker, I probably used the wrong term for it.
I think the best one is forced exception handling. Where java differs from C# in a big degree.
In java every normal exception which is declared has to be caught somehwhere and has to be explicitley declared at the method bodies which dont catch those exceptions themselves.
This way you can see at the highest level of the system which errors can occur at the subsystems you call and you have to deal with them.
Sure this causes added code. But in my experience the gain of stability you get from this is enourmous, since you have to deal with every possible program error explicitely.
In C++ and C# it is up to the programmer to catch an exception or to have the system deal with it.
That basically means, a little bit of sloppyness in the underlying subsystem, and documentation, and you might see exceptions at certain situations which you never thought you would ever see, especially if the program runs into one of those 1:1000 states which should never occur, but always occur at the worsed time you can think of.
Will it? You cannot forget about several things.
First they have the advantage of having the huge Microsoft marketing machine indirectly behind their backs. Secondly Iczaza is an excellent marketing guy for his projects.
Third java always was and always is uncool because it is not OSS and it is by Sun (believe me, the name Sun gives you the complete hatred of the Microsoft zealots)
The main problem I see with Mono is, that if you code with that stuff you might end up with a solution which basically is dependend on the goodwill of Microsoft which has several core patents within the non ECMA parts of the library.
Mono itself is an okish platform for development, the language is nice, and what they do in the non Microsoft parts might be good enough to get out programs. Because most programs dont really heavily rely that much on speed, you need good hooks into the underlying gui toolkit and you can cover 90% of the programs out there even with a really slow language.
The main problem java had for a long time is, that it uses its own toolkit and in the beginning it was really slow (not anymore but thats another issue)
So even if the language was fast enough for many purposes it ran into major problems from the user interface side of things.
So they word of mouth that java was dog slow basically came from the early swing implementations. Probably most people wouldnt even notice a java program anymore nowadays, once it is properly skinned.
No, best way to crash a server is to hire an incompetent programmer.
Yes definitely, the guy did lack experience, but the problem is, that in java given the same code nature the problem wouldnt have even existed that strongly.
What would have happened, java would have forced this guy to catch the exceptions. He probably would have done something really evil like logging it out to the console and the system probably would have had a much higher chance to recover to a sane state where it could have given me back a proper error instead of nailing me down mit for 2 minutes and then giving me a timeout.
The problem I see with this classical example is, that such an error can happen in an environment where you dont have to deal explicitely with exceptions even to the most experienced programmer, if the subsystem is not well documented or an error even deeper occurs nobody knows of.
In the end you basically to make the system really secury and stable, you have to catch pretty much every exception at the most outer rim of the system which can occur and then bring the program back to a sane state, which is close to impossible at that point, you might have tangling objects, open files, open connections and so on you dont know of and where you dont have control of (sure can happen with java too but it takes much more sloppyness to reach that state).
Well, I think you brought the whole issue to the point. Java is very easy to learn, but to program a serious system with it is, well lets say it that way, you even could use Logo and it would be hard.
People who can build enterprise size applications dont fall from the trees or you can hire a dime by the dozend, that is my experience, being almost 8 years into the field now.
The other thing is memory leaks. The VM in its current incarnations has none that I know of (and my systems seem to proof that by running months, til years without reboot or VM crash)
But just because you have a GC saying that memory leaks are impossible is a myth.
In the end you have to program carefully not to get them.
Rule #1 program wisely and wherever you are not sure that an object is referenced more than once and should be disposed use weak references extensively.
Rule #2
Learn patterns for heavens sake, learn OO design issue, learn about OO, AOP, Protocols and other stuff generally and keep your knowledge up to date and have a look at others code as often as possible. Also have a basic knowledge about the most important performance aspects of such systems so that you can avoid the usual mistakes which result in lousy performing servers.
If you apply those two rules you can make big stable systems. The problem is, that many companies hire people who jumped onto the train by a I learned java course and then wonder why their multi million thing goes haiwire gets memory leaks or acts weirdly once it reaches a certain loc threshold.
Btw. another word to memory leaks in VM based languages. Better be prepared to face one once in a while, and better be prepared that finding this leak is one hell of a task, due to the nature of those languages, which start Garbage collectors occasionally.
If you are lucky you have a good profiler and dig into the object reference counts and memory usage patterns at various code positions at different times if you are unlucky, then you can hope that you already have enough experience in the underlying vm behavior and lanugage that you basically can get a clue where the problem is by debugging and reading the code.
I think Anders was saying basically that some people tend to go overboard throwing exceptions because they can, but not using the handler as a tool to help them fix their code so that the exception is rarely thrown in the first place?
Well the problem I see with his view is, just that some people misuse a very strong safety net, is not a reason to give them a sword to cut it.
What happens, that some people tend to misuse the safety net managed exceptions to throw too many of them. But once you give the same people unmanaged ones, they probably revert to the same amount of exceptions without catching them ever. In the end you then have a program which crashes or acts more weirdly than it would have if the language had forced you to deal with them in the first place.
Although I admire Hjelfsberg for his views and his language designs in general, I think from a persons point of view who had to program various bigger systems in the past, he is dead wrong in this. (really have to read the interview though)
The same goes for the design of properties the way he does, the property system of delphi and C# is too ambigous to normal variables to be helpful in code readability (but this is a minor issue in my opinion)
I see it from a practical point of view.
I will give you an example of something which happened to me a while ago.
I had to dock on a bigger java program to a soap server written by a guy in.Net. What happened, the soap server fell regularily on me. After a little bit of research and looking into the guys code I found out, that there were weird exceptions coming down from deep within from the subsystem the guy never caught which hung the entire server and gave me a timeout.
This is the classic case of why unmanaged exceptions are dead awful. They compromise the stability of your system once it becomes bigger. Why? Because you never know what is going to fly into your code from the deeper aspects of the subsystem.
Unamanaged exceptions are great for small systems, but once the system becomes bigger it basically is a shoot yourself into the foot trigger
The only way out if this mess in.Net in the long term I see is the introduction of aspects, which would provide a way via junction points/waypoints to nail down the various exceptions in a proper disciplined manner.
But without some kind of AOP system, forget it.
Best way to crash a server, give the programmer unmanaged exceptions.
Acutally no, there is no speed improvement in this regard,
The JavaVM currently still is a tad faster, it does better runtime optimizations as the CLR.
Where.Net can really shine is things where it can hook directly into the underlying windows dlls.
Which is rather easy because,.Net is a code once, run on some Windows versions thing.
Wheras java has to abstract in many areas.
As for the other stuff..Net added autoboxing (already in java, 1.5 is stable since today), foreach also in java since 1.5 and the in my opinion really good meta data stuff.
As for the namespaces I dont see to many advantage. Well you also have the attributes, which basically is a problem if you dont know if they are attributes because you cannot see it directly. That might be your argument, but face it buddy, ever modern ide, generates the setters and getters automatically in java, you dont code them anymore.
The coding speed is improved mainly by the autoboxing foreach and the attributes, but those are handled already.
Operator Overloading, well a matter of taste, I am not a big fan, coming from the C++ side I know about the problems this stuff can cause, if not used wisely and thoughtful.
It is pretty clear why.
Business applications are server side applications. The uptime of VM based languages simply is amazing, if you dont do any serious memory leaks (which are not that easy with GCs and weak referencing) then you can get uptimes in years even in a 1.0 release.
The main problem still is (also with a shared VM) the memory footprint, memory is handled differently. But in the long til midterm, we will probably see important server infrastructure like plain webserving, database servers mailservers and other server stuff being moved to java, the foundations are there.
It is a mentality difference.
C++ back then was designed with following mentality.
Ok we have C, we need OO, add OO, we have this cool feature in language a, we have that cool feature in language b, we add them. Now think that process going on for almost a decade.
At the end there is the result: Ok we have a huge bloated language with myriads of features, the user will deal with it and will use what he needs.
Now we have the java situation:
Ok we have C++, tons of features, too complicated, programs are too slow to develop, to insecure, to many pitfalls which basically are a burden on the coding process.
Lets strip features out so that there is a minimalist of features but the advantatages and syntax of C++ are not lost.
Now to C#, ok we have Java, our attempt to take over the language via embrace and extend was stopped by the courts. What are we going to do now. First buy the best people from Borland, second, clone the language, alter the class lib so that it is not that obvious where it came from, and add a few features from C++ again and then start the marketing drums.
Java again: Ok we have a blatant ripoff of java, they added something again from C++, now lets rethink our strategy, does this feature make sense or not to be added again.
No Hjelfsberg is totally right. The extensions are syntactic sugar. But still they are useful, because, you gain coding efficiency that way.
Autoboxing, foreach, generics are all implemented in a way not to break the byte format, but you still need less code for doing jobs like iterating lists fetching elements from data structures and so on. Day to day stuff which you used every 10th line or os.
Priority #1 for Sun was not to break the bytecode format.
Priority #2 was to ease the life of programmers
The only thing which really will make a difference on code generation level will be the meta data, this one will make life easier for the implementors and for the users of servers. Soap instantly comes to my mind with the C# like @webmethod metadata. No more post and precompilers for doing that stuff, yiehaa.
Hjelfsberg is a smart guy, although I dont share his views on unmanaged exceptions, he is dead right with his comment on this.
Sorry, Dude, but the Java VM still is faster than.Net and Mono is significantly slower than.Net (since it is just a basic VM with a basic jit and no runtime optimization)
Despite the having a slower VM, the.Net programs sometimes can be faster than java programs because they are heavily integrated into windows wheras java has to add abstraction layers for not losing portability.
But back to Mono it will probably never be able to catchup speedwise with.Net unless they move to another VM which is maintained by a dedicated team (parrot comes to mind) but then they will lose compatibility on binary level to.Net (which is not really there anyway since Microsoft plays cat and mouse with them on a classlibrary level)
Actually no, it is an app problem.
Sun has introduced weak references way back in 1.3 to cope with that problem. And I have to admit, I never had any of these problems since 1.3
But it also could be that your program simply needs a tad more ram.
Following, check out the -Xmx and -Xms parameters of your application startup file and add more ram (java fetches 32MB in without any params and fills it up before it starts the GC for the first time)
That might help.
But never count memory leaks out, they are very rare, but can happen if somebody has tangling references, pretty much the only case where the Garbage Collector can do basically nothing.
The VM itself is not flakey, I have a few servers running here, with an uptime of a year already.
Which I would consider a totally idiotic statement since C# basically is a clone of java with a few language features added and a class library, not yet as extensive as Java.
So tell me, where do you think the speed improvement comes from, which language feature, which library feature gives you the speed advantage?
Well, what quality, Brooks basically wanted to do a junk movie and he did one. The reason why Spaceballs is so beloved is, that nobody really expected anything else and the humor was fashionable at that time.
The problem is if he is going to do the same a second time, it wont work anymore.
The humor he used in spaceballs is outdated.
He will be measured against a movie which was not really that good (he had done better before and after) but became for a weird reason a classic.
Well it is just, that Far Cry for instance, was done by a small german development house with a shoestring budget.
It just happened that they sold so many copies in germany alone, that the international publishers became aware of it.
Id software, yes they have the backing of activision, but they are not big either in international standards. They just do the same game over and over again and concentrate on the engine, to keep the effort and costs down.
Not independend games, but the borders are relative in this area.
Far Cry is the closest thing you can get to a high profile commercial sort of independend title.
Sheesh, I wouldnt even improve the CPU for now, there are so many bottlenecks which basically drag the whole speed down,
Ram like somebody mentioned, the bus system and a myriad of other things.
I will give you an example. I have a pretty fast machine at home (Athlon 2400) recently I had to install one of my programs at a customers server which basically was a souped up RS6000 with a Power4 processor. Although the processor was slower than my development machine. The overall integration and quality of components and design was so good, that it literally ran circles around my machine,
(Starting Tomcat with the webapp on my machine, around 7 seconds, on this machine 1.5, and that one also was hosting an oracle 9 server and other stuff)
The current PC architecture is like having a ferrari engine in a schoolbus with breaks on. PCI-X and other stuff will help to a certain degree, but Intel does not have too many incentives to improve performance by architecture improvement unless they are forced to.
Thief is an example in the regards of environmental sounds, water fire interaction and basically sort of freeform play by being able to dump anything onto a guard so that it becomes unconcoius.
For instance the arrow system, you extinquish fire with water arrows which is an integral part of gameplay. Same goes for rope arrows.
Also if you count physics you can move things around hide behind them, or use carpets to dampen your noise.
Or if you throw something you can distract the gua rds by the noise it makes.
Thief does not use extended physics, but things like noise, moving and dumping stuff, fire water reactions and so on as integral part of the gameplay.
Id say Thief is the pefect example of the style of freeform physics allow. The designer just basically sets the situation and leaves it up to the player on how to solve them within a certain ruleset, which the implemented physics reaction limit.
Slashdot Mirror
Customer satisfaction in pre Fiorina times definitely was the cornerstone of HPs success. HP always was more expensive than the competition, but you got really what you paid for. Printers, which were expensive, but literally lasted forever. Calculators HP was king there with products which represented the best you could get at that area. Same goes for the workstation, which were top notch quality. A processor line, which rivaled with the best (PA-RISC), the list is endless. They asked for high prices, high prices were paid, because the customers knew, they werent let down by the design and durability as well as the company behind it.
Well, nowadays, HP rivals with Dell and others by putting out mediocre PCs. There printer division still is the cash cow, but given the circumstances, they will lose the market in the long term to Canon. Their laser printers already are rebranded Canon printers. PA-RISC dead on the altar of the almighty Itanium. The merger as usual basically cost the best heads in engineering on both sides which either were gone or fled because their friends were gone. HP nowadays is a pale shadow of what it used to be.
Either they go back to their core strengths, reinvent themselves in a totally different field, like IBM did, or they go the way of the dodo. Btw. they are currently trying to make a quick buck by being one of the outsourcing providers. But HP is one of the biggest outsourcers themselves, so why shall customers trust them in this regard? There are others which dont just play middlemen.
I think the only thing which will come out is, that the Nixon government was overly paranoid. A fact already known.
Ask some people who were harrassed during flights, because suddenly they landed in the terrorist database without any reason.
(No I am not talking about Cat Stevens here) Even normal Senators already had the luck.
Those who dont want to hear wont here.
Togehter is not the only one written in Java, Omodo comes to my mind as well as Poseidon/ArgoUML
Points1 and 2 are valid if you want to do high performance computing. #3 is not. If you need fast 2d rendering, use Java2d and use windows, or have a good graphics card handy and use the -Gjava2d.opengl=true flag. In both cases the hardware acceleration of your card will be used. As for fast 3d, you can have several options, either use Java3d or the JavaOpenGL bindings. Heck there have been programmed 3d games with that stuff, so if you have a speed problem there, you definitely have to check your card. (The OpenGL bindings basically just root into OpenGL with a thin layer on top of it)
Given that I am not an english speaker, I probably used the wrong term for it.
I think the best one is forced exception handling. Where java differs from C# in a big degree.
In java every normal exception which is declared has to be caught somehwhere and has to be explicitley declared at the method bodies which dont catch those exceptions themselves. This way you can see at the highest level of the system which errors can occur at the subsystems you call and you have to deal with them. Sure this causes added code. But in my experience the gain of stability you get from this is enourmous, since you have to deal with every possible program error explicitely.
In C++ and C# it is up to the programmer to catch an exception or to have the system deal with it. That basically means, a little bit of sloppyness in the underlying subsystem, and documentation, and you might see exceptions at certain situations which you never thought you would ever see, especially if the program runs into one of those 1:1000 states which should never occur, but always occur at the worsed time you can think of.
Will it? You cannot forget about several things. First they have the advantage of having the huge Microsoft marketing machine indirectly behind their backs. Secondly Iczaza is an excellent marketing guy for his projects. Third java always was and always is uncool because it is not OSS and it is by Sun (believe me, the name Sun gives you the complete hatred of the Microsoft zealots)
The main problem I see with Mono is, that if you code with that stuff you might end up with a solution which basically is dependend on the goodwill of Microsoft which has several core patents within the non ECMA parts of the library.
Mono itself is an okish platform for development, the language is nice, and what they do in the non Microsoft parts might be good enough to get out programs. Because most programs dont really heavily rely that much on speed, you need good hooks into the underlying gui toolkit and you can cover 90% of the programs out there even with a really slow language.
The main problem java had for a long time is, that it uses its own toolkit and in the beginning it was really slow (not anymore but thats another issue) So even if the language was fast enough for many purposes it ran into major problems from the user interface side of things.
So they word of mouth that java was dog slow basically came from the early swing implementations. Probably most people wouldnt even notice a java program anymore nowadays, once it is properly skinned.
Not really, it was more a collection of "cool" stuff in StrStroups mind :-)
The problem I see with this classical example is, that such an error can happen in an environment where you dont have to deal explicitely with exceptions even to the most experienced programmer, if the subsystem is not well documented or an error even deeper occurs nobody knows of.
In the end you basically to make the system really secury and stable, you have to catch pretty much every exception at the most outer rim of the system which can occur and then bring the program back to a sane state, which is close to impossible at that point, you might have tangling objects, open files, open connections and so on you dont know of and where you dont have control of (sure can happen with java too but it takes much more sloppyness to reach that state).
Well, I think you brought the whole issue to the point. Java is very easy to learn, but to program a serious system with it is, well lets say it that way, you even could use Logo and it would be hard.
People who can build enterprise size applications dont fall from the trees or you can hire a dime by the dozend, that is my experience, being almost 8 years into the field now.
The other thing is memory leaks. The VM in its current incarnations has none that I know of (and my systems seem to proof that by running months, til years without reboot or VM crash) But just because you have a GC saying that memory leaks are impossible is a myth. In the end you have to program carefully not to get them.
Rule #1 program wisely and wherever you are not sure that an object is referenced more than once and should be disposed use weak references extensively.
Rule #2 Learn patterns for heavens sake, learn OO design issue, learn about OO, AOP, Protocols and other stuff generally and keep your knowledge up to date and have a look at others code as often as possible. Also have a basic knowledge about the most important performance aspects of such systems so that you can avoid the usual mistakes which result in lousy performing servers.
If you apply those two rules you can make big stable systems. The problem is, that many companies hire people who jumped onto the train by a I learned java course and then wonder why their multi million thing goes haiwire gets memory leaks or acts weirdly once it reaches a certain loc threshold.
Btw. another word to memory leaks in VM based languages. Better be prepared to face one once in a while, and better be prepared that finding this leak is one hell of a task, due to the nature of those languages, which start Garbage collectors occasionally. If you are lucky you have a good profiler and dig into the object reference counts and memory usage patterns at various code positions at different times if you are unlucky, then you can hope that you already have enough experience in the underlying vm behavior and lanugage that you basically can get a clue where the problem is by debugging and reading the code.
Well the problem I see with his view is, just that some people misuse a very strong safety net, is not a reason to give them a sword to cut it.
Although I admire Hjelfsberg for his views and his language designs in general, I think from a persons point of view who had to program various bigger systems in the past, he is dead wrong in this. (really have to read the interview though) The same goes for the design of properties the way he does, the property system of delphi and C# is too ambigous to normal variables to be helpful in code readability (but this is a minor issue in my opinion)What happens, that some people tend to misuse the safety net managed exceptions to throw too many of them. But once you give the same people unmanaged ones, they probably revert to the same amount of exceptions without catching them ever. In the end you then have a program which crashes or acts more weirdly than it would have if the language had forced you to deal with them in the first place.
I see it from a practical point of view.
.Net. What happened, the soap server fell regularily on me. After a little bit of research and looking into the guys code I found out, that there were weird exceptions coming down from deep within from the subsystem the guy never caught which hung the entire server and gave me a timeout.
.Net in the long term I see is the introduction of aspects, which would provide a way via junction points/waypoints to nail down the various exceptions in a proper disciplined manner.
I will give you an example of something which happened to me a while ago.
I had to dock on a bigger java program to a soap server written by a guy in
This is the classic case of why unmanaged exceptions are dead awful. They compromise the stability of your system once it becomes bigger. Why? Because you never know what is going to fly into your code from the deeper aspects of the subsystem.
Unamanaged exceptions are great for small systems, but once the system becomes bigger it basically is a shoot yourself into the foot trigger
The only way out if this mess in
But without some kind of AOP system, forget it. Best way to crash a server, give the programmer unmanaged exceptions.
Acutally no, there is no speed improvement in this regard, The JavaVM currently still is a tad faster, it does better runtime optimizations as the CLR. Where .Net can really shine is things where it can hook directly into the underlying windows dlls.
Which is rather easy because, .Net is a code once, run on some Windows versions thing.
Wheras java has to abstract in many areas.
.Net added autoboxing (already in java, 1.5 is stable since today), foreach also in java since 1.5 and the in my opinion really good meta data stuff.
As for the namespaces I dont see to many advantage. Well you also have the attributes, which basically is a problem if you dont know if they are attributes because you cannot see it directly. That might be your argument, but face it buddy, ever modern ide, generates the setters and getters automatically in java, you dont code them anymore.
As for the other stuff.
The coding speed is improved mainly by the autoboxing foreach and the attributes, but those are handled already.
Operator Overloading, well a matter of taste, I am not a big fan, coming from the C++ side I know about the problems this stuff can cause, if not used wisely and thoughtful.
It is pretty clear why. Business applications are server side applications. The uptime of VM based languages simply is amazing, if you dont do any serious memory leaks (which are not that easy with GCs and weak referencing) then you can get uptimes in years even in a 1.0 release.
The main problem still is (also with a shared VM) the memory footprint, memory is handled differently. But in the long til midterm, we will probably see important server infrastructure like plain webserving, database servers mailservers and other server stuff being moved to java, the foundations are there.
It is a mentality difference. C++ back then was designed with following mentality. Ok we have C, we need OO, add OO, we have this cool feature in language a, we have that cool feature in language b, we add them. Now think that process going on for almost a decade. At the end there is the result: Ok we have a huge bloated language with myriads of features, the user will deal with it and will use what he needs.
Now we have the java situation: Ok we have C++, tons of features, too complicated, programs are too slow to develop, to insecure, to many pitfalls which basically are a burden on the coding process. Lets strip features out so that there is a minimalist of features but the advantatages and syntax of C++ are not lost.
Now to C#, ok we have Java, our attempt to take over the language via embrace and extend was stopped by the courts. What are we going to do now. First buy the best people from Borland, second, clone the language, alter the class lib so that it is not that obvious where it came from, and add a few features from C++ again and then start the marketing drums.
Java again: Ok we have a blatant ripoff of java, they added something again from C++, now lets rethink our strategy, does this feature make sense or not to be added again.
No Hjelfsberg is totally right. The extensions are syntactic sugar. But still they are useful, because, you gain coding efficiency that way. Autoboxing, foreach, generics are all implemented in a way not to break the byte format, but you still need less code for doing jobs like iterating lists fetching elements from data structures and so on. Day to day stuff which you used every 10th line or os.
Priority #1 for Sun was not to break the bytecode format. Priority #2 was to ease the life of programmers
The only thing which really will make a difference on code generation level will be the meta data, this one will make life easier for the implementors and for the users of servers. Soap instantly comes to my mind with the C# like @webmethod metadata. No more post and precompilers for doing that stuff, yiehaa.
Hjelfsberg is a smart guy, although I dont share his views on unmanaged exceptions, he is dead right with his comment on this.
Sorry, Dude, but the Java VM still is faster than .Net and Mono is significantly slower than .Net (since it is just a basic VM with a basic jit and no runtime optimization)
.Net programs sometimes can be faster than java programs because they are heavily integrated into windows wheras java has to add abstraction layers for not losing portability.
.Net unless they move to another VM which is maintained by a dedicated team (parrot comes to mind) but then they will lose compatibility on binary level to .Net (which is not really there anyway since Microsoft plays cat and mouse with them on a classlibrary level)
Despite the having a slower VM, the
But back to Mono it will probably never be able to catchup speedwise with
I use Linux you insensitive clod
Actually no, it is an app problem. Sun has introduced weak references way back in 1.3 to cope with that problem. And I have to admit, I never had any of these problems since 1.3
But it also could be that your program simply needs a tad more ram.
Following, check out the -Xmx and -Xms parameters of your application startup file and add more ram (java fetches 32MB in without any params and fills it up before it starts the GC for the first time) That might help.
But never count memory leaks out, they are very rare, but can happen if somebody has tangling references, pretty much the only case where the Garbage Collector can do basically nothing.
The VM itself is not flakey, I have a few servers running here, with an uptime of a year already.
Yeah sure... whoever has voted this insightful, should rething his voting, the poster was a blatant troll.
Which I would consider a totally idiotic statement since C# basically is a clone of java with a few language features added and a class library, not yet as extensive as Java. So tell me, where do you think the speed improvement comes from, which language feature, which library feature gives you the speed advantage?
Well, what quality, Brooks basically wanted to do a junk movie and he did one. The reason why Spaceballs is so beloved is, that nobody really expected anything else and the humor was fashionable at that time. The problem is if he is going to do the same a second time, it wont work anymore. The humor he used in spaceballs is outdated. He will be measured against a movie which was not really that good (he had done better before and after) but became for a weird reason a classic.
Well it is just, that Far Cry for instance, was done by a small german development house with a shoestring budget. It just happened that they sold so many copies in germany alone, that the international publishers became aware of it. Id software, yes they have the backing of activision, but they are not big either in international standards. They just do the same game over and over again and concentrate on the engine, to keep the effort and costs down. Not independend games, but the borders are relative in this area. Far Cry is the closest thing you can get to a high profile commercial sort of independend title.
Sheesh, I wouldnt even improve the CPU for now, there are so many bottlenecks which basically drag the whole speed down, Ram like somebody mentioned, the bus system and a myriad of other things. I will give you an example. I have a pretty fast machine at home (Athlon 2400) recently I had to install one of my programs at a customers server which basically was a souped up RS6000 with a Power4 processor. Although the processor was slower than my development machine. The overall integration and quality of components and design was so good, that it literally ran circles around my machine, (Starting Tomcat with the webapp on my machine, around 7 seconds, on this machine 1.5, and that one also was hosting an oracle 9 server and other stuff) The current PC architecture is like having a ferrari engine in a schoolbus with breaks on. PCI-X and other stuff will help to a certain degree, but Intel does not have too many incentives to improve performance by architecture improvement unless they are forced to.
Thief is an example in the regards of environmental sounds, water fire interaction and basically sort of freeform play by being able to dump anything onto a guard so that it becomes unconcoius.
For instance the arrow system, you extinquish fire with water arrows which is an integral part of gameplay. Same goes for rope arrows. Also if you count physics you can move things around hide behind them, or use carpets to dampen your noise. Or if you throw something you can distract the gua rds by the noise it makes. Thief does not use extended physics, but things like noise, moving and dumping stuff, fire water reactions and so on as integral part of the gameplay.
Id say Thief is the pefect example of the style of freeform physics allow. The designer just basically sets the situation and leaves it up to the player on how to solve them within a certain ruleset, which the implemented physics reaction limit.