Using Java as opposed to another language where performance counts

[Doug Slattery]

Hi Guys,

I've started this new thread based on the last couple of responses from
this
thread.

Being relatively green to Java, but having a strong 'C' background, I'm wondering why Java would be considered over another language ('C' in my case) where low execution time is a factor.

My reasons for asking this are explained in the above link in my first reply.

Aloha,
Doug

[Stan James]

In many situations Java runs just as fast as C and there are some special situations where semi-interpreted byte-code will run faster than native code. If you think your application is one of the exceptions, maybe code both and try to prove it.

So if performance is not a large enough differentiator to make the language decision alone, what else does Java bring to the table?

One of the key goals was to make Java familiar enough that C folks could migrate easily, but to leave out the many opportunities C gives coders to mess up. Garbage collected memory is the biggest example, but not the only one. Java can also give a better ratio of business to housekeeping. I like classes that talk about nothing but insurance and Java often lets me cut a lot of the other clutter out of the code.

And then there's OO. You've fallen into a crowd that likes it here and we could talk for hours (and hours) about why. It's a big selling point over C, and even the way C++ did it. (You'll find crowds just as enamored of other paradigms elsewhere, but not so much here.)

[Doug Slattery]

Thanks for the reply Stan.

That seems to be the consensus from the replies on the other thread.

Aloha,
Doug

[Pat Farrell]

I wrote crypto code for CyberCash last century. Its generally considered one domain most hyper sensitive to performance. As a giggle, I coded some of the serious stuff in java and plugged it in. (This was pre-JIT, etc.) and while the crypto algorithms were much slower in benchmarks, they made no difference at all in an Internet commerce transaction's response time. The time was spend waiting for the user to type data, network transmission, finding the user in the database, checking inventory, etc.

All code can be made faster, the trick is figuring out when it is worth optimizing.

[Chandra Sekar]

The choice of language depends on the type of application. If it a server side application or an application which once started will run for a long time, Java is a good choice. Hotspot can provide lot of improvements in these scenarios.

But if it a desktop application or an application which runs for short periods of time, native languages would be better choice. Java VM is notorious for its long startup times.

[Gregg Bolinger]

Originally posted by S.C Sekar:
But if it a desktop application or an application which runs for short periods of time, native languages would be better choice. Java VM is notorious for its long startup times.

FUD. Modern JVM startup times (1.5+) are impressively fast.

[Chandra Sekar]

Dear friend, again there is no FUD here. Even a kid will find that Netbeans and Eclipse take more time to start than Visual Studio.

JEdit takes more time to start than kwrite, kate or even emacs.

I know Java applications run faster on 1.6 than in 1.5 and in faster in 1.5 than in 1.4. But it is never really faster than the native counterpart.

But Java does provide on big advantage even for desktop application development. It makes threading and networking very simple.

[Peter Chase]

Originally posted by S.C Sekar:
Even a kid will find that Netbeans and Eclipse take more time to start than Visual Studio.

Yes, but a kid wouldn't be able to determine whether that observation actually meant anything about the languages. And I have some doubts as to whether you would, either. Certainly, you've so far shown no hint of an analysis that would lend weight to your arguments.

When comparing big applications like IDEs, there are huge numbers of architectural and other choices that can affect start-up time. Language is one of them, for sure, but only one of many.

Originally posted by S.C Sekar:
Dear friend, again there is no FUD here.

There sure is. It is true that Java is notorious for slow start-up, but notoriety does not prove guilt. For instance, many historical figures' notoriety is partly or entirely unjustified, having been exaggerated or just invented by their enemies. That's true, to an extent, here.
[ October 02, 2007: Message edited by: Peter Chase ]

[Chandra Sekar]

I knew such arguments would come up. That's why posted about JEdit too. You have not told anything about it.

For your information I'm myself developing a desktop application using Java. But the reason I chose it was threading and networking facilities. If Java is going to become fast on all platforms/OS (quickstarter in Consumer JRE is not for all platforms/OS), I'll be the happiest and will take back every word I've told.

[Chandra Sekar]

Could you please provide hints of your own analysis comparing start up times of a Java and native applications of similar functionality when started for the first time after the system was booted?

[Peter Chase]

I very carefully didn't say I'd done such analysis. I didn't say that Java was as fast or faster to start up, either. What I said was that neither your "a kid could see..." nor your "notorious" arguments were well-constructed.

Out.

[Chandra Sekar]

You still have not said anything about the JEdit case. Are you accepting the fact there?

[Ulf Dittmer]

The startup time or performance of a particular application proves nothing about the general performance characteristics of the language it's written in.

What are you trying to show by comparing apples to oranges?

[Chandra Sekar]

The startup time or performance of a particular application proves nothing about the general performance characteristics of the language it's written in.

That's why I said Java is good for server applications where start up time doesn't matter as much as the performance after startup. Java is many a times faster than native languages for these cases.

But no user will choose a Java desktop application taking 6-10 seconds to start when a similar native application takes less than a second to start.

[Gregg Bolinger]

Java is many a times faster than native languages for these cases.

Well, that's not really true either as a blank statement. You are making way too many assumptions.

[Nicholas Jordan]

[Doug Slattery:]   I was using the Search First etiquette from the FAQ to not hijack this thread.

Dunno, the moderators watch this stuff so if there was any question, they would have spoke up by now. We do not have a lot of rules at Java Ranch, the only one seems to be using a realistic displayed name or the joking gets out of range to fast and too quickly.

[Doug Slattery:]   As this information is from my former employer, I no longer have access to it. However, after rewriting the cgi's in 'C', performance did noticeably improve under the same and heavier loads as the number of users accessing the site increased over time. I should also mention the server is Linux based (RedHat ES3) quad processor system using Apache with 16GB ram.

Then lets start off on our own work, in hopes of learning something or whatever. Let's take Stan's I like classes that talk about nothing but insurance and Java often lets me cut a lot of the other clutter out of the code.
as our development model where my ideas are too far-out and not efffective at providing study cases. Insurance is sufficiently developed as a work area that we may use it as our study model when there is no access to employer's work.


[Doug Slattery:]   Understood, but for my situation, afaik threading isn't necessary. Every request is first authenticated against session information stored on the server that gets created when a user logs in. There's a split at this point depending if the authentication is good or not. Assuming it's good, more than likely access to the database would happen. When that comes back, an html generator would dynamically create the response page with the results of the query. Pretty basic stuff.

Threading is crucial to server power, where performance counts.

Threading is where Java gets its power in a server role, see discussion a few paragraphs later..

[Doug Slattery:]   Could one of the possible causes of the reported slowness be contributed to the overhead of JIT? Another possibility I'm unsure of is doesn't the JVM have to run before the Java program, thus adding more overhead? Could the problem also be inherent in the Java language itself?

This is a potentially involved question, but is really basic. Disk heads are slow, and they are massive compared to something that is already in L-2 or the equivalent in commercial equipment. This is normal design consideration in application concepting. There is a time-cost, dollar-cost that has a lot to do with what a business is trying to accomplish and what sort of budget they have and who is running the company. For something like Tomcat, you are likely to achieve time-responsiveness per dollar-invested under heavy server loading that will outperform competing technologies for dollar invested, but it has a great deal to do with where Alice is working. The problem, if any, may be inherent in the Java language itself but what problem ? Some java appps run on cmos circuitry on consumer devices and that just means slow. It drives me nuts. Please provide an abstracted modeling of what you mean by slow that does not involve any proporietary nomenclature.


[Doug Slattery:]   I understand about writing efficient programs. That and security are to of my top pet peeves. I've done lots of reading on optimizing code and optimizing compilers (in 'C' that is). I'm still a little green when it comes to Java, which is why I'm asking these questions.

Java Ranch is for beginners.

[Doug Slattery:] I'll respectfully disagree and elaborate a bit more that my opinion is based on using Java for cgi programs on a high traffic web server considering JIT adds overhead (and maybe other things as well) as opposed to a stand alone executable.

Don't worry to much about being respectful to me, I just mis-interpret it as a challenge-response protocol. I think we need to examine your position here, under the watchful eye of Master Wong, who may have already responded to this point subsequent to its posting. Using java for cgi programs ? Do what, we need to back up to page one. CGI - common gateway interface, launches a new process for each request. If the process has already been requested a few times, the pattern will already be somewhere in cache betweent the physical disk heads and executable storage, ususally called RAM, but in some operating sceanrio may be pretty much anything a machine designer can come up with. (the reload from persistenet media)

Tomcat applicatioins - along with my approach to most applications - goes through a page load the first time it is accessed through what we think of as a url. IOW - A server request launches a Thread to handle, service, respond to something that comes in over the wire, then it just sits there, in RAM, and can be re-entrant. The Servlet book by Marty Hall discusses this in clear wording.

This seems really simple to me, I am a mechanic by nature and why people miss this is difficult for me to grasp. Since you write code commercially, it should not be difficult to envision kernel module inet daemon being writeable, if there was the hardware to support it, such that any new request gets assigned to an idle processor bus and this is where the power ( or potential power ) of java really comes in to shine. Much of C was orginally implemented to do just exactly this kind of work, but evolved into a camp where it was not considered etiquette to examine anything but what they want you to examine. Do you realize the constant keyword binds to the left, thus it is char const * const c, (constant pointer to a constant character), not const char c. Many optimizations are too complex for humans, compilers and the runtime systems can do a better job, they can instrument the code and fix what is really slow, not just what the programmer thinks is slow. But this idea of dispatching threads to processors seems so simple and obvious to me that why any accomplished coder would have trouble grasping it escapes me and is more a study in human engineering than in code authorship.

Telcos use backscatter in the line as a very limited, micro-cache that runs as a sort of control and feedback "executable" The question has a lot to do with bench-technician areas that are often dismissed in java discussions. I use Java, having made the transition at New Team Leads request, and have now made it my primary design linquistic. WE could, as a consequence of our discussions, enter work of a Java that is concepted to divest legacy calls into 16-bit single threaded dlls, control characters in the input stream and choke point buffers that are not up to the work that an insurance company data processing machine would inherently be capable of. Ever heard of a Hydra ?

[Doug Slattery:]   I was self employed for 8 years and have moved a lot of iron my friend.

Silica ? The cases are made of iron (with carbon, iron becomes caseworthy)

[Doug Slattery:]   I'll agree with you there. I do find it more convenient to use over 'C' in a lot of cases (device drivers excluded).

It's really a design decision, intel decided to force all drivers to be written in Java.

[Doug Slattery:]   Although, I doubt that Java can run in a "true" kernel (operating system that is) as it stands today.

The protected mode architecture begs for a ringed design paradigm where Java could take a protection role such as that described in the language concepting by Gosling. See Pentium Pro Family Developers Manual, Voume 3: Operating Systems Writer's Manual. Chapter Two: SYSTEM ARCHITECTURE OVERVIEW
[ October 03, 2007: Message edited by: Nicholas Jordan ]

[Nicholas Jordan]

[S.C Sekar:]   But no user will choose a Java desktop application taking 6-10 seconds to start when a similar native application takes less than a second to start.

Not so, in fact such Bloated Code Hogs are demanded by many users, who then go home and watch Dr. Dolittle 3 on flat-panel screens as described by Orwell and others.

I have much to say about these people, most of it negative.
[ October 03, 2007: Message edited by: Nicholas Jordan ]

[Doug Slattery]

Hi Nicholas,

Threading is crucial to server power, where performance counts.

Agreed in most cases except mine. The cgi operations are serial in nature. The cgi first has to (after authenticating the request) pull off the form variables. Next, generate a database query and finally generate a response page based on the results of the query.

This is a potentially involved question, but is really basic. Disk heads are slow, and they are massive compared to something that is already in L-2 or the equivalent in commercial equipment.

However, JIT runs after the classes have been loaded from cache/disk, right? The load overhead is unavoidable to both executables and JITs, so that's a mute point.

Some java appps run on cmos circuitry on consumer devices and that just means slow. It drives me nuts. Please provide an abstracted modeling of what you mean by slow that does not involve any proporietary nomenclature.

Running in cmos!? What an awful design decision. It must have something to do with cost I suspect. CMOS itself is a slower memory device compared to dram, and in most designs is used for data storage. It's also slower because it's not L2/L4 cached. I don't see why anyone would decide on cmos as opposed to (ep)rom for code.

Let's see if I can clarify slow... The contract for the project had one of its requirements to be that the request-response time to be five seconds or less. Of course, there was an exception clause for events out of our control such as high traffic in the internet cloud perpetuating a response time. The customer reported access times to far too frequently exceed the five second limit. After porting the cgi's to 'C', over a period of time, the customer reported access times much more reasonable, although, occasionally to exceed the five second limit. The five second limit was the slow determiner.

Using java for cgi programs ? Do what, we need to back up to page one.

Not for my understanding. That's old news .

Do you realize the constant keyword binds to the left, thus it is char const * const c, (constant pointer to a constant character), not const char c.

Yes, but the compiler will let you do it both ways

Ever heard of a Hydra ?

My former boss comes to mind

Silica ? The cases are made of iron (with carbon, iron becomes caseworthy)

I know, it's part of the entrepreneur's vernacular.

It's really a design decision, intel decided to force all drivers to be written in Java.

Since when? And why? They manufacture cpu's, not operating systems. All the drivers (and TSR's) I've written have been in 'C' and Assembly. If you're referring to portable/handheld devices, ok, that's not my turf.

Aloha,
Doug

[fred rosenberger]

JEdit takes more time to start than kwrite, kate or even emacs.

I am not really qualified to discuss performance, startup time, efficiency or the likes. I have no hard data to support - or disprove - either case.

However, this statement to me sounds like your saying "my table saw takes more time to start than my hand saw, so clearly I should use my handsaw for everything."
[ October 04, 2007: Message edited by: Fred Rosenberger ]

[Chandra Sekar]

Comparing Table Saw and Hand Saw is very different from comparing JEdit and Kate.

[Ulf Dittmer]

Originally posted by S.C Sekar:
Comparing Table Saw and Hand Saw is very different from comparing JEdit and Kate.

Are you saying JEdit and Kate are even further apart than a table saw is from a hand saw?

[Chandra Sekar]

Ulf, if that is what you'd like to believe to make yourself happy, you may interpret it that way. But I never meant that. Any day, the features offered by the basic install of JEdit and Kate are pretty much the same.

[Gregg Bolinger]

I think the point that Ulf is making is that both are saws and both are designed to cut things however, they are meant to cut different things. A power saw being able to provide more power. In saying that he's saying maybe JEdit is meant to provide more power for editing than Kate and therein could lie the differences that cause JEdit to take longer to start.

Whether or not that's really the case is a different story. At this point I'd concede that yes, Java apps take longer to startup than binary applications. It's getting better but the fact remains that anyone who really sees this as a negative aspect of Java has a lot to learn.

[Chandra Sekar]

Finally someone has accepted that Java takes longer to start. But, I hope that open sourcing of Java can help in its improvement as more people look into the code.

[Jesper de Jong]

I was at JavaPolis (the biggest Java conference outside the USA) last year in December, and there were some people from Sun there talking about what we can expect in the next Java releases from Sun.

One of the things they were talking about was speeding up the JVM start-up time.

If Java wants to be a serious competitor for Flash for example, it should be just as easy to download and install Java as it is to download and install the Flash plug-in and the JVM should also start up very quickly, just like the Flash plug-in.

In a coming update of Java 6 (update 3 or 4, due in January 2008), Sun plans to make the JVM more modular, which means it will be able to start up much faster, because it would only have to load a few small parts to get up and running. Other modules would then be loaded only if necessary.

So Sun definitely knows that the JVM start-up time needs to be improved and they are working on it.
[ October 04, 2007: Message edited by: Jesper Young ]

[Chandra Sekar]

They are working on it using a disk cache mechanism. But only for the windows platform.

[Ulf Dittmer]

Originally posted by S.C Sekar:
Finally someone has accepted that Java takes longer to start.

I see nothing in this thread where that was ever under dispute. The point a number of people were trying to make is that you can't compare the startup time of different applications, because those may or may not be doing different things at startup.

The point that was being made was that the JVM starts up very quickly these days, certainly much less than the 6-10 seconds quoted earlier. (I just verified that a Java desktop application can have a GUI up and running in about 2 seconds on a machine that's not very fast.) Some applications may choose to do all initialization before showing a GUI and becoming responsive, which will lessen the perception of a fast startup; others may make different choices.

if that is what you'd like to believe to make yourself happy, you may interpret it that way. But I never meant that.

I rarely use beliefs when I'm trying to understand what someone else says, nor do I like to have interpret. That's why I asked for clarification.

[Chandra Sekar]

AT this I also want to make a confession, 6 - 10 second is not for all applications. I based it on running a desktop application developed using Java and a similar native application. This 6 - 10 seconds is not constant. No one can ever expect Netbeans to start in a same time a Sun Download Manager.

I also, think this thread must come to an end. Again, I'm not here to spread FUD. I'm just putting forward constructive criticism.

[Jesper de Jong]

Originally posted by S.C Sekar:
They are working on it using a disk cache mechanism. But only for the windows platform.

Not only a caching mechanism; there is going to be a Consumer JRE which is much more than a caching mechanism to make startup time shorter.

[Chandra Sekar]

Jesper, Quickstarter, which uses disk caching is the primary method used to improve startup time.

Consumer JRE, has many other improvements for deployment and yes there is java kernel which is both for deployment and stratup. But they are not as important as quick starter. Java kernel is just a way to reduce initial download size, so that applets run faster when a new version is needed.

[Nicholas Jordan]

[Doug Slattery:]   Hi Nicholas,
I prefer to be called Nick in routine, casual discusion.

[Doug Slattery:]   Agreed in most cases except mine. The cgi operations are serial in nature. The cgi first has to (after authenticating the request) pull off the form variables. Next, generate a database query and finally generate a response page based on the results of the query.
This is why I brought this seemingly fine point up. It is discussed in the book cited about Servlets. You can do all of this in a multi-threaded fashion, provided you take definite, proveable steps in the allocation of a session id, user-id and track these to which response form field came from which session and are they logged on and a hydra of issues that becomes relatively do-able after deep contemplation of several Threading issues - all of which have been addressed in the last six months in Threads and Synchronization

They are very dicey, until you get several issues grounded. Some of these are rapidly solveable with static constructors. Others have a need for a central instance or static dispatcher that passes requests off to some section of code that will handle the ..... the several times that I have tried to code this, it gets stuck on finding out how Sockets work, and right now my concepting is to do it all with session id-s and user-id-s and form responses.

static volatile int sessionID;static{++sessionID}

Marty Hall discusses these effectively in the Servelets book.

Properly written, they scale better than cgi. I am now convinced that the Java VM will dispatch to processor bus(n) effectively if the code is written to spot identifiable candidate instruction streams for parallelizing. Keeping what's what will require some initial contemplation and paradigm shift, given the wording of your response.

[Doug Slattery:]   However, JIT runs after the classes have been loaded from cache/disk, right? The load overhead is unavoidable to both executables and JITs, so that's a mute point.

Not really, are you sitting down ? Do you have a CVA risk ? Are you ready to get your brain rattled ?

This is in fact it is the crucial core, the central issue and the point at which Servlets leaves cgi for a Modern Programming Model that is post 80's and is the true reap of our moving out of someone else's discussion.

You, in development, do the load sequence. You can get really fancy with what you have already loaded when the request comes in. And before you ask me:   "Really, really fancy ? Or just really fancy."   We are talking 200 A-10 WartHogs fired from arbitrary locations placed at random t,x,y,z by quantum decay of Strontium titanate, with Grace Hopper doing the load calcs, and keeping some semblance if sanity.

This assumes hardware is provided to do this scale of parallel request retirement.

Oh, and don't forget the 2,000 wasps that do a sombrero function while waiting for the next request to come in.

I'm gonna look stupid if you try to do this on quad-core, we are talking about 208/three-phase equipment at a minimum. Racks and aisles for servers, that type of thing. The processor/program combination is now the bottle-neck in Light Wave Tunnels -> and so by a wide margin.

[Doug Slattery:]   Running in cmos!? What an awful design decision. It must have something to do with cost I suspect. CMOS itself is a slower memory device compared to dram, and in most designs is used for data storage. It's also slower because it's not L2/L4 cached. I don't see why anyone would decide on cmos as opposed to (ep)rom for code.

See forum: Java Micro Edition Ever heard of a FPGA ? There is a wide range of hardware, that was a catch(){} - to avoid wasted keystrokes.

[Doug Slattery:]   Lets see if I can clarify slow... The contract for the project had one of its requirements to be that the request-response time to be five seconds or less. Of course, there was an exception clause for events out of our control such as high traffic in the internet cloud perpetuating a response time. The customer reported access times to far too frequently exceed the five second limit. After porting the cgi's to 'C', over a period of time, the customer reported access times much more reasonable, although, occasionally to exceed the five second limit. The five second limit was the slow determiner.

Let's reconcept the question. Try 3,000 requests a second. MTBF of 1/10,000 from a population of 1,000,000 requests
and then each failed requst must fail without bringing the server down. ( or confusing the user for that matter )

[Doug Slattery:]   Not for my understanding. That's old news .

Clarifiy, we missed something in the concept exchange for this point. Something basic and profound. A paradigm, a precept, a hidden gotcha that will make both of us appear to have done poor project concepting.

[Doug Slattery:]   Yes, but the compiler will let you do it both ways

That is unfortunate for Extreme Programming, welcome to Java. { that was not a setup (question) it is one of the transitional points - those always require at leisure contemplation and are not responsive to Socratic method ... I brougt it up to point out one of few things that will be acclimatizations for new to java programmers: If you want to fire up a Hornets Nest, tell some OO ers in Java that you should be able to cast to a void }

[Doug Slattery:]   My former boss comes to mind

Why is it former ?

[Doug Slattery:]   I know, it's part of the entrepreneur's vernacular.

I am an entrepreneur, a rather intrepid one. We leave our iron with the Sherrif before ordering Whiskey at the Saloon.

[Doug Slattery:]   Since when? And why? They manufacture cpu's, not operating systems. All the drivers (and TSR's) I've written have been in 'C' and Assembly. If you're referring to portable/handheld devices, ok, that's not my turf.

That is just something I read a while back at the intel site. Things shift and move forward, but I do not expect that to have been totally abandonded. I may be Hard Rocked to actually have to find it.

Nick
//eof

[ Here, chew on this awhile .... ]

public class TestHarness {long l = 99999999999999l;} // 10^{14} floating point ops

[ October 14, 2007: Message edited by: Nicholas Jordan ]

[Nicholas Jordan]

[Ulf Dittmer:]

The point that was being made was that the JVM starts up very quickly these days, certainly much less than the 6-10 seconds quoted earlier. (I just verified that a Java desktop application can have a GUI up and running in about 2 seconds on a machine that's not very fast.) Some applications may choose to do all initialization before showing a GUI and becoming responsive, which will lessen the perception of a fast startup; others may make different choices.

I concur. I will add that I am intending to code some timing loops, along with sliding window tests of sample data, and found that in C when I tried to do this, I got exactly the same load times and ini

[Stan James]

Agreed in most cases except mine. The cgi operations are serial in nature. The cgi first has to (after authenticating the request) pull off the form variables. Next, generate a database query and finally generate a response page based on the results of the query.

This paragraph, in response to threads being important on servers, caught my eye. It may well be that the sequence of steps for one user request offers no opportunity for threading, but running many users at once surely does, yes? Last time I looked (things may have changed) C language CGI started a new process for every request where Java started a new Thread. The lighter weight threads were usually a lot quicker to start up and shut down and even better when pooled.

For grins, see what you can find on pipelined architectures. They queue up a task for each of the steps you mentioned, and there is a dedicated thread for each task. So one thread does authentication and queues up extract variables, the next extracts request variables and queues up database access, the next does database stuff and so on. One advantage is that one thread running a very small amount of code in a tight loop avoids paging and code loading issues in virtual memory. They can also dedicate more threads or CPUs to database and fewer to extracting variables to fine tune. I find it surprising that this pays off, but under very specific conditions it can provide better throughput and better degradation under extreme load. Cool beans.

[Doug Slattery]

Hi Nick,

This is why I brought this seemingly fine point up. It is discussed in the book cited about Servlets. You can do all of this in a multi-threaded fashion, provided you take definite, proveable steps in the allocation of a session id, user-id and track these to which response form field came from which session and are they logged on and a hydra of issues that becomes relatively do-able after deep contemplation of several Threading issues - all of which have been addressed in the last six months in Threads and Synchronization

I see your point of view now based on Stan's reply (I think). However, now the burden is on you (and me the programmer) to implement this, rather than letting the os handle it.

..... the several times that I have tried to code this, it gets stuck on finding out how Sockets work, and right now my concepting is to do it all with session id-s and user-id-s and form responses.

Sounds like a fundamental problem with the sockets (unless it's winsock. I never did like implementing a socket based server on the MS platform). But, session id's is how we did the website in this discussion.

Properly written, they scale better than cgi. I am now convinced that the Java VM will dispatch to processor bus(n) effectively if the code is written to spot identifiable candidate instruction streams for parallelizing. Keeping what's what will require some initial contemplation and paradigm shift, given the wording of your response.

Properly written for a $$$ multicore/multiprocessor system. Agreed. But, let's not lower our guard and rely on fast h/w to be a solution for a slow inefficient program. Not that this is, but, a lot of greenhorns will use fast h/w as an easy way out. Also, not every budget allows for such an implementation.

You, in development, do the load sequence. You can get really fancy with what you have already loaded when the request comes in. And before you ask me:   "Really, really fancy ? Or just really fancy."   We are talking 200 A-10 WartHogs fired from arbitrary locations placed at random t,x,y,z by quantum decay of Strontium titanate, with Grace Hopper doing the load calcs, and keeping some semblance if sanity.

This assumes hardware is provided to do this scale of parallel request retirement.

LOL! It's been a while since I've seen an A-10 in action (for real, not on tv). I don't know why most people think they're ugly. I think they're cool and a lot better to look at than the F-4!

Really though, assume you're on my budget and parallelism is not an option.

Oh, and don't forget the 2,000 wasps that do a sombrero function while waiting for the next request to come in.

-- dead link.

Ever heard of a FPGA ? There is a wide range of hardware, that was a catch(){} - to avoid wasted keystrokes.

Yep. That was becoming mainstream around the same time I got out of h/w. I never did get into the gory details.

Let's reconcept the question. Try 3,000 requests a second. MTBF of 1/10,000 from a population of 1,000,000 requests
and then each failed requst must fail without bringing the server down. ( or confusing the user for that matter )

MTBF? That wasn't a factor. To me, MTBF means something between a BERT exception and a fire . My point of view is on the server side. Assume 3,000 requests a second get through. If not, it's a problem in the cloud, not with the server. Not my problem (but a problem). 3,000 is pretty high, but the population is more realistically 10 fold.

[Doug Slattery:]   Not for my understanding. That's old news .

Clarifiy, we missed something in the concept exchange for this point. Something basic and profound. A paradigm, a precept, a hidden gotcha that will make both of us appear to have done poor project concepting.

That was in response to your suggestion of going back to page one for using Java for cgi. I *really* get that part. Shoots, some cgi's I've written were shell scripts (where appropriate). Others (I was thrown into) were a combination of 'C', Perl, Java and shell.

If you want to fire up a Hornets Nest, tell some OO ers in Java that you should be able to cast to a void

Don't you mean NULL? You can't cast to void even in 'C'. Void negates the implication of a type to cast to.

With NULL though,
Yeah, what's the big deal?
int myStructIntSize = sizeof(((struct MyStruct *)NULL)->intSize);

[Doug Slattery:]   My former boss comes to mind

Why is it former ?

Obviously, you never worked for him . I was left supporting legacy systems while new programmers were hired to migrate things to today's "standards". With my tenure and all, it was a writing on the wall thing.

I am an entrepreneur, a rather intrepid one. We leave our iron with the Sherrif before ordering Whiskey at the Saloon.

Iron or silica

Aloha,
Doug

-- Nothing is impossible if I'mPossible.
[ October 15, 2007: Message edited by: Doug Slattery ]

[Nicholas Jordan]

[Stan James:] For grins, see what you can find on pipelined architectures.

[Doug Slattery:]   I see your point of view now based on Stan's reply (I think). However, now the burden is on you (and me the programmer) to implement this, rather than letting the os handle it.

This guy does heavy-hauler work for a large installation so I am glad to have it coming from him rather than me - He is a tradtionalist OO and Java makes much of OO as a central paradigm. Stan said exactly what I would tell you, damn near word for word .... so we are all very fortunate here.

Henry Wong is cover author or title author on an O'Reilly title:   Java Threads, 3rd Edition,   and I strongly suggest digging through this title before you get any precepts commited to habituation.

[Doug Slattery:]   Sounds like a fundamental problem with the sockets (unless it's winsock. I never did like implementing a socket based server on the MS platform). But, session id's is how we did the website in this discussion.

Well, what happens here is we get in the cross-fire of a camp-based intramural doctrine conflict. One side says you should have headless monsters running through invisible doors, the other side insisting on infantile L&F Gooies all over the place. One side can tear to shreds anything we do with developed computer science, the other cannot be combated because everything is wonderful, as Seen on TV.

Would this be the correct design/logic for a "log on" program? by Tarek Khojah is asking the same question.

[Doug Slattery:]   Properly written for a $$$ multi-core / multi-processor system. Agreed. But, let's not lower our guard and rely on fast h/w to be a solution for a slow inefficient program. Not that this is, but, a lot of greenhorns will use fast h/w as an easy way out. Also, not every budget allows for such an implementation.

Suffice it to say, the work I did on my pet project implements 2048 bit data block size before considering what concepting we need to do.

I spoke with a 'way-on-up-there' who works at a major retail vendor of boxes, and used to work as an IRS accounting specialist of some kind. Your words here involve subtlties of what cs calls "Social Engineering" and cannot be resolved. Look up Dragon Fly ~ and without giving any flesh to the cross-fire, tell me if you feel that some of the questions that descend from having 16-bit, single threaded code running in ring-0 would be better resolved by attempting a true Java Operating System that utilizes the Global Descriptor Table to provide a Sandbox at Ring-2 for Java CLass files running in Ring-3, reserving Ring-0 for just have to do it the proven way and reserved to traditional computer science's tests of reliability and Ring-1 being for implementation of a true operating system that takes 64-byte data block size as "supposed to be" the fundamental unit of traffic on the bus ?

This is way-on-out-there, I have heard nothing of this anywhere else. The snag here is we live in the real world, and without hearing about Intel's 64-chip on a chip chip, we may be chirping in the swamp ~ attracting cross-fire. Remeber, the Packin Heavy Dudes at the ranch get theirs out of the Liquor Cabinet. We have to be served traditional Whiskey.

[Doug Slattery:]   Really though, assume you're on my budget and parallelism is not an option.

I am, I did, I do. Since you have moved some sand, consider my problem. Trying to write and test for parallel wintel revealed, after reading Henry's book while writing the loop, that Threading provided a neat, effective model for the application of OO to recursively building dictionaries from sample documents dropped anywhere below some folder I would mkdir during installation. Program description, customer specification and worked out in contract negotiations.

Because machinery behaves in a manner that is disconcerting to someone not an experienced field technician, I was fortunate on my first test run to only have about 1-3 seconds of uh-oh, it won't work before I realized it was the paging and single processor, in conjunction with a business that has to run a business instead of entertaing my ( source code based ) imaginary world, not unlike the world as seen on tv.

I saw an A-10 in exhibition, it stood on the tailpipe for at least 6,000 vertical. At least 3-5 orders of magnitude removed from winnie the poo and user two.

[Doug Slattery:]   -- dead link.

You're firewalled.

Signal Processing. Special functions. There are a number of special functions used in studying signal processing either because they can be used to model ...

U. Dayton, what gives here ?

[Doug Slattery:]   -- dead link. Yep. That was becoming mainstream around the same time I got out of h/w. I never did get into the gory details

I am ancient, ever heard of an 028 ? CDC 7700 ? How about Tip & Ring ? No one EVER heard of The Wortman Mod : It was a proof-of-concept that made the 028 print R to L. It worked, too bad Dr. Tierney did not take any pictures.

Mr. Wortman resembles ( closely ) Dorvak in style, manner and era.

Message edit: I mised this: MTBF? That wasn't a factor.
MTBF == mean time between failure, we don't have to target even 300 requests a second. The point is that with Java's acommodation of parallelizing compilers right in the linguistic and hardware ( e.g. - 64-chip/chips ) already in the business's promotion pipeline, then Using Java as opposed to another language where performance counts becomes a given ~ and an obvious no-contestors when you learn about it's suitability as a rapid development platform because of the rich toolkit and elegant solution to [] overrun.

I throw away about a thousand lines of code a week because I can slap it up there and hit the go button and not worry about tearing up the machine.

I threw away a thousand lines this morning.

There is no mercy where professionals are concerned.

i.w. - fun and cool        
[ October 16, 2007: Message edited by: Nicholas Jordan ]

[Raees Uzhunnan]

Guys ; my judgment of using a language will be based on merely ROI. not based on weather it outran other by few milliseconds on not;

What good is an application that runs faster but it crashes before it reaches the mark !!

[Ilja Preuss]

Originally posted by RAEES UZHUNNAN:
Guys ; my judgment of using a language will be based on merely ROI. not based on weather it outran other by few milliseconds on not;

What good is an application that runs faster but it crashes before it reaches the mark !!

Or 10% faster, but 100% more costly to maintain and enhance...

[Chandra Sekar]

This is a very valid argument. That is one reason I'm a big fan of Java.

As far as stability and scalability are concerned I have so far not experienced a better platform.

[Doug Slattery]

What good is an application that runs faster but it crashes before it reaches the mark !!

What good is a programmer that writes an application that crashes?

A support guy for a Unix vendor way back in the days before Java gave me some advice after asking him about detecting buffer overruns in a device driver I wrote that could cause a system panic. He (boldly) told me that there wasn't a way to detect it and if a programmer was sloppy enough to let that happen, he deserved to have the system go down in flames.

I guess my point here is a properly written algorighm will be as efficient as efficiency can be regardless of the language it's implemented in. Most of them are available in api's, lib's and sample code from articles on the net. I like OO from the standpoint that you can customize algorithms through inheritance and polymorphism easier than non-OO (besides a boatload of other conveniences). However, I don't use this as a crutch, but choose to understand the nuts and bolts under the hood.

Aloha,
Doug

-- Nothing is impossible if I'mPossible

[Nicholas Jordan]

[Raees Uzhunnan: ]   .... based on whether it outran other by few milliseconds on not;

One of the central points I wish to make to Doug, along with probably five or six others - most of which have been brought up - is that given a server application, on hardware that supports it ( which as Doug points out, many of us do not have today ) Java <em>scales</em> so much better that the lg(n) flattening of the scalar is not intuitive: YOu have to see it to get the real body-shock that destroys your Win-World where everybody "wins" ( by transmitting id's that are guarded by an LFSR ) and do not realize the consequences of compliance with Sarbanes-Oxley using limited skills provided by the Sales Department.

All too true the story Doug relates about the "... deserved to have the system go down in flames." 22- million dollar systems do not go down in flames. Why ? Because ( in part ) of extensive testing. It took me two weeks to transition to Java {final in place of constant and no void nothing}: after which my productivity went way up.

Why ? Because I could do extreme programming. I do not think any other lingusitic will support crash & scratch prototyping. It is standard undergraduate cs to migrate between linguistics, so anything that gets working can be re-written in C/C++ as well as some unknown linguistic that will never make it out of the undergraduate cs lab. I just spent 10-12 hours straight since 8-10 am this morning doing just exactly that.

I now have 133,000 bytes of compiled work from the last build before I stepped onto the porch. Show me any competing lingistic that is free, constantly peer-reviewed and not controlled by an Elitist Central. There are things to be presented, notably gcc and probably several well-deserving citations - but how many of them can you write a keyed-map with in ten seconds or less ?

[Doug Slattery: ]   I guess my point here is a properly written algorighm will be as efficient as efficiency can be regardless of the language it's implemented in. Most of them are available in api's, lib's and sample code from articles on the net. I like OO from the standpoint that you can customize algorithms through inheritance and polymorphism easier than non-OO (besides a boatload of other conveniences). However, I don't use this as a crutch, but choose to understand the nuts and bolts under the hood.

What if the OO stuff is not published yet ? Case in point - JSP Tag Libriaries. Also, does not the typing and casting introduce something not totally unlike the fixed array size problem ? Further, many of the issues that we discuss here are on only approachable by deep comprehension of the AVL Zero-Page thread and hard-wiring of the write-back ( thingie ): ON sufficiently large equipment, Java will wipe these concerns off the Glass Pane. Okay, you do not have 64-pipliner today ~ I don't either.

I am writing in Java though.

J.I.T. will do the cross-code for me.

No lib from the net will do that.