On 2013-12-09 09:15, Iain Buclaw wrote:

> Of course, it will not work unless you also pass the following options:
> -version=Enterprise -noboundscheck -inline -property -transition=11629
>
> I thought everyone knew that??!?? :o)

Still no difference ;)

-- 
/Jacob Carlborg

On 12/9/2013 12:05 AM, Jacob Carlborg wrote:
> With DMD 2.064.2 produce the exact same assembly code for "foo" and "main" with
> our without "pure". I compiled with "dmd -O -release foo.d", am I doing
> something wrong?

Try this:

  pure int foo (int a, int b) nothrow {
    return a + b;
  }

  int test() {
    return foo(1, 2) + foo(1, 2);
  }

Compile with:

  dmd foo -O -release -c

And dump the assembly:

            push    EAX
            mov     EAX,2
            push    1
            call    near ptr _D3foo3fooFNaNbiiZi
            add     EAX,EAX
            pop     ECX
            ret

Granted, more cases can be done, but it *does* take advantage of purity here and there.


>> This is about inherent language opportunities, not whether current
>> implementations fall short or not.
>
> I think most people will care about what's working right now. Not what could
> possibly work sometime in the future.

One cannot do better optimization if the language does not allow it.

On 12/9/2013 12:11 AM, Jacob Carlborg wrote:
> On 2013-12-08 19:44, Walter Bright wrote:
>
>> To be fairer (!), all of these (except restrict) are non-Standard
>> extensions for C. "restrict" is an extension for C++.
>
> It doesn't matter they're not standard, as long as people are using them.


If a language needs extensions in order to be performant, then the language has problems claiming the crown of best performer.

Furthermore, you cannot argue that C is more performant when you really mean "Brand X C".

That's why I based my remarks on Standard C, not some vendor's extensions.

On Sunday, 8 December 2013 at 01:34:34 UTC, Walter Bright wrote:
> On 12/7/2013 4:46 PM, Manu wrote:
>> True as compared to C, but I wouldn't say this is true in general.
>> C# and Java make it easy to refactor code rapidly. D doesn't have any such tools
>> yet.
>> It's my #1 wishlist item for VisualD and Mono-D, and I await such tooling with
>> great anticipation.
>> Maybe when the D front-end is a library, and tooling has such powerful (and
>> reliable) semantic analysis as the compiler does it may be possible?
>
> Needing a tool to refactor code is a bit of a mystery to me. I've never used one, and never felt that not having one inhibited me from refactoring.

I used to think that until I tried rope in Emacs for editing Python code. After that I wanted proper refactorign for everything else as well. Renaming doesn't require checks, extracting a method is just easy... it's saved me a _lot_ of time and I just couldn't imagine having done some of the work I did without it.

On Monday, 9 December 2013 at 08:11:04 UTC, Jacob Carlborg wrote:
> On 2013-12-08 19:44, Walter Bright wrote:
>
>> To be fairer (!), all of these (except restrict) are non-Standard
>> extensions for C. "restrict" is an extension for C++.
>
> It doesn't matter they're not standard, as long as people are using them.

Not when writing portable code.

Nowadays I just do JVM/.NET stuff, but I still remember the
headaches of writing portable C and C++ code across commercial
UNIX systems during 1999 - 2001.

--
Paulo

On Monday, 9 December 2013 at 09:58:01 UTC, Paulo Pinto wrote:
> Not when writing portable code.
>
> Nowadays I just do JVM/.NET stuff, but I still remember the
> headaches of writing portable C and C++ code across commercial
> UNIX systems during 1999 - 2001.
>

Don't know about C much but writing portable C++ is not a pleasant task, especially now, when you really want to use C++11 features. Saying that nobody cares about portable code is of course completely ignorant. I would even say that today it is more relevant that single-platfrm code.

On Monday, 9 December 2013 at 10:03:31 UTC, Szymon Gatner wrote:
> On Monday, 9 December 2013 at 09:58:01 UTC, Paulo Pinto wrote:
>> Not when writing portable code.
>>
>> Nowadays I just do JVM/.NET stuff, but I still remember the
>> headaches of writing portable C and C++ code across commercial
>> UNIX systems during 1999 - 2001.
>>
>
> Don't know about C much but writing portable C++ is not a pleasant task, especially now, when you really want to use C++11 features. Saying that nobody cares about portable code is of course completely ignorant. I would even say that today it is more relevant that single-platfrm code.

Many people in the open source world equate writing portable C
code with using gcc and clang across Linux/BSD distributions,
while complaining about Windows.

However when using commercial C compilers across many systems.
The C language standard is full of undefined behaviors that will
bite you, once you start using multiple vendors.

Then there was the POSIX standard, with its own set of undefined
behaviors and vendor specific extensions.

Additionally when I was in this project, some of the C compilers
were still midway between K&R and ANSI C compliance.

Thankfully most of the application was written in TCL with OS
specific C bindings.

As for C++, it has been always like that. One of the reasons I
liked Java so much in the beginning was it is a C++ like
language, with Pascal like safety, that I could use everywhere
without having #ifdef everywhere on my code, always wondering
what language constructs would be supported.

Writing portable C++ code before the C++98 standard was finalized
was a guessing game of what each compiler supported what, and how
far it was from the ongoing draft.

So if you wanted to play safe, the C++ code was basically a
better C with in-house developed classes.

--
Paulo

On Sunday, 8 December 2013 at 18:53:07 UTC, Walter Bright wrote:
> 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.

Well ok when I say "easy" or "trivial" it doesn't mean anything ;-).

(1) doesn't require solving the halting problem at all though. For optimizations all you need to do is to come up with an analysis that approximates the runtime behaviour in a conservative approach. ("When in doubt, assume it modifies this location.")

> (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.

Well look at the subject: "inherent" vs "practical".

> (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.)
>

Both GCC and LLVM can perform link time optimizations.

>> 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 :-)
>

Again -- the subject is "inherent code performance advantages". The average C program full of "if (errcode) goto errorHandler" is irrelevant to this discussion. BTW I would indeed add "D has exceptions" to your list.

> (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.

And get the same (theoretical) advantages for optimizations? Perhaps.

On 2013-12-09 09:50, Walter Bright wrote:

> If a language needs extensions in order to be performant, then the
> language has problems claiming the crown of best performer.
>
> Furthermore, you cannot argue that C is more performant when you really
> mean "Brand X C".
>
> That's why I based my remarks on Standard C, not some vendor's extensions.

Sure, but then this comparison might not be so interesting. I'm trying to say that it might be more interesting in what D can do now and what developers are actually using, including vendor extension.

-- 
/Jacob Carlborg

On 2013-12-09 09:45, Walter Bright wrote:

> Try this:
>
>    pure int foo (int a, int b) nothrow {
>      return a + b;
>    }
>
>    int test() {
>      return foo(1, 2) + foo(1, 2);
>    }
>
> Compile with:
>
>    dmd foo -O -release -c
>
> And dump the assembly:
>
>              push    EAX
>              mov     EAX,2
>              push    1
>              call    near ptr _D3foo3fooFNaNbiiZi
>              add     EAX,EAX
>              pop     ECX
>              ret
>
> Granted, more cases can be done, but it *does* take advantage of purity
> here and there.

Yeah, that worked. I tried to do as simple case I could think of.

-- 
/Jacob Carlborg