From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 required=3.0 tests=BAYES_00,NICE_REPLY_A
	autolearn=ham autolearn_force=no version=3.4.6
Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Not good for Ada endorsement
Date: Thu, 8 Jul 2021 12:42:25 +0200
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <sc6kqh$1sj$1@dont-email.me>
References: <cd296b88-2e0a-403f-82c7-973e41fa7331n@googlegroups.com>
 <sc4fuo$8vn$1@gioia.aioe.org> <e9hbeg9014he87s6kbrkinrt4tre1cfgqc@4ax.com>
 <ly8s2iorpl.fsf@pushface.org> <5a1cegtfm5ibqej3ldebpc4g99ujniqt9u@4ax.com>
 <a0080e82-2f52-4fd7-9c44-6bc2d8f0664bn@googlegroups.com>
 <sc6cgh$9vu$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 8 Jul 2021 10:42:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="cb2457d9224309e070dc9e984a070cbf";
	logging-data="1939"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18JO+GlGljPhiBPi9uY+CLeoHx19bem1O0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
Cancel-Lock: sha1:KGUtiTX1EvZtDE1FNAngs3p0hm4=
In-Reply-To: <sc6cgh$9vu$1@dont-email.me>
Content-Language: en-US
Xref: reader02.eternal-september.org comp.lang.ada:62353
List-Id: <comp.lang.ada>

On 7/8/21 10:20 AM, Jeffrey R. Carter wrote:
> 
> Compiling with -gnatp -O3 would undoubtedly speed it up (suppressing checks is 
> justified since execution with checks active shows that no checks fail).
> 
> Looking casually at the code, the map could be replaced by a constant, as 
> Sieve_Size is hard coded to 1,000,000, and the filling of the map is included in 
> the timing. The calculation of the square root of 1,000,000 could be replaced by 
> a constant. The array of Boolean could be constrained to 3 .. Sieve_Size. The 
> function that simply returns (others => True) could be replaced by the 
> aggregate, though optimization will probably do that. Long_Long_Integer could be 
> replaced by a type with range 0 .. 2 ** 31 - 1, though I don't know if that 
> would have any effect. The first inner loop in the sieve algorithm could be 
> eliminated, in which case the initialization of Num could also be removed.

Compiling the original code with

gnatmake prime_sieve.adb

gives 408 passes in 5 seconds.

Making the changes listed above (I used Interfaces.Integer_32) and compiling with

gnatmake -O3 prime_sieve.adb

(to ensure that no checks fail) gives 2087 passes in 5 seconds, for a factor of 5.1.

Applying that to the reported 67 passes/second for the original on the test 
system implies that this version, compiled with checks enabled and optimization, 
would give 343 passes/second.

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81