Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35643 > unrolled thread

Re: Java is faster!

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Java is faster! Roedy Green <inquiry@mindprod.com> - 2016-09-25 03:28 -0700
    Re: Java is faster! j4n bur53 <janburse@fastmail.fm> - 2016-09-25 20:05 +0200
      Re: Java is faster! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-09-25 14:44 -0400
        Re: Java is faster! j4n bur53 <janburse@fastmail.fm> - 2016-09-26 23:09 +0200
          Re: Java is faster! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-09-27 10:51 -0400
            Re: Java is faster! Sebastian <nowhere@nirvana.org> - 2016-09-28 23:50 +0530
              Re: Java is faster! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-09-28 15:14 -0400
                Re: Java is faster! j4n bur53 <janburse@fastmail.fm> - 2016-09-29 09:11 +0200
      Re: Java is faster! Arne Vajhøj <arne@vajhoej.dk> - 2016-09-29 21:24 -0400
    Re: Java is faster! Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-25 16:37 -0400
      Re: Java is faster! Eric Douglas <e.d.programmer@gmail.com> - 2016-09-26 05:47 -0700
        Re: Java is faster! Robert Klemme <shortcutter@googlemail.com> - 2016-10-04 23:04 +0200
    Re: Java is faster! Arne Vajhøj <arne@vajhoej.dk> - 2016-09-29 21:18 -0400

#35643 — Re: Java is faster!

On 23 Sep 2016 13:31:38 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

>      "Java is faster!


faster than C++?  Faster than Java used to be?

[toc] | [next] | [standalone]

#35647

Since Java is typesafe, and this typesafety goes
vary far, recently, after much time, I have
even created a runtime error when assigning
an array cell, so the component type of the array
didn't match the element type.

I think there is a general limit. This typesafety
is still ingrained in the runtime. Although casts
are highly optimized, they don't go away. I recently
made some other experiments, and bumpted my head
speed wise just because of the many casts I needed.

So if all is well typed, no casts and a lot of primitive
types, I guess you get speed. But if you use more
generic data structures, I see some problems just
because of the casts, although some caching techniques
are used inside the JVM.(*)

http://stackoverflow.com/questions/2170872/does-java-casting-introduce-overhead-why

(*) There are tons of patentsn by Sun etc.., but
I don't know whats currently going in a JVM on.
Newest JDK allows methods in interfaces, etc..
JVM getting complexer from release to release.

Roedy Green schrieb:
> On 23 Sep 2016 13:31:38 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
> wrote:
>
>>       "Java is faster!
>
>
> faster than C++?  Faster than Java used to be?
>

[toc] | [prev] | [next] | [standalone]

#35648

On 9/25/2016 2:05 PM, j4n bur53 wrote:
> Since Java is typesafe, and this typesafety goes
> vary far, recently, after much time, I have
> even created a runtime error when assigning
> an array cell, so the component type of the array
> didn't match the element type.

     Many Java programmers consider this a Good Thing.

> I think there is a general limit. This typesafety
> is still ingrained in the runtime. Although casts
> are highly optimized, they don't go away. I recently
> made some other experiments, and bumpted my head
> speed wise just because of the many casts I needed.

     How did you measure the time consumed by the casts?  That is,
what kind of experiment did you perform to accomplish "the same"
computation without the casts?

     Hmm: I suppose you could re-write your classes to use Object
references instead of Strings and JButtons and so on, and insert
casts as needed:

	// String s = "Hello";
	Object s = "Hello";

	// int length = s.length();
	int length = ((String) s).length();

... for some very large set of references, and then compare the
run times of the cast-free and cast-heavy versions.  Did you do
something of that kind, or measure the penalty in some other way?

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35653

Yes and Yes.

Eric Sosman schrieb:
> On 9/25/2016 2:05 PM, j4n bur53 wrote:
>> Since Java is typesafe, and this typesafety goes
>> vary far, recently, after much time, I have
>> even created a runtime error when assigning
>> an array cell, so the component type of the array
>> didn't match the element type.
>
>      Many Java programmers consider this a Good Thing.
>
>> I think there is a general limit. This typesafety
>> is still ingrained in the runtime. Although casts
>> are highly optimized, they don't go away. I recently
>> made some other experiments, and bumpted my head
>> speed wise just because of the many casts I needed.
>
>      How did you measure the time consumed by the casts?  That is,
> what kind of experiment did you perform to accomplish "the same"
> computation without the casts?
>
>      Hmm: I suppose you could re-write your classes to use Object
> references instead of Strings and JButtons and so on, and insert
> casts as needed:
>
>      // String s = "Hello";
>      Object s = "Hello";
>
>      // int length = s.length();
>      int length = ((String) s).length();
>
> ... for some very large set of references, and then compare the
> run times of the cast-free and cast-heavy versions.  Did you do
> something of that kind, or measure the penalty in some other way?
>

[toc] | [prev] | [next] | [standalone]

#35659

On 9/26/2016 5:09 PM, j4n bur53 wrote:
> Yes and Yes.
> [The second "Yes" answering my question about how he measured
> the cost of casting.]

     If your results are not proprietary trade secrets or something,
could you disclose them?  We all realize that different machines/JVM's
will produce different timings for identical classes, but even some
not-completely-reliable "indicative" numbers would be of considerable
interest to me, and, I imagine, to others as well.

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35664

Am 27.09.2016 um 20:21 schrieb Eric Sosman:
> On 9/26/2016 5:09 PM, j4n bur53 wrote:
>> Yes and Yes.
>> [The second "Yes" answering my question about how he measured
>> the cost of casting.]
>
>     If your results are not proprietary trade secrets or something,
> could you disclose them?  We all realize that different machines/JVM's
> will produce different timings for identical classes, but even some
> not-completely-reliable "indicative" numbers would be of considerable
> interest to me, and, I imagine, to others as well.
>
Well, Marko Topolnik has already taken the trouble, see here:
http://stackoverflow.com/a/17764556

tl;dr: there is no noticeable cost to casting

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#35665

On 9/28/2016 2:20 PM, Sebastian wrote:
> Am 27.09.2016 um 20:21 schrieb Eric Sosman:
>> On 9/26/2016 5:09 PM, j4n bur53 wrote:
>>> Yes and Yes.
>>> [The second "Yes" answering my question about how he measured
>>> the cost of casting.]
>>
>>     If your results are not proprietary trade secrets or something,
>> could you disclose them?  We all realize that different machines/JVM's
>> will produce different timings for identical classes, but even some
>> not-completely-reliable "indicative" numbers would be of considerable
>> interest to me, and, I imagine, to others as well.
>>
> Well, Marko Topolnik has already taken the trouble, see here:
> http://stackoverflow.com/a/17764556
>
> tl;dr: there is no noticeable cost to casting

     Three observations:

     First, cheap casts would appear to be a prerequisite for a usable
JVM.  Applying a cast to a reference should be approximately as hard
as discovering the class of the referenced object, and Java does this
a LOT.  Every call to a possibly-overridden method, for example, needs
to discover which class provides the method's code.  If casts were slow,
the "approximately equivalent effort" of method dispatch would also be
slow, and Java itself would be slow.  (Or "slowER," for you doubters.)

     Second, Jan Burse has reported elsethread that casts have caused
performance problems for him: "[...] bumpted my head speed wise just
because of the many casts I needed."  I find this surprising, and am
interested in learning more about his results (if he's at liberty to
share them).  Although the First point "stands to reason," actual
data trumps "stands to reason" any day.

     Third, Marko Topolnik's benchmark doesn't seem terribly convincing
to me (even though it supports First).  It may in fact be correct, but
there's a lot more going on than the cast vs. no-cast comparison, and
I'm worried that the difference he's trying to measure may have been
lost in the noise.  For example, note that the testNoDowncast() method
does in fact perform at least ten thousand downcasts. testDowncast()
performs twenty thousand, but comparing 2N to N instead of N to 0 is
at the very least an eyebrow-raiser.  (In Topolnik's defense, he's
trying to answer a slightly more specific question than the one we're
wondering about.)

     So, I hope Jan can show his results.

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35666

Eric Sosman schrieb:
>      Third, Marko Topolnik's benchmark doesn't seem terribly convincing
> to me (even though it supports First).  It may in fact be correct, but
> there's a lot more going on than the cast vs. no-cast comparison, and
> I'm worried that the difference he's trying to measure may have been
> lost in the noise.  For example, note that the testNoDowncast() method
> does in fact perform at least ten thousand downcasts. testDowncast()
> performs twenty thousand, but comparing 2N to N instead of N to 0 is
> at the very least an eyebrow-raiser.  (In Topolnik's defense, he's
> trying to answer a slightly more specific question than the one we're
> wondering about.)
>
>      So, I hope Jan can show his results.

My test case is an interpreter basically based on a trampolin
architecture(*). So anything that happens in the main loop
of the trampolin is directly visible as speed impact, since
it is multiplied by the high number of interations through
the trampolin.

So micro benchmark results highly apply to this code. And
last time when I went through the code I could eliminate
a cast here and then, by some code movememts and better
typing and I got slightly better results. I have some
measurements, which I could share.

But unfortunately they measure the total of all changes
I did. I also did some more changes, for example was
using an enumerate in one place where before I was
calling new to create an object.

https://en.wikipedia.org/wiki/Trampoline_%28computing%29

[toc] | [prev] | [next] | [standalone]

#35669

On 9/25/2016 2:05 PM, j4n bur53 wrote:
> Since Java is typesafe, and this typesafety goes
> vary far, recently, after much time, I have
> even created a runtime error when assigning
> an array cell, so the component type of the array
> didn't match the element type.
>
> I think there is a general limit. This typesafety
> is still ingrained in the runtime. Although casts
> are highly optimized, they don't go away. I recently
> made some other experiments, and bumpted my head
> speed wise just because of the many casts I needed.
>
> So if all is well typed, no casts and a lot of primitive
> types, I guess you get speed. But if you use more
> generic data structures, I see some problems just
> because of the casts, although some caching techniques
> are used inside the JVM.(*)

This is probably mostly important in what was once
labeled scientific computing (as opposed to business
computing).

In theory I think the JIT compiler could move a lot
of the type checking outside of inner loops and thereby
minimize the overhead.

But there are probably some impact left.

Also note that Java has never gained so much
traction in scientific computing as in many other
areas.

I suspect that type check, array index check
and lack of user defined value types play a role
in that.

Arne

[toc] | [prev] | [next] | [standalone]

#35649

On 9/25/2016 6:28 AM, Roedy Green wrote:
> On 23 Sep 2016 13:31:38 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
> wrote:
> 
>>      "Java is faster!
> 
> 
> faster than C++?  Faster than Java used to be?
> 

Faster than BASIC on a TRS-80. :)

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#35652

On Sunday, September 25, 2016 at 4:37:13 PM UTC-4, Jerry Stuckle wrote:
> >>      "Java is faster!
> > 
> > 
> > faster than C++?  Faster than Java used to be?
> > 
> 
> Faster than BASIC on a TRS-80. :)

Hey, my 1000 line program to draw one picture on screen using ascii blocks was very efficient!

[toc] | [prev] | [next] | [standalone]

#35718

On 26.09.2016 14:47, Eric Douglas wrote:
> On Sunday, September 25, 2016 at 4:37:13 PM UTC-4, Jerry Stuckle wrote:
>>>>      "Java is faster!
>>>
>>>
>>> faster than C++?  Faster than Java used to be?
>>>
>>
>> Faster than BASIC on a TRS-80. :)
>
> Hey, my 1000 line program to draw one picture on screen using ascii blocks was very efficient!

efficient != fast

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#35668

On 9/25/2016 6:28 AM, Roedy Green wrote:
> On 23 Sep 2016 13:31:38 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
> wrote:
>
>>      "Java is faster!
>
>
> faster than C++?  Faster than Java used to be?

Read the remaining lines:

#      In terms of throughput in a long running system ...
#      For specific applications ...
#      On a well tuned JVM ...
#      With near-optimal GC strategy selected ..."
#
#  says Chandler Carruth, one of Google's C++ experts. (JFTR)

And make a guess.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web