----- Original Message ----- From: "Anne Thomas Manes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 02, 2003 11:46 Subject: RE: standalone vs. servlet
> Dennis, > > I absolutely agree with you regarding application code. Using well-optimized > code and a good application server, you ought to be able to make a Java > application run at a speed that's reasonably comparable to a C++ > application. There's a bigger difference, though, when it comes to > infrastructure code. In my experience, SOAP *platforms* built with C++ run a > lot faster than those built with Java. Just as you won't find a J2EE app > server that can compare with Tuxedo. Do you think that is an artifact of the C++ parsers, like MSXML4, actually being pretty impressively good compared to those in the java space? Or is it some other reason, like the dev team spent more time on tuning. Getting back to Denis' observation: yes, badly written C++ apps can have their own problems, esp. around concurrency, and as memory leaks tend to show up faster, there are big barriers to writing 7x24 systems. Plus you need to have people on the dev team who know the diff between strcpy() and strncpy(), and how to use the latter properly. That said, friends of mine do 7x24 stuff for telcos, and I have dabbled in the performance area. if you really know what you are doing, and know the target system (esp CPU cache properties and how its multiprocessor cache coherency works), and can insert prefetch instructions into your source, you can do stunningly fast code, at the risk of creating a maintenance nightmare later on, by virtue of the aggressively unsynchronised code you've just written. But perf tuned java has the same problem -if you write code knowing that int reads and writes are atomic and dont need syncing, and someone chanigns that field to a long, everything goes pear shaped. -steve
