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


Groups > comp.lang.java.programmer > #36906

Re: One code is aggressively optimised, while another not. Why?

Path csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From Cecil Westerhof <Cecil@decebal.nl>
Newsgroups comp.lang.java.programmer
Subject Re: One code is aggressively optimised, while another not. Why?
Date Thu, 13 Jul 2017 19:51:45 +0200
Organization Decebal Computing
Lines 106
Message-ID <8760ew443y.fsf@munus.decebal.nl> (permalink)
References <87lgnu5b9o.fsf@munus.decebal.nl> <ok58hq$s4n$1@dont-email.me> <87h8yg6ag8.fsf@munus.decebal.nl> <ok820t$786$1@dont-email.me> <87a84846uu.fsf@munus.decebal.nl>
Mime-Version 1.0
Content-Type text/plain
Injection-Info mx02.eternal-september.org; posting-host="cea988b749795bfe5e66959d383985c6"; logging-data="15431"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LnS7AHgaehcOE53KXfH0nKANG/KN2PaM="
User-Agent Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
X-Homepage http://www.decebal.nl/
Cancel-Lock sha1:LZ5KZVm7mor2QDc6LxGg7rnoq1U= sha1:VhggPm+SS2Jtw01LoBm94TinPaw=
Xref csiph.com comp.lang.java.programmer:36906

Show key headers only | View raw


Cecil Westerhof <Cecil@decebal.nl> writes:

> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>     Explanation/Rationale: Each test runs a loop to compute a sum,
>> but the sum is never subsequently used for anything at all: It is
>> not printed, it is not tested, it participates in no further
>> computation of any kind.  The JVM may well notice this and decide
>> not to bother computing the sum since it isn't needed.  A loop
>> that starts out as
>>
>> 	long sum = 0;
>> 	for (int i = start; i < end; ++i) {
>> 	    sum += i;
>> 	}
>>
>> ... may then be transformed to
>>
>> 	for (int i = start; i < end; ++i) {
>> 	}
>>
>> ... which (since the loop has no effect on anything except `i',
>> which is itself not used outside the loop) may be further
>> optimized to
>>
>> 	{
>> 	}
>>
>> ... which casts just a wee bit of suspicion on the timings ;).
>
> OK, I change the code to return the sum.

I rewrote the code and use Supplier<Long> now. That gives more sane
values. (Next time I should think twice before posting.)

I now get:
    19:10:13: Timing long int    
    19:10:13: took 2.95E+00 seconds.
    19:10:16: took 3.05E+00 seconds.
    19:10:19: took 3.05E+00 seconds.
    19:10:22: took 3.05E+00 seconds.
    19:10:25: took 3.04E+00 seconds.

    19:10:28: Timing long long   
    19:10:28: took 8.71E+00 seconds.
    19:10:37: took 8.79E+00 seconds.
    19:10:46: took 8.67E+00 seconds.
    19:10:54: took 8.68E+00 seconds.
    19:11:03: took 8.70E+00 seconds.

    19:11:12: Timing Long int    
    19:11:12: took 7.24E+01 seconds.
    19:12:24: took 7.08E+01 seconds.
    19:13:35: took 7.17E+01 seconds.
    19:14:46: took 7.01E+01 seconds.
    19:15:57: took 6.96E+01 seconds.

    19:17:06: Timing Long long   
    19:17:06: took 7.75E+01 seconds.
    19:18:24: took 7.82E+01 seconds.
    19:19:42: took 7.68E+01 seconds.
    19:20:59: took 7.68E+01 seconds.
    19:22:15: took 7.80E+01 seconds.

    19:23:33: Timing long Integer
    19:23:33: took 2.75E+01 seconds.
    19:24:01: took 2.75E+01 seconds.
    19:24:28: took 2.77E+01 seconds.
    19:24:56: took 2.76E+01 seconds.
    19:25:24: took 2.77E+01 seconds.

    19:25:51: Timing long Long   
    19:25:51: took 3.89E+01 seconds.
    19:26:30: took 3.89E+01 seconds.
    19:27:09: took 3.89E+01 seconds.
    19:27:48: took 3.90E+01 seconds.
    19:28:27: took 3.90E+01 seconds.

    19:29:06: Timing Long Integer
    19:29:06: took 7.99E+01 seconds.
    19:30:26: took 7.96E+01 seconds.
    19:31:46: took 7.95E+01 seconds.
    19:33:05: took 8.03E+01 seconds.
    19:34:26: took 7.72E+01 seconds.

    19:35:43: Timing Long Long   
    19:35:43: took 9.17E+01 seconds.
    19:37:15: took 9.15E+01 seconds.
    19:38:46: took 9.18E+01 seconds.
    19:40:18: took 9.19E+01 seconds.
    19:41:50: took 9.47E+01 seconds.

So long/integer is about three times as fast as long/long.
And long/long is about eight times as fast as Long/long.
Also long/long is about ten times as fast as Long/Long.

So I think it is save to say that when you could use an integer, you
should not use a long.
And that when you need to do a lot of calculations you should wait as
long as possible before converting to Long.

Or am I still overlooking something?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

One code is aggressively optimised, while another not. Why? Cecil Westerhof <Cecil@decebal.nl> - 2017-07-12 10:07 +0200
  Re: One code is aggressively optimised, while another not. Why? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-12 09:38 -0400
    Re: One code is aggressively optimised, while another not. Why? Cecil Westerhof <Cecil@decebal.nl> - 2017-07-13 09:51 +0200
      Re: One code is aggressively optimised, while another not. Why? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-13 11:05 -0400
        Re: One code is aggressively optimised, while another not. Why? Cecil Westerhof <Cecil@decebal.nl> - 2017-07-13 18:52 +0200
          Re: One code is aggressively optimised, while another not. Why? Cecil Westerhof <Cecil@decebal.nl> - 2017-07-13 19:51 +0200
  Re: One code is aggressively optimised, while another not. Why? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2017-07-12 09:19 -0500
    Re: One code is aggressively optimised, while another not. Why? Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-12 17:04 +0000
  Re: One code is aggressively optimised, while another not. Why? Arne VajhĂžj <arne@vajhoej.dk> - 2017-07-12 21:02 -0400

csiph-web