Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #36906
| 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
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