Re: Not good for Ada endorsement

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2021-07-08 10:20, Jeffrey R. Carter wrote:
> On 7/8/21 5:46 AM, Richard Iswara wrote:
>> Indirectly it is a comparison of implementation and tools 
>> benchmarking. Looking at the gpr file, there is no compile switch 
>> used, not even an "-o2" switch.
> 
> 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.

Exactly, this is what is wrong with such contests. The solution is 
non-scalable giving advantage to low-level languages like C. Scalability 
and readability has the price that hobby-sized instances work poorly.

P.S. I would also suggest ensuring the Boolean array not packed. If not 
with compiler switches and pragmas then by declaring a custom Boolean 
1,2,4,8 bytes long depending on the target architecture. It is not a 
fair play, guys!


-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de