Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Cecil Westerhof 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> References: <87lgnu5b9o.fsf@munus.decebal.nl> <87h8yg6ag8.fsf@munus.decebal.nl> <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 Cecil Westerhof writes: > Eric Sosman 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 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