|
> upgrade to P-III 850's with 512MB RAM.
Ever notice that the solution to most of Java's problems seems to be along the lines of "just throw more metal at it!"? Esp. if you happen to be a Sun customer!!! (Ducking.)
Alas, I am stuck working with J2EE and the two "optimized" VMs for some development. I can actually *feel* my life slipping away now... 
Peace!
-=- James.
|
|
|
|
|
Hey, I'm back again! Thanks for the kind words.
For the first reply - as far as high salaries are concerned, there are a few things to consider. First is the market you're in. Some cities have a lot of demand, others don't. I'm currently working in the northern Atlanta area, and it's absolutely nuts around here. Second, look at what a company is trying to do. My company is migrating from a Windows-based product line to a consolidated J2EE solution. For this kind of work, you need to know both Microsoft and Java Enterprise technologies very well. Most people have one or the other, but not both. Finally, attitude is king. Most recruiters and hiring managers don't understand this concept, but it's far more important than just technical skill. If you enjoy learning new things, and if you don't have a problem with reading through specifications, and if you're the type of person who likes to get information directly from the source, then you have the right attitude. People without this attitude tend to ask coworkers questions that could be easily answered by opening a book and reading for a couple of minutes. People without this attitude tend to cut-and-paste others' code into their own without understanding what it does first. This unfortunately happens quite often in my workplace. 
There are many other factors involved, but when I make hiring recommendations it's almost always based on domain knowledge and attitude. Hope this helps!
Now, for the second reply - yes, I agree that the solution to Java's problems are "throw more metal at it". But, if you consider the cost of a very high-end desktop relative to the average software engineer's salary, you can see why companies don't really mind. A $3000 PC is well-worth the investment if an engineer who costs the company far more than $3000 per year (  ) can be more productive.
The other thing is that Microsoft technologies are always ready to push the technology barrier. I wouldn't suggest running Visual Studio.NET and Windows 2000 Server on anything less than 384MB of RAM. Considering you can buy 256MB PC133 DIMMs for roughly $100 right now (for CAS2 fast memory, not the cheap market grade stuff), it's a good time to upgrade to 512MB of RAM anyway. Hook yourself up with a 1GHz AMD Athlon chip and motherboard for $300-400, add the RAM for $200, and you've got a screaming system for any software, whether it's from Sun or Microsoft.
|
|
|
|
|
The 'throw more metal at it' debate has a couple of variables.
If the engineer time vs. hardware cost decision only impacts one company, that's one thing. If you are producing a product intended for resale (as in you cut a CD and ship it out), then your decision also filters down to your customers, and your company's cost competitiveness.
The server-centric ASP model (as in Application Service Provider) of course changes this equation pretty dramatically, but I think many organzations are still opting to load server-based applications onto their Intranets.
David
|
|
|
|
|
> The 'throw more metal at it' debate has a couple of variables.
Of course. And the points you raise are valid, and have specific uses in the Real World.
But there is no debate going on, nor was I trying to start one. I was saying that Java's solution to something not running well is to "throw more metal at it". Notice the lack of other options, hence no debate.
> If the engineer time vs. hardware cost decision only impacts one company, that's one
> thing.
Does that assume that the engineer would be spending more time doing it is C++ than in Java? That depends greatly on the specific developers. Although many out there assume that it is true.
> If you are producing a product intended for resale (as in you cut a CD and
> ship it out), then your decision also filters down to your customers, and your
> company's cost competitiveness.
Yes, and as such, Java does have its place.
-=- James.
|
|
|
|
|
James,
Although my friends at www.sitraka.com might say that their JProbe profiler might be an option, I agree that the current state of mind is more horsepower.
In my thought about engineering cost vs. hardware cost I wasn't trying to advocate one language over another. The premise holds true for any language, I think.
David
|
|
|
|
|
> Although my friends at www.sitraka.com might say that their JProbe profiler might be
> an option, [...]
Anything that can help developers tweak every bit out of Java cannot be all that bad!
> In my thought about engineering cost vs. hardware cost I wasn't trying to advocate one
> language over another. The premise holds true for any language, I think.
Cool.
Peace!
-=- James.
|
|
|
|
|
I really find this sort of post pathetic. Knee jerk analysis.
I will not claim that Java is as fast as C++ for all cases. For some it is a bit faster, others a bit
slower. Even when comparing decent Java to decent C++ code. Overall, it probably loses by a little
bit when looking in real world data. But it is only a tool to create other tools.
Java does allow me to concentrate on what I am trying to do and get it done. Quickly. I have spent too
much time on projects fixing memory and COM interface leaks not to appreciate some of the advantages
of Java. The time saved not dealing with this bookkeeping can then go into making my code selectively
faster where it counts and refactoring for maintanence. A big win in my view.
Would I use Java for everything. NO! But then I also use more than a screwdriver when working around
the house. If you refuse to look at other tools, everything gets screwed. (Sorry, I couldn't help myself)
|
|
|
|
|
> I really find this sort of post pathetic. Knee jerk analysis.
Knee jerk reactions are from those that are not trained well. Not me.
> I will not claim that Java is as fast as C++ for all cases. For some it is a bit faster,
> others a bit slower. Even when comparing decent Java to decent C++ code.
Which cases show Java to be faster than C++? I am sure that in order to back up such a statement, you would be willing to post links to examples, code, etc. Right?
> Overall, it probably loses by a little bit when looking in real world data.
Try a LOT.
> it is only a tool to create other tools.
Good point! Hence my post. Too many people use Java for processing intensive, or performance critical applications. To do such is a bad idea. Some Java SDKs *still* have disclaimers in them about not using them for mission-critical applications. You want to write a little game to play checkers on a web page? Fine. You want to use it in a financial installation for real-time statement generation? Not fine.
> Java does allow me to concentrate on what I am trying to do and get it done.
I would have to disagree there: Java helps developers to NOT concentrate on what they are trying to do. Why? Because it reduces the responsibility placed on the developer. They do not have to concentrate on "delete"ing "new"ed memory, they can just fly around their code, using Java's "new" with no concern for what the implications are.
God forbid these "developers" start using C++ with a broken understanding of what "new" is, and how to use and NOT use it.
> I have spent too much time on projects fixing memory and COM interface leaks
> not to appreciate some of the advantages of Java.
Then you should also appreciate what Java and VB can do to the development community at large. We end up "dumbing-down" software development. Dumber developers doing stupid things like leaking resources.
> [...] go into making my code selectively faster [...]
Always decent bait.
> Would I use Java for everything. NO! But then I also use more than a screwdriver when
> working around the house. If you refuse to look at other tools, everything gets screwed.
Again, something that matches my original "pathetic", "knee jerk" post. "Because dumbasses out there fall into the "Java trap'", and start thinking that Java is the solution to everything. Take a look around at how many companies have embraced Java as a serious development platform, and maybe you will understand my post a bit more.
Peace!
-=- James.
|
|
|
|
|
>> Java does allow me to concentrate on what I am trying to do and get it done.
> I would have to disagree there: Java helps developers to NOT concentrate on what they are trying to do. Why? Because it reduces the responsibility placed on the developer. They do not have to concentrate on "delete"ing "new"ed memory, they can just fly around their code, using Java's "new" with no concern for what the implications are. God forbid these "developers" start using C++ with a broken understanding of what "new" is, and how to use and NOT use it.
Dumb developers are just dumb developers: there is no helping that. But a good developer can desire the removal of things _that are irrelevant to the task_. Managing memory when there is no need to do so is a purely _bookkeeping_ task. For many (not all) programs, it is irrelevant. I use smart pointers in C++ all the time for the same reason; I don't have to worry about freeing memory -- it's done for me. A smart developer doesn't want to waste time on things that are unnecessary.
>> I have spent too much time on projects fixing memory and COM interface leaks not to appreciate some of the advantages of Java.
> Then you should also appreciate what Java and VB can do to the development community at large. We end up "dumbing-down" software development. Dumber developers doing stupid things like leaking resources.
A language should be complex to remind you that software development is complex?? This is not a good argument.
>Too many people use Java for processing intensive, or performance critical applications. To do such is a bad idea. Some Java SDKs *still* have disclaimers in them about not using them for mission-critical applications. You want to write a little game to play checkers on a web page? Fine. You want to use it in a financial installation for real-time statement generation? Not fine.
This is silly. There is a wide range of software development between writing a UI and real-time processing. Anyone doing real-time processing would have performance requirements that could be checked with a proof-of-concept (in Java or C++).
Let's get down to the bottom line: C++ developers are old-school. They like knowing that their implementation is the fastest, that they aren't using memory when they don't need to be, and that their code is the smallest and tightest possible. The thing now is, huge amounts of CPU, disk and memory are available to most clients. e.g., it's not a big concern if an app uses 10MB, 20MB or 30MB when your user has 128MB+ of RAM.
Improvements in software development are made when you can offload more bookkeeping tasks onto the machine and less onto the developer. This is the trend, and it is a good one. Low-level unnecessary tasks drop away and you can concentrate on developing your high-level concepts.
|
|
|
|
|
> Dumb developers are just dumb developers: [...] Managing memory when there is
> no need to do so is a purely _bookkeeping_ task. For many (not all) programs,
> it is irrelevant.
Remember that this discussion is about Java in particular. Behind the scenes, Java uses the heap for just about everything that is allocated. Check heap usage on a running VM. (Also, as such, the Java VM is "managing memory when there is no need to do so"!) Not being concerned about, or worse, not even being *aware* of, such things that are FAR from irrelevant, is further proof of "dumb developers". Some would think that memory management it is more than "irrelevant": anything that can bring down an application and/or a system sounds pretty damn important to me! I would hope the same is true of most professionals out there. And as I said before, Java *does* have its place for some (not all) programs. The key is knowing EXACTLY where that place is.
> I use smart pointers in C++ all the time for the same reason;
But sounding like a somewhat able C++ coder, there is a good chance that if you could not use them for a particular project, you would be able to cope with it. Is the same true of Java developers that need to "delete" objects all of a sudden? Think about it.
> A language should be complex to remind you that software development is complex??
> This is not a good argument.
Read my posts again. I never said C/C++ was complex... Anyone that things so SHOULD be using Java, just so they do not hurt themselves, IMHO. What I was trying to say that training people in a languages that hides such things from them makes those people ignorant of the implications of that "thing". Hence, developers become "dumber" as a result.
> [Re: Java SDK disclaimers] This is silly. There is a wide range of software
> development between writing a UI and real-time processing.
Right. Again, as I *have* said before: Java DOES have its place. The problem is that lots of companies are jumping on Java, thinking that is the solution to everything, the same way they did a few years ago with VB and COM.
> Let's get down to the bottom line: C++ developers are old-school.
Luckly, with age comes experience (and usually knowledge). And, us "old-school"-ers are using a language and development tools that are more mature when compared to their Java counterparts.
Some of us have also experienced Java development first hand. I had the "pleasure" of using Java for development about 3-4 years ago when everyone thought that "thin client" was the wave of the future. The wave collapsed, I left Java behind. As a result this young old-school developer knows the places for Java.
> They like knowing that their implementation is the fastest, that they aren't
> using memory when they don't need to be, and that their code is the smallest
> and tightest possible.
Hence, C++ should be used for applications where speed and size are important. As I said, Java people fall into the "Java applications are just as fast as C/C++" lie, and do not understand that "Poor performing Java apps are easy to write." You have just argued in my favor, thanks!
> The thing now is, huge amounts of CPU, disk and memory are available to most
> clients. e.g., it's not a big concern if an app uses 10MB, 20MB or 30MB when
> your user has 128MB+ of RAM.
Such is the cry of those that have never experienced development on smaller platforms, and those that believe throwing more metal at something is a solution to a problem with it. "Hey, if it runs like sh*t, we can just wait 6 months for the new CPUs to come out." Uh, no.
Remember that there are still "smaller" platforms out there. Also, the average user's system is usually less featured than your development box. That is another usually forgotten fact.
Peace!
-=- James.
|
|
|
|
|
>> I really find this sort of post pathetic. Knee jerk analysis.
> Knee jerk reactions are from those that are not trained well. Not me.
Right. How much Java training do you have? I wouldn't feel qualified to comment on Smalltalk since
I don't use it regularly. How much do you use Java?
>> I will not claim that Java is as fast as C++ for all cases. For some it is a bit faster,
>> others a bit slower. Even when comparing decent Java to decent C++ code.
> Which cases show Java to be faster than C++? I am sure that in order to back up such a
> statement, you would be willing to post links to examples, code, etc. Right?
A coworker had created a simple test of C++ IO and std::map performance to test expected performance
for an update to some code in one of our products. It read in a text file of '0' padded ints and created
a map of these as wstrings to their integer values. Then some random lookups and deletes, adding the
deleted values to a list. This was actually very similar to something that modeled what the final code
would do.
Since I have been after the folks here to look at Java more closely, I also implemented ith same in it.
The results on a 198M PIII 600mHz with 400K elements were:
VC++ 6.0 sp4 Java 1.3 (Sun)
read And create Map 247.3 sec (yes 247) 4.23 sec
Empty loop creating 3.776 sec .4 sec
key
lookup, add and remove 8.141 sec 2.073 sec
We changed STL implementations and brought the VC times down to 7.03, 2.123 and 5.348 respectively,
but Java still performed better in this test. I do not like Micro-Benchmarks and am only posting this to
confirm that for SOME tasks, Java can outperform C++.
I also remeber a CN2 benchmark that had been on the web showing similar results. I cannot find it at
the moment. I will look on some of my home machines since I think I played with it a couple years back.
>> Overall, it probably loses by a little bit when looking in real world data.
> Try a LOT.
I'm sure you would be willing to post links, right?
>> it is only a tool to create other tools.
> Good point! Hence my post. Too many people use Java for processing intensive,
> or performance critical applications. To do such is a bad idea.
Even here the difference in performance is closing. But often C++ will be the better choice.
> Some Java SDKs *still* have disclaimers in them about not using them for mission-critical applications.
The lawyers don't want a failure of a VM in a reactor to put them at risk. Based on the way VC messes up
code with optimizations enabled, they should also have a disclaimer
>> Java does allow me to concentrate on what I am trying to do and get it done.
> I would have to disagree there: Java helps developers to NOT concentrate on what they are
> trying to do. Why? Because it reduces the responsibility placed on the developer. They do
> not have to concentrate on "delete"ing "new"ed memory, they can just fly around their code,
> using Java's "new" with no concern for what the implications are. God forbid these "developers"
> start using C++ with a broken understanding of what "new" is, and how to use and NOT use it.
Is the purpose of your program memory management? NO. I rarely WANT to worry about that. Not
having to worry about the "implications" is a blessing. And as far as having a "broken" understanding
of what new is, Java just has a different one. They are different languages after all.
> > I have spent too much time on projects fixing memory and COM interface leaks
>> not to appreciate some of the advantages of Java.
> Then you should also appreciate what Java and VB can do to the development community at large.
> We end up "dumbing-down" software development. Dumber developers doing stupid things like
> leaking resources.
Is this real?? Any language can be used stupidly. I once worked tech support for a comipler vendor
and had to explain to a user with 10+ years experience that you had to call delete when you new'ed
something.
Lisp has a GC. Are all Lisp programmers stupid? Physists now use calculatorsand computers instead
of doing calculations in their heads. Are they now dumber because of it? Have a tool and using it
lets you concentrate on other skills. Like good design.
>> [...] go into making my code selectively faster [...]
>Always decent bait.
And this means???
>> Would I use Java for everything. NO! But then I also use more than a screwdriver when
>> working around the house. If you refuse to look at other tools, everything gets screwed.
> Again, something that matches my original "pathetic", "knee jerk" post. "Because dumbasses
> out there fall into the "Java trap'", and start thinking that Java is the solution to everything.
And others refuse to accept that Java has a place. Both sides are wrong.
> Take a look around at how many companies have embraced Java as a serious development
> platform, and maybe you will understand my post a bit more.
I know plenty of people in many companies working in Java. So I still don't understand the post.
>Peace! -=- James.
Best Wishes also.
Otis
|
|
|
|
|
> Right. How much Java training do you have? I wouldn't feel qualified to comment
> on Smalltalk since I don't use it regularly. How much do you use Java?
I would not comment on things that I do not know about (to do so would be stupid), and that should be *enough* for everyone else to know. But just for those that do not know any better to not ask, here is a small list:
o Learned Java over 4 years ago.
o Implemented several small scale applications, like chat servers and clients (thin). Both browser-hosted and standalone.
o Implemented some some other "utility" applications for use during development.
o Studied and implemented several multi-threaded Java applications, employing techniques found in some older Java "performance" books, more recently "High-Performance JAVA Platform Computing" (a really good book, BTW).
> A coworker had created a simple test of C++ IO and std::map performance [...]
I hope you used a good STL implementation. And stored pointers to the strings in the map, and not references, so that the objects would not be copied each time the map had to reallocate (people make that mistake all the time). (And I noticed that I misphrased my comment. I am referring to C++ code that you control, not libraries that are written by Lord-knows-who, and perform Lord-knows-how-bad.) OK... Good. We have one "link" so far.
> I'm sure you would be willing to post links, right?
Be wary of who you choose to fence with, and attempt to copy concepts from.
http://www.sosnoski.com/Java/Compare.html
http://sprout.stanford.edu/uli/java_cpp.html
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf.html
http://www.dl.ac.uk/TCSC/UKHEC/JASPA/node8.html
(Some of the above links show Java to be better in some areas, just to show that I am not only posting the links that agree with me.) But here is the best "link" of all: is anyone out there using a Java VM (and matching SDK) that was actually written in Java for anything "real" (so-called high performance)? Ever wonder why?
> The lawyers don't want a failure of a VM in a reactor to put them at risk.
Now I know you are not saying that the disclaimer should just be ignored. Which brings me back to what I said before. Does everyone even know that the disclaimers are there, let alone pay attention to them?
> Based on the way VC messes up code with optimizations enabled, they should
> also have a disclaimer
Maybe. Or you can turn them off, and do not try to have the compiler fix some of your mistakes for you.
> Is the purpose of your program memory management? NO. I rarely WANT to worry about that.
True, the purpose of few programs is Memory Management. I never said that the purpose of code would be Memory Management. But anyone that is concerned about performance should be concerned about how their code is (mis)using memory.
> And as far as having a "broken" understanding of what new is, Java just has
> a different one. They are different languages after all.
A "Broken understanding" with regard to how it works in C++. And yes, different languages; with different features, concerns, and USES.
> Is this real?? Any language can be used stupidly.
And as we have recently seen, anybody can be stupid as well.
> I once worked tech support for a comipler vendor and had to explain to a user
> with 10+ years experience that you had to call delete when you new'ed something.
Entropy abounds.
> Lisp has a GC. Are all Lisp programmers stupid?
People are not trying to use Lisp as the solution to all development the same way that some people and companies are embracing Java. That is what this thread is about. Lisp has its place, and so does Java.
> [Re: bait] And this means???
Lookup its meaning WRT postings on the Internet.
> And others refuse to accept that Java has a place. Both sides are wrong.
Which is why I have said, many times already, that Java does have a place. The trick is knowing where the line between using Java for something, and using C++ for something, is drawn (and in some cases blurred).
> I know plenty of people in many companies working in Java. So I still don't
> understand the post.
Are these people trying to use Java as a be-all-end-all solution? If not, you are lucky. If so, you should understand the problem a bit more. If you fail to understand any of my earlier posts, the fault lies with you. I cannot explain things any simplier than I already have.
> Best Wishes also.
And to you as well.
Peace!
-=- James
|
|
|
|
|
Ok, I guess we can end this. My reason for posting originally was that the original post
gave me the impression that it was saying Java was SLOW and unusable for anything.
I now see that that was not your intension since you say that Java has a place and
even help me confirm its performance with a couple of your own links. Thanks for that,
I rarely have time to look for articles on topics like that.
Like I said originally, Its all about picking the right tool.
Oh, when do maps reallocate? Hash_maps might need to rehash but I thought that the
standard structure for a map was a tree. You might have to create new nodes but you
shouldn't need to realloc. I'll have to take a look. performance seemed ok just using a
map<wstring,int> since then we don't have to create a smart_ptr<wstring*> and a
comparator for them. Might save a bit if wstring(const& wstring) is slow.
Signing off for now.
|
|
|
|
|
I haven't written many computationally expensive programs, so optimization isn't that needed for me, except once when I used converted to using quadtrees instead of a huge linked list for objects in my 3D engine. That made an entire world of difference.
I also have problems doing optimizations themselves, most of the time my optimizations do nothing to increase speed.
|
|
|
|
|
You need to make sure you optimise areas that are actual bottlenecks, otherwise the effect will be minimal.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Hello!
Third option should be rather
"If it works, and no one complain about it, then OK. That is good enough for me."
It is fine to try write best possible code, but in the real world it is sometime really hard to find time to rewrite working code for optimization, if there is no requests (from customers, from management) for this.
SlavoF
"I hear and I forget. I see and I remember. I do and I understand."
--Confucius
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
