[Rusty Shackleford:]Because the program you are writing is not inherently parallel.
Well since OP sought to open discussion, I counter that sales will write mono-code path in parallel, invoking sophisticated compiler optimizations ~ then do bulky, tiered ops in squeak - the micro language. This is sorta sophisticated nuance splitting for engineers, but I am sure we see it too often and I have a degreed risk-analysis engineer so I actually seek any feedback. I have better things to do with my time than drivel on masters.
[Rusty Shackleford:]Because the extra time it takes to refactor it outweighs any speed benefit.
In such arena, the J2EE Architect should deal with the client, they have soft-skills ~ I do not.
[Rusty Shackleford:]Because the code you programmed in parallel runs slower on multiple cores.
Ditto, that's for the Architect.
[Rusty Shackleford:]At least on the desktop, the future is not parallelized programs. In my opinion, the future is the OS running a process on one core, another on the second, etc. In many cases, be it desktop, server or whatever, this will be a more optimal solution.
Agreed, largely. Crossing process boundaries is costly in the time domain, selection of supervisor program such as operational allocation of i/o resources may not require dedicated processor architecture and in fact preliminary concepting on asymetric, transfer function of 1/(scale * processorCount + 1) to determine allocation of supervisor circuitry from application circuitry may yield OP's goals in our work.
[Rusty Shackleford:]If a program, no matter what space is runs in, can be made to run in parallel that doesn't mean it is going to run faster. Take an extreme example: a program that has be written so that 80% of the execution time can run in parallel will not double in speed on 2 cores. It won't speed up 4x on cores, etc. In fact, with 4 cores you won't see a 2x performance boost. It all depends on the program and the processor architecture. Do the separate L1 caches need to communicate often? Is L2 shared? Write-through? Write-back?
Cache consistency is not likely to be achieved effectively in client code presented in routine business. ( ?... speculative look ahead ) In my opinion, some artificial intelligence could be put on BUS<sub>n</sub> to do reliability in large-sclae socialization structures that has not yielded to cryptographic efforts. [ the password on the monitor problem ]
[Rusty Shackleford:]There is not enough information to be able to respond in any meaningful way. Java may hide the hardware details from the programmer but that doesn't mean it is irrelevant in terms of performance.
A classic case of Engineering School being packed with attentive, focused minds sweating on pencil and paper dreading time consuming calculations has been replaced ( speculative ) with hoards of role-playing minds fascinated to The Glass Eyed Monster. { CRT }
[Raj Chaud:]Nicholas, I don't even understand what you are getting at with that "linguistic" comment, so I am going to ignore it. Linguistic is a generalized terminology for human-readable code such as Java, C/C++, Perl, Lisp, ADA and any of the written codes vis-a-vis some speculative Point & Program tool such as IDE's could potentially become, if not already.
[Raj Chaud:]Anyway, you're missing the point. The whole idea, or selling points behind JAVA (and I've been doing this since just about they came out with this thing over a decade ago) was platform independence, pure scalability, and oh yeah, platform independence. I missed nothing in your post, I calcualted my comments EXACTLY to pull in the heavyweights we see posting. Now that I have some twenty-thousand-pound-elephants, watch me make them dance!
[Raj Chaud:]the whole idea was to let developers spend time writing effective code that would perform business tasks and support a business, not for us old devs to see how good we could get at it, although, to some extent it has turned out that way. ) What Java is becoming in fact is an effective training platform for CS students. That was ( opening the door to open development ) how the mighty M$ publishing empire came to be on the front of software innovation. ( spare me, folks ) Then we have a development concept ( Java ) by what may be modeled as a competition player, not-dissimilar, evoking very effective discussions such as we have here. I doubt we will rule, such as experience shows, but for those of us who want to keep up with issues in J2EE so that we know what will be coming in the door, then we have a cross-platform linguistic we are skilled in and thus may not be wrapped is silk but nevertheless make our work here productive.
[Raj Chaud:]point being bro, Please do not use variant spellings, it drags beginners in where Pro-Bro's must hammer the 304 Stainless.
[Raj Chaud:]if I have to go about coding too specific for the platform, then why the hell am I still not writing C++? may as well manage the memory, and threading, etc, etc, etc from there YES? No! Proposals, anyone?.... (snicker, snicker)
[Raj Chaud:]That is the whole point. So the question is, if I hadn't written any platform specific code (and anyone that doesn't think that writing code specific to the machine is platform specific = CRAZY) like the normal dev on my team would do 3 years ago, would it speed up if I went to a multi-core machine.Why do you want to speed it up?
[Raj Chaud:]the answer I have found is NO, well, i.e., not much. java does execute a little faster, but the gains are minimum. so, I know why this is, but I was just asking if everyone else had similar experiences...............because, this will set us up in the industry in the next near period to discuss how we can speed up single threaded code from a machine standpoint.We speed it up by allocating some un-used processor power to thwarting weekend ruiners.