On 2 Jun 2014 17:49, "Iain Buclaw" <ibuclaw@gdcproject.org> wrote:
>
> On 2 June 2014 17:33, bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > Walter Bright:
> >
> >
> >> Report the source code you fed to it that caused the crash.
> >
> >
> > Even hello world crashes.
> >
> > Bye,
> > bearophile
>
>
> Then that is a start.  Post a bug and report clearly what your
environment is.

Also where you got gdc from if you downloaded binaries instead of built from development.

On Saturday, 31 May 2014 at 10:56:06 UTC, bearophile wrote:
> Even adding logic to remove 20% of the bound checks in numeric code is going to help D because I think more and more people will not disable bound checks in D.

What speedup those 20% will give? 3%? Shouldn't optimization go a different route?

1. Get annoying performance problem.
2. Diagnose it.
3. Optimize the hot spot.

Do you have 1?

On Monday, 2 June 2014 at 09:46:03 UTC, bearophile wrote:
> 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.

Scientific programs usually process trusted data (or easily validated), so they may need correctness checks, but don't need security checks. If you see the algorithm works with bound checks, you can turn them off.

Kagamin:

> Scientific programs usually process trusted data (or easily validated), so they may need correctness checks, but don't need security checks.

I agree.


> If you see the algorithm works with bound checks, you can turn them off.

Algorithms go in different code paths, so different runs hit the arrays differently. In scientific code you have to trust the correctness of the results. So you prefer to leave array bound checks active (as in Java, Julia, Python). If your compiler is able to remove some bound checks and mechanically verify the code as safe, that's even better (as in Java, and probably in future Julia). If you give me a compiler able to remove most array bound checks safely, you will see me never disable them blindly again :-)

Bye,
bearophile

On 5/31/2014 3:56 AM, bearophile wrote:
> Even adding logic to remove 20% of the bound checks in numeric code is going to help D

https://github.com/D-Programming-Language/dmd/pull/3620

Walter Bright:

> https://github.com/D-Programming-Language/dmd/pull/3620

Yes, it's a start point :-)

Bye,
bearophile

Sorry for my slow answering, I'm trying to catch up.

Kagamin:

> Shouldn't optimization go a different route?
> 
> 1. Get annoying performance problem.
> 2. Diagnose it.
> 3. Optimize the hot spot.
> 
> Do you have 1?

That's a good strategy if you are optimizing user code. But even when you write library code you sometimes can't use that strategy, because you are not always sure the performance needs of the people that will use the library. That's why Phobos should be written to be efficient regardless of evidence of performance problems.

The same is true for compiler writers. If you compile D code that uses arrays a lot with and without "-noboundscheck" you see some run time difference. It's nice to think that the D compiler will remove part of such difference in all your future D programs that you have not yet written. Array bound checks removal was found to be a sufficiently important problem to solve even in Java, that is used for heavy array processing less than other languages like Fortran.

Bye,
bearophile

deadalnix:

>I think we should focus on solving problems that modern backend aren't capable to optimize.<

I agree. But those D snippets I have written are not able to show what the backends are or aren't able to do. Generally if you compile D code even with LDC2 you see a significant performance difference in heavy-array processing code if you compile it with or without -noboundscheck. I have seen this plenty of times. If you want we can take a look at some benchnmarks.

Bye,
bearophile

Dmitry Olshansky:

> It would be interesting if you could point to a precedent of expression-level attribute used for enforcing that compiler does elide bounds checking

Perhaps that's a little invention of mine :-)

In the last years I've seen that while optimizations are important, there are situations where you need to know if an optimization is done. Array bound checks removal is not able to change the code semantics like tail call optimization (TCO), but like forced inlining you sometimes want to be sure a small amount of lines of a numeric processing kernel doesn't waste run time verifying bounds.

(And if you are sure certain bound checks are not present, you have also verified that a part of the code doesn't raise array bound run-time errors. So it's also a code verification technique, that I think will become more common in the next years).

If you write a contract between the compiler and the programmer, and it fails (so the compiler is not able to remove all bound checks in a piece of D code inside the @bounded { ... }), then the programmer can add strongly typed indexes to help the compiler figure out at compile time the correctness of array accesses (strongly typed array indexes that I have discussed in a recent thread are indeed also useful for the compiler optimizations, they are not just to help avoid programmers bugs), or the programmer can add some asserts or change the code in other small ways to reach the same goal. Once such goal is reached, and your kernel computation is efficient, you don't care if in some cases in the rest of the code the D compiler is not able to remove all array bound checks. So only a small/certain percentage of the code is meant to go inside the braces of @bounded{...}. The alternative solution is to put the kernel into another module, and compile it separately with "-boundscheck=off". But this is less handy and it's less safe.

Generally I like ways to express a richer semantics in the code.

Bye,
bearophile

On Thursday, 5 June 2014 at 09:36:53 UTC, bearophile wrote:
> deadalnix:
>
>>I think we should focus on solving problems that modern backend aren't capable to optimize.<
>
> I agree. But those D snippets I have written are not able to show what the backends are or aren't able to do. Generally if you compile D code even with LDC2 you see a significant performance difference in heavy-array processing code if you compile it with or without -noboundscheck. I have seen this plenty of times. If you want we can take a look at some benchnmarks.
>

I know and this is worthwhile to add some effort to optimize
that. I was simply reminding that we should try to understand in
which case the code is not optimized and why, before jumping to
solutions.