* Re: Not good for Ada endorsement
2021-07-08 8:20 ` Jeffrey R. Carter
@ 2021-07-08 8:42 ` Dmitry A. Kazakov
2021-07-08 8:52 ` Luke A. Guest
2021-07-08 10:42 ` Jeffrey R. Carter
2 siblings, 0 replies; 38+ messages in thread
From: Dmitry A. Kazakov @ 2021-07-08 8:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 8:20 ` Jeffrey R. Carter
2021-07-08 8:42 ` Dmitry A. Kazakov
@ 2021-07-08 8:52 ` Luke A. Guest
2021-07-08 10:42 ` Jeffrey R. Carter
2 siblings, 0 replies; 38+ messages in thread
From: Luke A. Guest @ 2021-07-08 8:52 UTC (permalink / raw)
On 08/07/2021 09: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.
I did wonder about that as I haven't got around to looking through it yet.
> Compiling with -gnatp -O3 would undoubtedly speed it up (suppressing
> checks is justified since execution with checks active shows that no
> checks fail).
I got nothing from the output of trying to run just the Ada version.
> 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
In the video he mentions Pascal's version only being 32 bit and his is 64.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 8:20 ` Jeffrey R. Carter
2021-07-08 8:42 ` Dmitry A. Kazakov
2021-07-08 8:52 ` Luke A. Guest
@ 2021-07-08 10:42 ` Jeffrey R. Carter
2021-07-08 10:51 ` Luke A. Guest
2 siblings, 1 reply; 38+ messages in thread
From: Jeffrey R. Carter @ 2021-07-08 10:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 10:42 ` Jeffrey R. Carter
@ 2021-07-08 10:51 ` Luke A. Guest
2021-07-08 11:12 ` Jeffrey R. Carter
0 siblings, 1 reply; 38+ messages in thread
From: Luke A. Guest @ 2021-07-08 10:51 UTC (permalink / raw)
On 08/07/2021 11:42, Jeffrey R. Carter wrote:
Here's the playlist
https://youtube.com/playlist?list=PLF2KJ6Gy3cZ5Er-1eF9fN1Hgw_xkoD9V1 the
second video is where he sets up Python, C# and C++.
> 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.
He shows the C++ jumping from 4645 (https://youtu.be/D3h62rgewZM?t=1246)
to 7,436 (https://youtu.be/D3h62rgewZM?t=1306) passes going from 32 to
64 bit.
He also uses clang's -Ofast option to compile for speed over size.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 10:51 ` Luke A. Guest
@ 2021-07-08 11:12 ` Jeffrey R. Carter
2021-07-08 17:37 ` Luke A. Guest
0 siblings, 1 reply; 38+ messages in thread
From: Jeffrey R. Carter @ 2021-07-08 11:12 UTC (permalink / raw)
On 7/8/21 12:51 PM, Luke A. Guest wrote:
>
> On 08/07/2021 11:42, Jeffrey R. Carter wrote:
>
> Here's the playlist
> https://youtube.com/playlist?list=PLF2KJ6Gy3cZ5Er-1eF9fN1Hgw_xkoD9V1 the second
> video is where he sets up Python, C# and C++.
>
>> 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.
>
> He shows the C++ jumping from 4645 (https://youtu.be/D3h62rgewZM?t=1246) to
> 7,436 (https://youtu.be/D3h62rgewZM?t=1306) passes going from 32 to 64 bit.
>
> He also uses clang's -Ofast option to compile for speed over size.
Going back to 64-bit integers gives 1999; with -gnatp, 2098
--
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 11:12 ` Jeffrey R. Carter
@ 2021-07-08 17:37 ` Luke A. Guest
2021-07-08 17:43 ` Luke A. Guest
` (3 more replies)
0 siblings, 4 replies; 38+ messages in thread
From: Luke A. Guest @ 2021-07-08 17:37 UTC (permalink / raw)
On 08/07/2021 12:12, Jeffrey R. Carter wrote:
>> He also uses clang's -Ofast option to compile for speed over size.
>
> Going back to 64-bit integers gives 1999; with -gnatp, 2098
>
I've uploaded my version here
https://github.com/Lucretia/Primes/tree/add-optimised-ada/PrimeAda/solution_2
It's as straight a conversion from the C++ to Ada. I intend to keep
optimising it.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 17:37 ` Luke A. Guest
@ 2021-07-08 17:43 ` Luke A. Guest
2021-07-08 19:16 ` Luke A. Guest
2021-07-08 19:16 ` Luke A. Guest
` (2 subsequent siblings)
3 siblings, 1 reply; 38+ messages in thread
From: Luke A. Guest @ 2021-07-08 17:43 UTC (permalink / raw)
On 08/07/2021 18:37, Luke A. Guest wrote:
> On 08/07/2021 12:12, Jeffrey R. Carter wrote:
>
>>> He also uses clang's -Ofast option to compile for speed over size.
>>
>> Going back to 64-bit integers gives 1999; with -gnatp, 2098
>>
>
> I've uploaded my version here
> https://github.com/Lucretia/Primes/tree/add-optimised-ada/PrimeAda/solution_2
>
>
> It's as straight a conversion from the C++ to Ada. I intend to keep
> optimising it.
As a quick test, I removed the Pack attribute from the Bits array and
got the following speed:
debug0:
Passes: 1108, Time: 5.003198, Avg: 0.004515521, Limit: 1000000,
Count1: 78498, Count2: 78498, Valid: TRUE
Lucretia;1108; 5.003198;algorithm=base,faithful=yes,bits=8
optimised:
Passes: 3286, Time: 5.000592, Avg: 0.001521786, Limit: 1000000,
Count1: 78498, Count2: 78498, Valid: TRUE
Lucretia;3286; 5.000592;algorithm=base,faithful=yes,bits=8
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 17:43 ` Luke A. Guest
@ 2021-07-08 19:16 ` Luke A. Guest
0 siblings, 0 replies; 38+ messages in thread
From: Luke A. Guest @ 2021-07-08 19:16 UTC (permalink / raw)
On 08/07/2021 18:43, Luke A. Guest wrote:
> debug0:
> Passes: 1108, Time: 5.003198, Avg: 0.004515521, Limit: 1000000,
> Count1: 78498, Count2: 78498, Valid: TRUE
> Lucretia;1108; 5.003198;algorithm=base,faithful=yes,bits=8
>
> optimised:
> Passes: 3286, Time: 5.000592, Avg: 0.001521786, Limit: 1000000,
> Count1: 78498, Count2: 78498, Valid: TRUE
> Lucretia;3286; 5.000592;algorithm=base,faithful=yes,bits=8
I've updated again, moving the main function to the generic, strange
results.
This also now used packed and unpacked boolean arrays.
I'd be interested to see what numbers your machines get, mine's a tad
ancient now.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 17:37 ` Luke A. Guest
2021-07-08 17:43 ` Luke A. Guest
@ 2021-07-08 19:16 ` Luke A. Guest
2021-07-09 2:47 ` Richard Iswara
2021-07-09 8:10 ` Paul Rubin
2021-07-09 8:33 ` Egil H H
3 siblings, 1 reply; 38+ messages in thread
From: Luke A. Guest @ 2021-07-08 19:16 UTC (permalink / raw)
On 08/07/2021 18:37, Luke A. Guest wrote:
> On 08/07/2021 12:12, Jeffrey R. Carter wrote:
>
>>> He also uses clang's -Ofast option to compile for speed over size.
>>
>> Going back to 64-bit integers gives 1999; with -gnatp, 2098
>>
>
> I've uploaded my version here
> https://github.com/Lucretia/Primes/tree/add-optimised-ada/PrimeAda/solution_2
>
>
> It's as straight a conversion from the C++ to Ada. I intend to keep
> optimising it.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 17:37 ` Luke A. Guest
2021-07-08 17:43 ` Luke A. Guest
2021-07-08 19:16 ` Luke A. Guest
@ 2021-07-09 8:10 ` Paul Rubin
2021-07-09 8:24 ` Egil H H
2021-07-09 8:33 ` Egil H H
3 siblings, 1 reply; 38+ messages in thread
From: Paul Rubin @ 2021-07-09 8:10 UTC (permalink / raw)
"Luke A. Guest" <laguest@archeia.com> writes:
> It's as straight a conversion from the C++ to Ada. I intend to keep
> optimising it.
I'd be interested in seeing a straight conversion of Pascal to Ada, if
the existing Ada code differs significantly from the existing Pascal
code in a way that affects the speed and isn't a straightforward
conversion.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-09 8:10 ` Paul Rubin
@ 2021-07-09 8:24 ` Egil H H
0 siblings, 0 replies; 38+ messages in thread
From: Egil H H @ 2021-07-09 8:24 UTC (permalink / raw)
On Friday, July 9, 2021 at 10:10:37 AM UTC+2, Paul Rubin wrote:
> "Luke A. Guest" <> writes:
> > It's as straight a conversion from the C++ to Ada. I intend to keep
> > optimising it.
> I'd be interested in seeing a straight conversion of Pascal to Ada, if
> the existing Ada code differs significantly from the existing Pascal
> code in a way that affects the speed and isn't a straightforward
> conversion.
One significant difference between the original Ada version and the Pascal and C++ versions, is
that Ada is missing a Num := Factor before the first inner loop.
(Luke fixed that in his version, though)
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-08 17:37 ` Luke A. Guest
` (2 preceding siblings ...)
2021-07-09 8:10 ` Paul Rubin
@ 2021-07-09 8:33 ` Egil H H
2021-07-09 9:16 ` Jeffrey R. Carter
3 siblings, 1 reply; 38+ messages in thread
From: Egil H H @ 2021-07-09 8:33 UTC (permalink / raw)
On Thursday, July 8, 2021 at 7:38:19 PM UTC+2, Luke A. Guest wrote:
> On 08/07/2021 12:12, Jeffrey R. Carter wrote:
>
> >> He also uses clang's -Ofast option to compile for speed over size.
> >
> > Going back to 64-bit integers gives 1999; with -gnatp, 2098
> >
> I've uploaded my version here
> https://github.com/Lucretia/Primes/tree/add-optimised-ada/PrimeAda/solution_2
>
> It's as straight a conversion from the C++ to Ada. I intend to keep
> optimising it.
On my computer, at least, GNAT is not happy about incrementing Number by 2
in the inner loop. I get a bit better performance by modifying the check to
if Number mod 2 /= 0 and then Sieve.Bits(Index_Type(Number)) then
and then incrementing Number by 1.
Or even rewriting to a for-loop
Is_Prime : for Foo in Index_Type (Factor)..Sieve.Size loop
if Foo mod 2 /= 0 and then Sieve.Bits (Foo) then
Factor := Integer(Foo);
exit Is_Prime;
end if;
end loop Is_Prime;
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-09 8:33 ` Egil H H
@ 2021-07-09 9:16 ` Jeffrey R. Carter
2021-07-09 9:21 ` Jeffrey R. Carter
0 siblings, 1 reply; 38+ messages in thread
From: Jeffrey R. Carter @ 2021-07-09 9:16 UTC (permalink / raw)
On 7/9/21 10:33 AM, Egil H H wrote:
>
> On my computer, at least, GNAT is not happy about incrementing Number by 2
> in the inner loop. I get a bit better performance by modifying the check to
>
> if Number mod 2 /= 0 and then Sieve.Bits(Index_Type(Number)) then
>
> and then incrementing Number by 1.
Since both operands are positive, mod and rem give the same results, and rem is
usually a bit faster. It's normally not an issue, but in this case it's done
billions of times, so it might make a difference.
--
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-09 9:16 ` Jeffrey R. Carter
@ 2021-07-09 9:21 ` Jeffrey R. Carter
2021-07-15 15:13 ` Lucretia
0 siblings, 1 reply; 38+ messages in thread
From: Jeffrey R. Carter @ 2021-07-09 9:21 UTC (permalink / raw)
On 7/9/21 11:16 AM, Jeffrey R. Carter wrote:
> On 7/9/21 10:33 AM, Egil H H wrote:
>>
>> On my computer, at least, GNAT is not happy about incrementing Number by 2
>> in the inner loop. I get a bit better performance by modifying the check to
>>
>> if Number mod 2 /= 0 and then Sieve.Bits(Index_Type(Number)) then
>>
>> and then incrementing Number by 1.
>
> Since both operands are positive, mod and rem give the same results, and rem is
> usually a bit faster. It's normally not an issue, but in this case it's done
> billions of times, so it might make a difference.
Note also that short-circuit forms (and then) require disabling processor-level
optimizations and may have a negative effect on execution time when used
unnecessarily.
--
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-09 9:21 ` Jeffrey R. Carter
@ 2021-07-15 15:13 ` Lucretia
2021-07-15 15:56 ` Jeffrey R. Carter
0 siblings, 1 reply; 38+ messages in thread
From: Lucretia @ 2021-07-15 15:13 UTC (permalink / raw)
On Friday, 9 July 2021 at 10:21:05 UTC+1, Jeffrey R. Carter wrote:
> On 7/9/21 11:16 AM, Jeffrey R. Carter wrote:
> >> if Number mod 2 /= 0 and then Sieve.Bits(Index_Type(Number)) then
> >>
> >> and then incrementing Number by 1.
> >
> > Since both operands are positive, mod and rem give the same results, and rem is
> > usually a bit faster. It's normally not an issue, but in this case it's done
> > billions of times, so it might make a difference.
> Note also that short-circuit forms (and then) require disabling processor-level
> optimizations and may have a negative effect on execution time when used
> unnecessarily.
You don't need those as the algorithm always starts at 3 and increments by 2.
I managed to get just under 4000 passes with a 1 bit array, but not using Ada's packed array. That's actually the slowest method, strangely.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 15:13 ` Lucretia
@ 2021-07-15 15:56 ` Jeffrey R. Carter
2021-07-15 16:29 ` Anh Vo
2021-07-15 16:29 ` Lucretia
0 siblings, 2 replies; 38+ messages in thread
From: Jeffrey R. Carter @ 2021-07-15 15:56 UTC (permalink / raw)
On 7/15/21 5:13 PM, Lucretia wrote:
>
> I managed to get just under 4000 passes with a 1 bit array, but not using Ada's packed array. That's actually the slowest method, strangely.
So you have an array of a modular type, calculate an index and bit within it,
mask out that bit, and compare it to zero? I would have thought an unpacked
array of Boolean would be fastest.
A packed array of Boolean requires all the operations above, plus shifting the
bit to the LSB and treating the result as a Boolean, so it may not be that
surprising that it's slower.
--
Jeff Carter
"How'd you like to hide the egg and gurgitate
a few saucers of mocha java?"
Never Give a Sucker an Even Break
101
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 15:56 ` Jeffrey R. Carter
@ 2021-07-15 16:29 ` Anh Vo
2021-07-15 17:30 ` Lucretia
2021-07-23 17:04 ` Anh Vo
2021-07-15 16:29 ` Lucretia
1 sibling, 2 replies; 38+ messages in thread
From: Anh Vo @ 2021-07-15 16:29 UTC (permalink / raw)
On Thursday, July 15, 2021 at 8:56:40 AM UTC-7, Jeffrey R. Carter wrote:
> On 7/15/21 5:13 PM, Lucretia wrote:
> >
> > I managed to get just under 4000 passes with a 1 bit array, but not using Ada's packed array. That's actually the slowest method, strangely.
> So you have an array of a modular type, calculate an index and bit within it,
> mask out that bit, and compare it to zero? I would have thought an unpacked
> array of Boolean would be fastest.
>
> A packed array of Boolean requires all the operations above, plus shifting the
> bit to the LSB and treating the result as a Boolean, so it may not be that
> surprising that it's slower.
Should fixed lower bound index array (-gnatX) speed it up?
Anh Vo
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 16:29 ` Anh Vo
@ 2021-07-15 17:30 ` Lucretia
2021-07-16 16:27 ` Simon Wright
2021-07-16 16:28 ` Simon Wright
2021-07-23 17:04 ` Anh Vo
1 sibling, 2 replies; 38+ messages in thread
From: Lucretia @ 2021-07-15 17:30 UTC (permalink / raw)
On Thursday, 15 July 2021 at 17:29:52 UTC+1, Anh Vo wrote:
> > A packed array of Boolean requires all the operations above, plus shifting the
> > bit to the LSB and treating the result as a Boolean, so it may not be that
> > surprising that it's slower.
> Should fixed lower bound index array (-gnatX) speed it up?
On GCC 9.3.0:
-gnatX Language extensions permitted
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 17:30 ` Lucretia
@ 2021-07-16 16:27 ` Simon Wright
2021-07-16 16:28 ` Simon Wright
1 sibling, 0 replies; 38+ messages in thread
From: Simon Wright @ 2021-07-16 16:27 UTC (permalink / raw)
Lucretia <laguest9000@googlemail.com> writes:
> On Thursday, 15 July 2021 at 17:29:52 UTC+1, Anh Vo wrote:
>
>> > A packed array of Boolean requires all the operations above, plus
>> > shifting the
>> > bit to the LSB and treating the result as a Boolean, so it may not be that
>> > surprising that it's slower.
>> Should fixed lower bound index array (-gnatX) speed it up?
>
> On GCC 9.3.0:
>
> -gnatX Language extensions permitted
Ah, but which ones?
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 17:30 ` Lucretia
2021-07-16 16:27 ` Simon Wright
@ 2021-07-16 16:28 ` Simon Wright
2021-07-23 17:55 ` Luke A. Guest
1 sibling, 1 reply; 38+ messages in thread
From: Simon Wright @ 2021-07-16 16:28 UTC (permalink / raw)
Lucretia <laguest9000@googlemail.com> writes:
> On Thursday, 15 July 2021 at 17:29:52 UTC+1, Anh Vo wrote:
>
>> > A packed array of Boolean requires all the operations above, plus
>> > shifting the bit to the LSB and treating the result as a Boolean,
>> > so it may not be that surprising that it's slower.
>> Should fixed lower bound index array (-gnatX) speed it up?
>
> On GCC 9.3.0:
>
> -gnatX Language extensions permitted
Ah, but which ones?
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-16 16:28 ` Simon Wright
@ 2021-07-23 17:55 ` Luke A. Guest
0 siblings, 0 replies; 38+ messages in thread
From: Luke A. Guest @ 2021-07-23 17:55 UTC (permalink / raw)
On 16/07/2021 17:28, Simon Wright wrote:
> Lucretia <laguest9000@googlemail.com> writes:
>
>> On Thursday, 15 July 2021 at 17:29:52 UTC+1, Anh Vo wrote:
>>
>>>> A packed array of Boolean requires all the operations above, plus
>>>> shifting the bit to the LSB and treating the result as a Boolean,
>>>> so it may not be that surprising that it's slower.
>>> Should fixed lower bound index array (-gnatX) speed it up?
>>
>> On GCC 9.3.0:
>>
>> -gnatX Language extensions permitted
>
> Ah, but which ones?
>
Oh, I now think it's the 2012 extension which enables you do have (1 ..
<>) or (0 .. <>) in array types, rather than a more useful command line
option to normalise array indices to 0.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 16:29 ` Anh Vo
2021-07-15 17:30 ` Lucretia
@ 2021-07-23 17:04 ` Anh Vo
2021-07-23 17:12 ` Luke A. Guest
1 sibling, 1 reply; 38+ messages in thread
From: Anh Vo @ 2021-07-23 17:04 UTC (permalink / raw)
On Thursday, July 15, 2021 at 9:29:52 AM UTC-7, Anh Vo wrote:
> On Thursday, July 15, 2021 at 8:56:40 AM UTC-7, Jeffrey R. Carter wrote:
> > On 7/15/21 5:13 PM, Lucretia wrote:
> > >
> > > I managed to get just under 4000 passes with a 1 bit array, but not using Ada's packed array. That's actually the slowest method, strangely.
> > So you have an array of a modular type, calculate an index and bit within it,
> > mask out that bit, and compare it to zero? I would have thought an unpacked
> > array of Boolean would be fastest.
> >
> > A packed array of Boolean requires all the operations above, plus shifting the
> > bit to the LSB and treating the result as a Boolean, so it may not be that
> > surprising that it's slower.
> Should fixed lower bound index array (-gnatX) speed it up?
Indeed, it does. As posted on Reddit Ada, I got 5476 Passes after changing array types to arrays having fixed lower bound index of 0 on lines 9 and 10 and compiling it using switch -gnatX -02. By the way, I used GNAT Studio 2021 running on Windows 10.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-23 17:04 ` Anh Vo
@ 2021-07-23 17:12 ` Luke A. Guest
0 siblings, 0 replies; 38+ messages in thread
From: Luke A. Guest @ 2021-07-23 17:12 UTC (permalink / raw)
On 23/07/2021 18:04, Anh Vo wrote:
>> Should fixed lower bound index array (-gnatX) speed it up?
>
> Indeed, it does. As posted on Reddit Ada, I got 5476 Passes after changing array types to arrays having fixed lower bound index of 0 on lines 9 and 10 and compiling it using switch -gnatX -02. By the way, I used GNAT Studio 2021 running on Windows 10.
>
I as I stated that flag enables gnat extensions, usually the next
language revision. I'm on the FSF compiler, the dockerfile is set of gcc 11.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 15:56 ` Jeffrey R. Carter
2021-07-15 16:29 ` Anh Vo
@ 2021-07-15 16:29 ` Lucretia
2021-07-15 16:49 ` Dmitry A. Kazakov
2021-07-15 21:08 ` Jeffrey R. Carter
1 sibling, 2 replies; 38+ messages in thread
From: Lucretia @ 2021-07-15 16:29 UTC (permalink / raw)
On Thursday, 15 July 2021 at 16:56:40 UTC+1, Jeffrey R. Carter wrote:
> On 7/15/21 5:13 PM, Lucretia wrote:
> >
> > I managed to get just under 4000 passes with a 1 bit array, but not using Ada's packed array. That's actually the slowest method, strangely.
> So you have an array of a modular type, calculate an index and bit within it,
> mask out that bit, and compare it to zero? I would have thought an unpacked
> array of Boolean would be fastest.
Doesn't seem to be. Also, the guy is using the packed bit as the final test of all the languages.
> A packed array of Boolean requires all the operations above, plus shifting the
> bit to the LSB and treating the result as a Boolean, so it may not be that
Don't need to shift to the LSB, only need to shift the 1 to the bit location you want to test, invert and then check against 0.
> surprising that it's slower.
I know. I would've thought the compiler would've handled the packed array as a special case and optimised as much as possible there.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 16:29 ` Lucretia
@ 2021-07-15 16:49 ` Dmitry A. Kazakov
2021-07-15 21:08 ` Jeffrey R. Carter
1 sibling, 0 replies; 38+ messages in thread
From: Dmitry A. Kazakov @ 2021-07-15 16:49 UTC (permalink / raw)
On 2021-07-15 18:29, Lucretia wrote:
> On Thursday, 15 July 2021 at 16:56:40 UTC+1, Jeffrey R. Carter wrote:
>> On 7/15/21 5:13 PM, Lucretia wrote:
>>>
>>> I managed to get just under 4000 passes with a 1 bit array, but not using Ada's packed array. That's actually the slowest method, strangely.
>> So you have an array of a modular type, calculate an index and bit within it,
>> mask out that bit, and compare it to zero? I would have thought an unpacked
>> array of Boolean would be fastest.
>
> Doesn't seem to be.
Unlikely unless compiled into machine-specific instructions. You should
inspect the code.
> Also, the guy is using the packed bit as the final test of all the languages.
>
>> A packed array of Boolean requires all the operations above, plus shifting the
>> bit to the LSB and treating the result as a Boolean, so it may not be that
>
> Don't need to shift to the LSB, only need to shift the 1 to the bit location you want to test, invert and then check against 0.
Usually masks are either tabulated in a look-up table or are constants
in a case choice.
>> surprising that it's slower.
>
> I know. I would've thought the compiler would've handled the packed array as a special case and optimised as much as possible there.
It is still unlikely to be faster than all arrays. You should probably
try to use different element types and inspect the code.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Not good for Ada endorsement
2021-07-15 16:29 ` Lucretia
2021-07-15 16:49 ` Dmitry A. Kazakov
@ 2021-07-15 21:08 ` Jeffrey R. Carter
1 sibling, 0 replies; 38+ messages in thread
From: Jeffrey R. Carter @ 2021-07-15 21:08 UTC (permalink / raw)
On 7/15/21 6:29 PM, Lucretia wrote:
> On Thursday, 15 July 2021 at 16:56:40 UTC+1, Jeffrey R. Carter wrote:
>
>> A packed array of Boolean requires all the operations above, plus shifting the
>> bit to the LSB and treating the result as a Boolean, so it may not be that
>
> Don't need to shift to the LSB, only need to shift the 1 to the bit location you want to test, invert and then check against 0.
You know that that is enough, and may be what you're doing manually, but the
compiler may not know that. If A is a packed array of Boolean, then A (I) has
type Boolean. Unless the compiler can optimize it (and maybe it can), it would
normally need to shift the bit down so it can be treated as a value of type
Boolean, and then apply whatever you do with the resulting Boolean value.
--
Jeff Carter
"How'd you like to hide the egg and gurgitate
a few saucers of mocha java?"
Never Give a Sucker an Even Break
101
^ permalink raw reply [flat|nested] 38+ messages in thread