Path: csiph.com!aioe.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk>
Newsgroups: comp.lang.java.programmer
Subject: Re: One code is aggressively optimised, while another not. Why?
Date: Wed, 12 Jul 2017 21:02:55 -0400
Organization: Aioe.org NNTP Server
Lines: 73
Message-ID: <ok6gru$8dl$1@gioia.aioe.org>
References: <87lgnu5b9o.fsf@munus.decebal.nl>
NNTP-Posting-Host: PBuS014lhzVyHjLbXmo/ZQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.java.programmer:36873

On 7/12/2017 4:07 AM, Cecil Westerhof wrote:
> I am looking into some performance metrics. I have the following code:
>      long sum = 0L;
> 
>      for (long i = start; i < end; ++i) {
>          sum += i;
>      }
> 
> And this code:
>      long sum = 0L;
> 
>      for (int i = start; i < end; ++i) {
>          sum += i;
>      }
> 
> Start and end are defined like:
>      private static int end   = Integer.MAX_VALUE;
>      private static int start = Integer.MIN_VALUE;
> 
> 
> The second code takes about 50% more time to execute. No surprise
> there. But the first code is aggressively optimised when run several
> times (the fifth run is about 2½ million times faster as the first
> run), while the second code is not optimised:
>      09:41:10: Timing long int
>      09:41:10: took 2.08E+00 seconds.
>      09:41:13: took 1.29E-03 seconds.
>      09:41:13: took 1.25E-04 seconds.
>      09:41:13: took 1.36E-06 seconds.
>      09:41:13: took 7.97E-07 seconds.
> 
>      09:41:13: Timing long long
>      09:41:13: took 3.09E+00 seconds.
>      09:41:16: took 3.11E+00 seconds.
>      09:41:19: took 4.03E+00 seconds.
>      09:41:23: took 3.94E+00 seconds.
>      09:41:27: took 3.87E+00 seconds.
> 
> Why the difference?

Other have already commented on the specifics.

But let me add a few general comments.

Optimizers are pretty smart these days, but they are not human. They
recognize certain patterns and do certain optimizations on them.

For a real world application consisting of thousands or tens
of thousands of constructs, then the optimizer get a large part
of them right and the result is an overall good performance.

But if you focus on just a single construct, then it becomes
almost random if the optimizer get it right or not.

And that conclusion is not constant over time. Any time
you switch Java version, then the optimizer can work
the same or do a better job or do a worse job.

Testing an extremely unrealistic small program for
something that is known that it can change with any
new Java version is in general not very productive.

Unless you happen to do number crunching and you need
to optimize DAXPY, then there are most likely much
better usage of the time.

Arne