Array bound checks removal increasing importance

Dmitry Olshansky via Digitalmars-d digitalmars-d at puremagic.com
Mon Jun 2 14:53:51 PDT 2014


02-Jun-2014 13:46, bearophile пишет:
> Dmitry Olshansky:
>
>> An expression attribute? Why turn language into a mess over this tiny
>> problem?
>>
>> It seems to me that you are considering solutions that add arbitrary
>> amounts of complexity to solve relatively small problems.
>>
>> ...
>> That "just" epithet is remarkable self-destruction.
>
> Please be more gentle toward others. Your attitude is poisonous for
> creativity, and while I have a thick hide and I can ignore comments like
> this, similar answers could scare away other people from contributing to
> the discussions. The lack of tact and basic human kindness is a common
> problem in technical forum. I sometimes do the same mistake, but we
> should try to be better. Your good work on the regex module shows you
> are intelligent and qualified, so I'm sure you can also be better toward
> others.

Yes, I was on the edge. My apologies.
The point that I agree may be lost due to the emotional amplitude was 
that ideas became that much more interesting by keeping "entities 
introduced vs problems solved" count as low as possible.

>
> Regarding the technical topic, array bound checks are not a tiny
> problem, and it's not a huge one. D has switches and logic to enable and
> disable them. The Oracle JavaVM ha a good amount of logic to optimize
> away array bound checks. Similar logic is visible in other language
> compilers. Ada language has refined features that allow the compiler to
> safely remove some bound checks without too much inference work. There
> are several papers on this topic, like the one I've shown in the first
> post, that show that several intelligent people have studied this topic
> extensively. Experimental high-performance numeric languages like X10
> and Chapel contain several strategies to avoid array bound checks
> safely. The experience with both famous bugs and the daily experience in
> debugging programs shows that out-of-bound array access is a frequent
> source of some of the worst bugs.

It would be interesting if you could point to a precedent of 
expression-level attribute used for enforcing that compiler does elide 
bounds checking or any other features. The fact that bounds checks can 
be elided as part of optimization is not new.


> There are papers that show a 20-100%
> improvement in performance coming from disabling array bound checks in
> programs that use arrays a lot, like most scientific programs. And D
> language seems fit for some heavy numerical work. D Zen considers quite
> important both performance and safety, so adding logic to the compiler
> to remove some more array bounds is a very good way to do both things at
> once.

No arguing that, the question about implementing the logic mostly boils 
down to who would be carrying the torch (doing the work on the 
compiler). Somewhat joking, giving the prologue of your proposal:

 > ... But now I am giving increasing importance to compiler logic that 
optimizes away bound checks safely.

I hoped you'd want to implement it.

The point about extra attributes to enforce this optimization is that it 
would a very tough sell.

>
> Regarding my idea of the @bounded, perhaps it's stupid and useless, but
> you have to understand that it's just an idea. Most ideas are not even
> wrong, but sometimes the wrong ones lead to better ideas, that sometimes
> are useful. This has happened many times even in the D history (like my
> refused suggestion for the @noheap attribute. Now we have @nogc and I
> like it a lot, it allows me to understand better what my code is doing).

I suspect that most folks arguing for @nogc never heard of @noheap, and 
that's the problem with generating ideas for the sake of throwing them 
out there. Ideas as they stand are cheap, it's refined ideas that are 
priceless. Yes, a weak idea can turn out to be useful, after a lot of 
work was spent on refining it.

> If you criticize too much the people that invent ideas, you will have no
> future.

It goes both ways. Accepting everything is the definition of disaster.

> Bye,
> bearophile


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list