>
> How does a coding convention allow you to create a high-performance regex engine at compile time? How does it allow you to do pretty much any of what CTFE can do?

Well you can always pretend the output of re2c or flex was your hand-written C code. ;-) But sure, "code conventions" is not the proper term for what I mean here.

On Sunday, 8 December 2013 at 11:17:15 UTC, bearophile wrote:
> Araq:
>
>> Interestingly, things that are encouraged in Ada (this is an array of integers of range 0..30, see value range propagation) are much harder to recompute with whole program optimization and D lacks them.
>
> I am currently thinking about related topics. What do you mean? I don't understand.
>
> Bye,
> bearophile

Well that "int[]" is in fact really an "array of int of range 0..30" is a property of a type; pureness or what a function modifies is a property of a function. Properties of types are inherently more difficult to infer than properties of functions.

On Sunday, 8 December 2013 at 13:02:56 UTC, ponce wrote:
> On Sunday, 8 December 2013 at 13:00:26 UTC, Joseph Rushton Wakeling wrote:
>> How is icc doing these days?  I used it years ago (almost 10 years ago!) when it produced significantly faster executables than gcc, but I had the impression that more recent gcc releases either matched its performance or significantly narrowed the gap.
>
> I don't know. People say the gap has reduced a lot and you have to use the #pragmas to get ahead.

My experience is that if you write loads of loops that *are* vectorisable, but not trivially so, and then run on modern intel hardware, intel will beat gcc. Otherwise, probably not. It's become a rather narrow target.

On Sunday, 8 December 2013 at 12:35:45 UTC, ponce wrote:
>> 1. D knows when data is immutable. C has to always make worst case assumptions, and assume indirectly accessed data mutates.
>
> ICC (and other C++ compilers) has plenty of way to disambiguate aliasing:
> - a pragma to let the optimizer assume no loop dependency
> - restrict keyword
> - /Qalias-const: assumes a parameter of type pointer-to-const does not alias with a parameter of type pointer-to-non-const.
> - GCC-like strict aliasing rule

To be fair, all of these are unsafe optimizations. You only use them after carefully identifying the hot spot. D immutability is based on a (probably) sound type system and can be used without danger.

On Sun, Dec 08, 2013 at 10:30:37AM +0100, Timon Gehr wrote:
> On 12/08/2013 06:35 AM, H. S. Teoh wrote:
> >...
> >
> >Or maybe this is just another one of those cultural old age indicators?  Has the term "refactoring" shifted to mean "variable renaming" among the younger coders these days? Genuine question. I'm baffled that these two things could even remotely be considered similar things.
> >
> >
> >T
> >
> 
> "Refactoring" means changing code without changing its functional behaviour.

OK, but still, renaming must be the most trivial of them all?


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.

On 12/08/2013 04:37 PM, H. S. Teoh wrote:
> On Sun, Dec 08, 2013 at 10:30:37AM +0100, Timon Gehr wrote:
>> On 12/08/2013 06:35 AM, H. S. Teoh wrote:
>>> ...
>>>
>>> Or maybe this is just another one of those cultural old age
>>> indicators?  Has the term "refactoring" shifted to mean "variable
>>> renaming" among the younger coders these days? Genuine question. I'm
>>> baffled that these two things could even remotely be considered
>>> similar things.
>>>
>>>
>>> T
>>>
>>
>> "Refactoring" means changing code without changing its functional
>> behaviour.
>
> OK, but still, renaming must be the most trivial of them all?
>
>
> T
>

I don't think so. Eg. stripping comments and formatting is more trivial. :o)

Also, it is not too easy, an entire D front end and some additional static analysis is probably required to automatically rename symbols in a reliable way.

On 12/08/2013 03:13 PM, Araq wrote:
> On Sunday, 8 December 2013 at 11:17:15 UTC, bearophile wrote:
>> Araq:
>>
>>> Interestingly, things that are encouraged in Ada (this is an array of
>>> integers of range 0..30, see value range propagation) are much harder
>>> to recompute with whole program optimization and D lacks them.
>>
>> I am currently thinking about related topics. What do you mean? I
>> don't understand.
>>
>> Bye,
>> bearophile
>
> Well that "int[]" is in fact really an "array of int of range 0..30" is
> a property of a type; pureness or what a function modifies is a property
> of a function. Properties of types are inherently more difficult to
> infer than properties of functions.

I don't understand this point. Functions have types as well. Are you referring to mutability?

On 12/8/2013 6:26 AM, qznc wrote:
> On Sunday, 8 December 2013 at 12:35:45 UTC, ponce wrote:
>>> 1. D knows when data is immutable. C has to always make worst case
>>> assumptions, and assume indirectly accessed data mutates.
>>
>> ICC (and other C++ compilers) has plenty of way to disambiguate aliasing:
>> - a pragma to let the optimizer assume no loop dependency
>> - restrict keyword
>> - /Qalias-const: assumes a parameter of type pointer-to-const does not alias
>> with a parameter of type pointer-to-non-const.
>> - GCC-like strict aliasing rule
>
> To be fair, all of these are unsafe optimizations. You only use them after
> carefully identifying the hot spot. D immutability is based on a (probably)
> sound type system and can be used without danger.

To be fairer (!), all of these (except restrict) are non-Standard extensions for C. "restrict" is an extension for C++.

On 12/8/2013 4:35 AM, ponce wrote:
>> 3. Function inlining has generally been shown to be of tremendous value in
>> optimization. D has access to all the source code in the program, or at least
>> as much as you're willing to show it, and can inline across modules. C cannot
>> inline functions unless they appear in the same module or in .h files. It's a
>> rare practice to push many functions into .h files. Of course, there are now
>> linkers that can do whole program optimization for C, but those are kind of
>> herculean efforts to work around that C limitation of being able to see only
>> one module at a time.
>
> This point is not entirely accurate. While the C model is generally harmful with
> inlining, with the Intel C++ compiler you can absolutely rely on cross-module
> inlining when doing global optimization. I don't know how it works, but all out
> tiny functions hidden in separate translation units get inlined.

I believe this is the linker thing I mentioned at work.

On 12/8/2013 2:13 AM, Araq wrote:
> From this list only (7) is a valid point. All the others can be trivially dealt
> with whole program optimization (1,2,3)

If it's trivial, it's not happening. (1) would require solving the halting problem. (2) is impractical because there's no way for the programmer to detect if his call stack is pure or not, so he can't reasonably fix it to make it pure. (3) does require whole program analysis, which is done (as I said) by the linker, and is not normally done. Will gcc/ld do it? Nope. (It's not so trivial.)

> or coding conventions (4,5,6) (always
> pass a (char*, len) pair around for efficient slicing).

(4) just try retrofitting an existing C program to do this. I have. You'll give it up soon :-)

(5) it just doesn't happen in C code - it's too hard

(6) I pretty much never see this happening in real C code - it's not so trivial


> Interestingly, things
> that are encouraged in Ada (this is an array of integers of range 0..30, see
> value range propagation) are much harder to recompute with whole program
> optimization and D lacks them.

You can do these in D with a library type.