Help me!! Why java is so popular

[raddog58c]

I wouln't rush to use the performance issue
if I were a java freakazoid.


I agree with this.
Not only bloatware, but MONSTERWARE,
with a foot print of a inter-galactic space ship.

But what I like about Microsucks development environment
is that it is very intuitive and very simple in terms
of assisting you with many things you normally do,
starting from editing and down to compilation, run time,
debugging, and you name it. You can edit the HTML or
XML files with full support of toolkits and gadgets,
probably better than some dedicated HTML editors can.
And it is all integrated. Just drag and drop the file
from your directory, and boom, you are in HTML edit mode
and the toolkit is hanging right there, down to style sheet
editing on a sophisticated level.

Hmmmm, I dunno about that... .have you done much with the WMFSDK?
Intuitive is not a description that seems appropriate in the same
sentence with the proliferation of Interfaces supporting obscure and
ecclectic functions embedded in the bowels of the documentation for
that SDK. Wanna programatically cut a 5-second clip out of the middle
of an ASF movie file? You'll need an IWMSyncReader, IWMWriter,
IWMProfileManager, etc. etc etc... and about 3,000 lines of code later
you're done.

Wanna do the same thing with an AVI file? Scrap your IWM stuff and
read up on DirectShow -- it's crazy, man.

The other thing that's really badly managed by MS is incompatibilities
in released SDKs and a TON of obscure fixes via pragmas, deprecated
versions of SDKs, or instructions on how to modify the base code.

Like MFC -- you have to define the appropriate level with a #define
_WIN32_WINNT 0x0401 or some such rot, otherwise you'll get link and/or
compile errors.

Not at all intuitive there.... a real impediment to programmer
productivity, IMO. I've personally spent hours perusing the WWW
looking for solutions to compile or link or coding problems which are
not easily found in msdn.microsoft.com only to find the answer in some
game developer forum or in comments in a someone's sample program,
etc.

But that's stuff for a whole different thread -- it is possibly
relevant here in the sense that obstacles like that definitely will
push people toward a more "standard," non-OS specific development
language like Java.

In that sense Microsoft may be doing more to push people to other
solutions than they realize.....

ymmv...

 

[raddog58c]

That approach runs into the problem of combinatorial explostion -- which is why
it is only used in limited ways and in rather extreme cases. The thing is that
a JIT has more information available to it than any possible static analysis.
That is a /fundamental/ advantage, and cannot be clawed back (though it can be
wasted); just as having to do extra work at runtime is a fundamental
/disadvantage/ which can only be compensated for, but never eliminated.

BTW, I'd not advocating one approach over the other here, just discussing what
the approach taken by current JVM's /is/.

-- chris

Excellent points.

 

[raddog58c]

Actually they can ;-) If the right instructions are issued in the right order

then they can beat a smaller number of instructions doing the same thing but in
the wrong order. There's a nice Wikipeadia article on one form of
memory-access optimisation
http://en.wikipedia.org/wiki/Loop_nest_optimization
which I tried translating into C, and was somewhat shocked to find a (on one
machine) a full factor of 10 speed up...

Recall I said 100 vs 50 of an average of the same mix. Depending on
the processor, and if virtual memory is on/off, for instance, 1
instruction can cause horrendous performance issues, such as a paging
exception.

Conditional branch instructions executed on CPUs with "dumb"
prefetchers can degrade performance horribly.

But assuming you have two programs doing the same thing, particularly
if both are truly well coded, the shorter I-stream is going to win all
the time.

You probably already know this, but just to be clear. Java bytecode is
essentially irrelevant in considerations of performance. It's best thought of
as a high-level programming language (OO, with GC, etc) which is used as
reasonably compact, portable, /transmission/ medium.

Whether /any/ bytecode survives until runtime is implementation dependent.
IBM's "Jikes research JVM" (a very impressive bit of work, and incidentally
written in Java) translates /all/ bytecode into native code (but only invokes
an optimiser for discovered hotspots). They report that a fast-and-simple
translation phase takes essentially the same time as just loading and parsing
the bytecode in the first place. The current Sun range (at least for Intel
boxes) use a mixture of more-or-less direct interpretation of the bytecode plus
JITing for the hotspots. (The interpreter itself, by the way, is generated at
runtime as part of JVM startup, using the same code-generation framework as the
JITer uses. I think that's rather cute).

-- chris

Interesting. I don't know much about the internal optimizations in
the JVM -- sounds like good research for a rainy day -- but I wonder
if a JVM could keep a cache of precompiled programs and compile them
the first time they're encountered and then simply reload them upon
request -- that would certainly be an excellent option to enable on a
JVM and should lead to pretty comparable performance in just about any
case.

If it compiled only once, you would lose the ability for it to coerce
the code at different runtimes based on the existing circumstances of
the system. I'd think that would be a reasonable tradeoff in many
cases.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I wasn't trying to prove anything. Common sense says if you have to
convert from one format to another before you begin executing, you
have an extra step and obviously all things being equal you are not as
efficient, period, end of sentence.

True.

But utterly irrelevant to the part of your post I commented on:

#The fact the conversion is done at run time and would have to be done
#every time the code is run (unless it's cached) puts it at a
#disadvantage out of the gate. The late binding to environment could
#help close the gap,

Where you claimed that the benefit from late binding to
environment <= the loss from having to JIT compile overhead.

Converted code that's more efficient you could make up for the
conversion - it would depend on the problem space, run duration, and
how well/badly each program were written. The converted code would
need to be more efficient to have a chance to make up for the extra
step. If it were equal to or less efficient, you will not make up the
gap.

That's not a proof -- it's an observation of reality, right?

A completely irrelevant observation in connection with your claim
quoted above.

There's a beauty in interpreted languages, but instruction-level
efficiency is a trade off you make for the functionality and late-
binding paradigm that interpretation provides. I give the JVM
architects a lot of credit, as under the right circumstances they
glean a lot of efficiency out of Java byte code -- but on balance the
Java code I've worked with in batch, GUI, and web server applications
has not been impressive from a speed standpoint. Functionality wise
it's great, however, so that's the emphasis upon which one should
focus with respect to interp. languages, IMHO.

So far I do not think you have impressed many with your understanding
of Java performance.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Fair enough, but the key words are "may" and "could" -- often they
will not,

We are impressed by your argumentation technique.

You are basically arguing that "Java is slow because it is slow".

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Like a lot of interpreted languages, Java's development cycle is
pretty excellent I think. A programmer can get a fairly complicated
application off the ground quickly due to a number of things brought
about both by the interp-language development paradigm that allows for
immediate detection of errors and compile-and-test-as-you-code
sessions.

Have you ever coded in Java ?

Java development is very similar to C++ development
and very distinct from development in the interpreted
usually dynamic typed languages like Python and Ruby.

I'm fluent in a decent array of languages, compiled and interpreted,
as well as a good number of assembler languages.

We have understood that you are very impressed over your own skills.

Arne

 

[Chris Uppal]

raddog58c wrote:

[me:]

Recall I said 100 vs 50 of an average of the same mix.

Essentiall the same mix of instructions. The difference is in the patterns of
access to memory. Cache effects, in a word (OK, two words). No virtual
memory, or other paging, involved (although V.M. effects /are/ cache effects
too)

Conditional branch instructions executed on CPUs with "dumb"
prefetchers can degrade performance horribly.

As far as I can tell the branches should be equally well predicted in both
cases. (There aren't that many in relation to the total instruction count, and
what conditions there are nearly always take the same branch, hence are easily
predicted.)

But assuming you have two programs doing the same thing, particularly
if both are truly well coded, the shorter I-stream is going to win all
the time.

Nice theory. Not true ;-)

(Alternatively, you could see the cache-friendly version as being more
"well-coded" than the other, but since that kind of coding is an almost
impossibly difficult task, I wouldn't put it like that myself. The point of a
term like "well-coded" is that it expresses that something is better -- more to
be desired -- than something else, and the hand-optimised code is very much
/not/ to be desired !)

Interesting. I don't know much about the internal optimizations in
the JVM -- sounds like good research for a rainy day -- but I wonder
if a JVM could keep a cache of precompiled programs and compile them
the first time they're encountered and then simply reload them upon
request -- that would certainly be an excellent option to enable on a
JVM and should lead to pretty comparable performance in just about any
case.

Yes, it could do that, but it's interesting to consider /why/ it doesn't. I
don't know the answers, of course, but here's how it seems to me...

The optimisation in the JIT irretrievably scrambles together every element of
the input "program" (a term which doesn't have much meaning in a language like
Java). The scrambling crosses not only module but also function boundaries
(what with dynamic inlining and so forth). So it's effectively impossible to
cache anything at a level of granularity less than a whole program. But then,
the optimisations actually performed depend on what the program actually does
on that run (imagine a word processor, on Monday it might spend most of its
time letting the user type in text, on Tuesday most of its time recalculating
layouts, on Wednesday most of its time doing spell-checking and comparison with
previous versions, on Thursday most of its time formatting stuff for printing).
It's not easy to see what could be cached (or another way of putting the same
thing, it's not easy to tell whether the cache was still a valid reflection of
what it /should/ be). Since the overhead of JITing isn't really all that large
(since it's focussed on where its needed), the cache idea hasn't really taken
off.

But, for a differing view, proponents of statically-compiled Java (such as the
makers of Excelsior Jet) think that the time available for static optimisation
(far larger, obviously) is enough to make static compilation a viable point in
the design spectrum too. FWIW, I agree with them.

-- chris

 

[Chris Uppal]

To the spirit of the thread, and from my experience working in
reasonably diverse range of languages, I still don't believe Java's
popularity has in any way, shape or form been a byproduct of its
legendary performance.

I wouldn't call it "legendary" (it is very impressive technology -- but not
unique). I wouldn't call it "mythical" either ;-)

I would say that Java implementations have offered a balance between
flexibility and other ease-of-programming aspects
performance
conformance to prejudice
which has been found appealing by many. It's the /balance/ which is important.

(I don't, in fact, agree with that judgement myself, but that's a question for
another day).

Like a lot of interpreted languages, Java's development cycle is
pretty excellent I think. A programmer can get a fairly complicated
application off the ground quickly due to a number of things brought
about both by the interp-language development paradigm that allows for
immediate detection of errors and compile-and-test-as-you-code
sessions.

Hmm... Or maybe it's for today after all. Java was designed as if it was never
going to be interpreted. In most ways the language (or the compiler's
interpretation of the language) is totally static. (The /JVM/ on the other hand
is much more dynamic). There is almost nothing that the designers of Java
/could/ eliminate from the benefits of dynamic languages that they /haven't/
eliminated. Possibly in the misguided belief that they were impossible to
implement efficiently.

Fortunately, the runtime semantics of the JVM are more flexible.

And (perhaps even more fortunately) the creators of IDEs for Java have
attempted to replace it (at least at development/debug time) by a more dynamic
language with the same syntax but a less rigid semantics.

They haven't succeeded, of course -- in fact their efforts are laughable[*] --
but they /have/ tried, and they haven't entirely failed either.

([*] The scorn -- and it /is/ scorn -- is because I'm a Smalltalker in my other
life.)

I have seen a lot of inefficiently written components used in a lot of
applications. Because Java encourages the programmer to let the JVM
handle a lot of details it seems to me -- and I welcome other opinion
on this -- that many Java coders get "lazy" about what's really going
on inside the code.

My own impression is that, although you are right, a different language would
not materially change those programmer's attitudes. They /still/ would not
want to understand what they were doing in more detail, or at a greater depth,
than they could get away with. One of the parameters one can "twiddle" when
designing a language (or an API, come to that) is how the language copes with
such abuse. The Java approach is generally to try to protect them from /error/
while allowing performance (in all senses) problems. The C approach is
different. The C++ approach is (interestingly) a combination of the two -- at
the /language/ level it has very much the same philosophy as C, but it provides
better tools for creating safe APIs.

(Re-reading that last paragraph, I realise it sounds as if I'm claiming that
there's a black-and-white distinction between "good" programmers and
"lazy/ignorant" programmers -- I don't really mean that at all, but the sense
may come across better if I leave it overstated. Anyway, I can't be bothered
to re-write it now...)

Oh, and I must add: although I strongly support the idea that programmers
should understand the next level or two down of the operations they are
invoking. I don't think that the difficulty of that is always appreciated in
these days where the hardware itself is hugely complicated, with subtle and
non-obvious performance characteristics of its own.

-- chris

 

[Chris Uppal]

We are impressed by your argumentation technique.

You are basically arguing that "Java is slow because it is slow".

I don't think he is, you know.

It is legitimate to ask, in response to a claim[*] that <such and such> a
technique /can/ have an advantage, how often, and by how much, that advantage
manifests in practice.

Scepticism != blind prejudice.

-- chris

[*] or even proof.

 

[Patricia Shanahan]

Recall I said 100 vs 50 of an average of the same mix. Depending on
the processor, and if virtual memory is on/off, for instance, 1
instruction can cause horrendous performance issues, such as a paging
exception.

Conditional branch instructions executed on CPUs with "dumb"
prefetchers can degrade performance horribly.

But assuming you have two programs doing the same thing, particularly
if both are truly well coded, the shorter I-stream is going to win all
the time.

What do you consider to be "the same thing"? For example, consider:

A) A traditional three-loop matrix multiplication.

B) A matrix multiplication with extra loops to do the job as a series of
subproblems that each fit in cache.

Are the "doing the same thing"?

Patricia

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I don't think he is, you know.

He is arguing that Java performance is less than C/C++
performance based on an assumption that the JIT compilation
runtime overhead is bigger than the JIT over AOT gain.

To me that is basing the conclusion on an assumption that
is equivalent to the conclusion.

Arne

 

[raddog58c]

Have you ever coded in Java ?

Java development is very similar to C++ development
and very distinct from development in the interpreted
usually dynamic typed languages like Python and Ruby.

Have you ever coded in C++? It's not at all similar to developing in
Java, unless you mean they're both C language derivations. C++
requires compilation to find syntax errors, and linking to resolve
missing or mistyped externals. This is completely dissimilar to Java
development in an IDE like Visual Age, WSAD, or Eclipse, where missing
imports, mistyped classes, and syntax errors are flagged in the
editor.

Do you use notepad to write Java and then run it against java.exe? If
you do that I suppose it would be similar, but most folks I know don't
develop Java in that way.

I'm not familiar with Python or Ruby, but I use Perl quite a bit and
believe it to be similar. I don't have a Perl IDE, so I use notepad
and run it with Perl.exe. Perl development for me falls somewhere
between C++ and Java, but closer to Java. There's no linking step,
and it's pretty fast to write something and test it.

The Perl language is syntactically similar, but it provides some great
benefits over Java or C++ for scripting. I love it for scripting; I
can't imagine using Java or C++ to replace Perl in the situations I
use Perl.

Everything has it's place.

We have understood that you are very impressed over your own skills.

Arne

First who's "we"? Second, you don't have to be snide -- was I rude to
you? Third, I never said I was impressed with my skills; I said I
knew a decent number of languages fluently. There's a difference. I
mention my programming experience because I thought it relevant to
this thread. Why is java so popular -- I have my own perspective
based on experiences with more than one or two languages.

I never said my experience was impressive; never meant to imply it
either. It is what it is: experience.

Wanna know what's impressive about me? I'm a world class powerlifter.
That's right, I weigh 165 lbs and should break the US record for squat
next month with a 590-to-615 lb full squat, somewhere around there.
I've trained next to 290-lb pro football players and outlifted them.
Gather up a 1000 165'ish pound guys and see how many can do that. It
doesn't make me great, and it may not impress you, but down at the gym
people line up to watch me lift.

Hope that clarifies what I find impressive...

Anyways, Java is seen as a panacea in some places I know. C was a
panacea at one time. I remember ADA being proclaimed the mother of all
languages. I know people to this day who swear COBOL is all you ever
need. Sheesh. New languages will spawn from Java and C++, just as they
spawned from C, SmallTalk, Pascal, ALGOL 60, etc.

If all I'd ever coded was Java, or just C and Java, I might have a
different view than if all I'd ever coded was SmallTalk or something
like that. Besides, it doesn't matter if I'm impressed with myself or
with you or neither -- this thread is about why java has become
popular.

 

[Christian]

He is arguing that Java performance is less than C/C++
performance based on an assumption that the JIT compilation
runtime overhead is bigger than the JIT over AOT gain.

To me that is basing the conclusion on an assumption that
is equivalent to the conclusion.

Arne

Then what makes the main difference in speed? Is it rather such nice
features like checking for ArrayOutOfBound that java is a bit slower?

I once implemented a cryptograhic hashfunction .. and I couldn't come
closer to the speed of a c++ implementation than a factor of about 0.5.

since its purely deerministic I would assume a hashfunction can be very
well optmized at compile time in case of c++ and JIT and AOT should not
matter much to the program?

- Christian

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Then what makes the main difference in speed? Is it rather such nice
features like checking for ArrayOutOfBound that java is a bit slower?

The point is that Java is not always a bit slower. Sometimes it is a bit
slower, sometimes it is a lot slower, sometimes it is faster.

I once implemented a cryptograhic hashfunction .. and I couldn't come
closer to the speed of a c++ implementation than a factor of about 0.5.

since its purely deerministic I would assume a hashfunction can be very
well optmized at compile time in case of c++ and JIT and AOT should not
matter much to the program?

Difficult to say without seeing the code.

0.5 sounds awfully high, but it could be.

It also depends on the Java version being used and
whether run in client or server VM.

Arne

 

[Lew]

Have you ever coded in C++? It's not at all similar to developing in
Java, unless you mean they're both C language derivations. C++
requires compilation to find syntax errors, and linking to resolve
missing or mistyped externals. This is completely dissimilar to Java
development in an IDE like Visual Age, WSAD, or Eclipse, where missing
imports, mistyped classes, and syntax errors are flagged in the
editor.

You are talking about programming in a particular IDE, not about programming
in Java /per se/. There are IDEs that assist with C++ programming, too.

Both languages require some sort of compilation, whether run under the hood by
the IDE or explicitly by the programmer, "to find syntax errors, and linking
to resolve missing or mistyped externals"; it is the mechanism of the
compilation and link that differs, and that is not of much consequence to the
cognitive state of programming. Neither language supports the kind of inline,
write-and-run process of scripting languages.

Do you use notepad to write Java and then run it against java.exe? If
you do that I suppose it would be similar, but most folks I know don't
develop Java in that way.

And most folks don't program in C++ that way, either.

Of course there are differences between the development psyches, inherent in
the differences between the languages. Arne's point is that Java and C++ are
more similar to each other than to the Ruby/Python constellation of languages.
Arguments for the absolute will fail either way.

- Lew

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Have you ever coded in C++? It's not at all similar to developing in
Java, unless you mean they're both C language derivations. C++
requires compilation to find syntax errors, and linking to resolve
missing or mistyped externals. This is completely dissimilar to Java
development in an IDE like Visual Age, WSAD, or Eclipse, where missing
imports, mistyped classes, and syntax errors are flagged in the
editor.

????

Similar features are available in C++ IDE'es.

Do you use notepad to write Java and then run it against java.exe? If
you do that I suppose it would be similar, but most folks I know don't
develop Java in that way.

Java with standard editor and command line build is similar to C++
with standard editor and command line build.

Java in IDE is similar to C++ in IDE.

C++ with standard editor and command line build is obviously
not similar to Java in IDE.

But that is a ridiculous comparison.

First who's "we"?

The readers of this thread.

Second, you don't have to be snide -- was I rude to
you?

No but I strongly dislike people who think that various suspect claims
will appear more credible if they present themselves as great experts.

Wanna know what's impressive about me? I'm a world class powerlifter.
That's right, I weigh 165 lbs and should break the US record for squat
next month with a 590-to-615 lb full squat, somewhere around there.
I've trained next to 290-lb pro football players and outlifted them.
Gather up a 1000 165'ish pound guys and see how many can do that. It
doesn't make me great, and it may not impress you, but down at the gym
people line up to watch me lift.

Actually I am impressed.

Arne

 

[raddog58c]

He is arguing that Java performance is less than C/C++
performance based on an assumption that the JIT compilation
runtime overhead is bigger than the JIT over AOT gain.

No, I'm assuming it takes longer to translate a thing and run it, than
it does to skip translation and just run it. I think that's a fair
assumption.

BTW, this is not a C/C++ vs Java competition. I'd write something in
native assembler taking advantage of every facet of the hardware if
that's what I needed to do. The fact is I code in Java, C, C++, Perl
and a smidgeon of other things (COBOL, Shell script, and visual basic
to name a few) these days. I like them all for certain things, and
they each have drawbacks for other things.

Just wanted to make sure I was clear on where I stand.

To me that is basing the conclusion on an assumption that
is equivalent to the conclusion.

Arne

If you want to be 100% accurate, what I said was if you have to
translate code to run it, then eliminating the translation step would
cause the code to run faster.

Java has to be translated before you run it.

I believe these two statements are true. You can ding me and say you
translate Java once and then it can be cached or wathever, and that's
fine, but at load time it has to be translated. Byte code != native
instruction set.

An assertion was made that late binding can take advantages of the
environment to supply more efficient instructions. That's a theory.
What if the non-translated program is alread optimized for the
environment? Does someone want to suggest a JVM can translate a
program and then perform some magic to make the ALU run faster? Of
course not. Late binding only helps in circumstances where there's an
opportunity to improve by substituting a more efficient set of
instructions. As long as we're comparing apples to oranges then sure,
we can say there's an opportunity for a difference. If we're
comparing apples to apples, adding a translation step is going to be
slower.

Let me put it another way.

Java class abc is invoked for the first time -- we fire up and load
the JVM, abc gets translated to native code and executed -- Java class
abc is invoked again, only this time it's sitting in cache and is
ready to go so it's executed -- which instance of abc's execution ran
faster? I'm claiming the 2nd -- does someone want to argue the 1st
execution is faster? That firing up the JVM, translating the program,
then executing it is faster than just executing it, or just reading it
off disk and executing it?

This is what I'm saying. If these were 2 distinct programs, the 2nd
should win every time (ignoring interrupts, system activity, etc)
because we're comparing apples to apples.

FWIW, some of the late-binding advantage can be simulated with
reasonably simple code in any language. For instance an installation
script could check installed hardware and deploy the best from several
versions, or I could build a run-time hardware checker/loader to pull
code from a different DLL based on environments. I have created code
to do these kinds of things. It's not out of the box functionality,
but it's not very difficult either.

Also, a JVM can pay attention to usage, provide caching, adapt at run
time, etc., but such a service requires space and processing cycles to
supply. That means *potentially* it could make a single processing
unit it serves run faster or maybe not, but the service's computations
come at the expense of the operating environment as a whole. Most
comparisons focus on a single program's execution, but the resources
consumed by the JVM to look for runtime optimizations are resources
unavailable to other processes in the operating environment. How much
I don't know, but computational knowledge requires memory to store and
processor cycles to access. I do know large Java apps running on my
workstation will "blackout" (eg become unresponsive to mouse clicks),
and I don't experience the same from my C, C++ or Perl scripts -- I
presumed garbage collection was running, but maybe it's the JVM
looking for ways to run its apps and classes faster.

One other thing that I believe hurts Java's runtime environment is the
built-in unicode support. I have no use for unicode in my
applications, but Java stores everything as unicode, right? So that
means twice as much memory, and the need to convert from ASCII or
EBCDIC into and out of unicode, over and over again, and for nothing.
Is there are really good reason for mandatory unicode support? This
hurts Java's runtime model, IMO, and it's pointless if you don't need
it.

Anyway, this is a really interesting discussion to me. I think the
fact there's a discussion at all is a very big compliment to the
software engineers constructing the JVMs. They're obviously good.

 

[John W. Kennedy]

Then what makes the main difference in speed? Is it rather such nice
features like checking for ArrayOutOfBound that java is a bit slower?

I once implemented a cryptograhic hashfunction .. and I couldn't come
closer to the speed of a c++ implementation than a factor of about 0.5.

since its purely deerministic I would assume a hashfunction can be very
well optmized at compile time in case of c++ and JIT and AOT should not
matter much to the program?

And, on the other hand, the authors of "Core Java" report that a Java
implementation of the sieve of Eratosthenes using the Java Bitset class
regularly outperforms an equivalent C++ program using the C++ Bitset
template, even when they wrote a new Bitset template.

 

[raddog58c]

And, on the other hand, the authors of "Core Java" report that a Java
implementation of the sieve of Eratosthenes using the Java Bitset class
regularly outperforms an equivalent C++ program using the C++ Bitset
template, even when they wrote a new Bitset template.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

That's actually very interesting... why do you think that's the case?
I'm guessing the C++ Bitset template is grossly inefficient. Never
used it so I don't know. It's intriguing -- I plan to run some
benchmarks this week to compare ASM, C, C++ and Java -- time will
dictate how extensive I go, and I'll keep the tests simple and as
equivalent as possible. I'll post the results to this thread and we
can see it looks like.

Thanks for sharing that.

 

[Mark Thornton]

reasonably simple code in any language. For instance an installation
script could check installed hardware and deploy the best from several
versions, or I could build a run-time hardware checker/loader to pull
code from a different DLL based on environments. I have created code
to do these kinds of things. It's not out of the box functionality,
but it's not very difficult either.

How difficult this is depends on how many variations you need to test.
For example SSE 1,2,3, AMD; number of processors (1 or >1). So 4 or 5
different levels of accelerated math, plus the number of processors, you
could be looking at 10 different DLLs for the same function. This gets
very tedious. The usual response is simply to insist on say SSE2.

One other thing that I believe hurts Java's runtime environment is the
built-in unicode support. I have no use for unicode in my
applications, but Java stores everything as unicode, right? So that
means twice as much memory, and the need to convert from ASCII or
EBCDIC into and out of unicode, over and over again, and for nothing.
Is there are really good reason for mandatory unicode support?

Not having to duplicate all the methods which take String parameters.
What encoding would you assume for 'narrow' character strings?

Mark Thornton