On Tue, Dec 10, 2013 at 11:47:47PM +0100, Sean Kelly wrote:
> On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote:
> >
> >"there is no way proper C code can be slower than those languages."
> 
> Didn't Bjarne cover this in his C++ performance talk at SD West in 2007?  Templates alone can make C++ and D code faster than even hand-optimized C.  And that doesn't even consider some of the other points you mentioned.

The thing is, what constitutes "proper C" is not well-defined, because since C translates to machine code (as does C++ and D), in theory *everything* has access to the same level of performance -- that is, the hardware. So arguably, no matter what code fragment you may present in C++ or D, there's always a corresponding C code fragment that performs equally fast or faster. But that obscures the fact that said C code fragment may be written in an unmanageably convoluted style that no one in their right mind would actually use in practice. (And the same can be said for C++ and D: use asm blocks, and you'll beat any "normal" C code, but that proves nothing since the whole issue is writing *idiomatic* C vs. *idiomatic* D, not writing things in an unnatural way just so you can lay claim to the title of best performance.)


T

-- 
No! I'm not in denial!

On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote:
> On Tue, Dec 10, 2013 at 11:47:47PM +0100, Sean Kelly wrote:
>> On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote:
>> >
>> >"there is no way proper C code can be slower than those
>> >languages."
>> 
>> Didn't Bjarne cover this in his C++ performance talk at SD West in
>> 2007?  Templates alone can make C++ and D code faster than even
>> hand-optimized C.  And that doesn't even consider some of the other
>> points you mentioned.
>
> The thing is, what constitutes "proper C" is not well-defined, because
> since C translates to machine code (as does C++ and D), in theory
> *everything* has access to the same level of performance -- that is, the
> hardware. So arguably, no matter what code fragment you may present in C++ or D, there's always a corresponding C code fragment that performs equally fast or faster. But that obscures the fact that said C code fragment may be written in an unmanageably convoluted style that no one in their right mind would actually use in practice. (And the same can be said for C++ and D: use asm blocks, and you'll beat any "normal" C code, but that proves nothing since the whole issue is writing *idiomatic* C vs. *idiomatic* D, not writing things in an unnatural way just so you can lay claim to the title of best performance.)

Bjarne's point was essentially that templates allow code to be inlined to a ridiculous degree.  C code simply can't compete with that and still be maintainable.  I suppose you could expand that to mean any inlineable code rather than just templates, but the same assertion holds.

I don't think it makes sense to consider the scenario where the "C code" is purpose built assembly code because that says nothing about the language itself.  Nor does it make sense to restrict the compared language to "C style code" (whatever that means) because any speed advantages would be leveraging language features or conventions not present in idiomatic C.

For example, I've posted benchmarks of a JSON parser here before that I wrote in C and it's considerably faster than anything I've seen done in D.  Does that mean that C is faster than D?  Absolutely not.  I could recompile the same code in D and have it be just as fast as the C version.  The more interesting issue is how easy that problem was to solve in each language, and which is more maintainable.

On Wed, Dec 11, 2013 at 01:33:24AM +0100, Sean Kelly wrote:
> On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote:
> >On Tue, Dec 10, 2013 at 11:47:47PM +0100, Sean Kelly wrote:
> >>On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote:
> >>>
> >>>"there is no way proper C code can be slower than those languages."
> >>
> >>Didn't Bjarne cover this in his C++ performance talk at SD West in 2007?  Templates alone can make C++ and D code faster than even hand-optimized C.  And that doesn't even consider some of the other points you mentioned.
> >
> >The thing is, what constitutes "proper C" is not well-defined, because since C translates to machine code (as does C++ and D), in theory *everything* has access to the same level of performance -- that is, the hardware. So arguably, no matter what code fragment you may present in C++ or D, there's always a corresponding C code fragment that performs equally fast or faster. But that obscures the fact that said C code fragment may be written in an unmanageably convoluted style that no one in their right mind would actually use in practice. (And the same can be said for C++ and D: use asm blocks, and you'll beat any "normal" C code, but that proves nothing since the whole issue is writing *idiomatic* C vs. *idiomatic* D, not writing things in an unnatural way just so you can lay claim to the title of best performance.)
> 
> Bjarne's point was essentially that templates allow code to be inlined to a ridiculous degree.  C code simply can't compete with that and still be maintainable.  I suppose you could expand that to mean any inlineable code rather than just templates, but the same assertion holds.
> 
> I don't think it makes sense to consider the scenario where the "C code" is purpose built assembly code because that says nothing about the language itself.  Nor does it make sense to restrict the compared language to "C style code" (whatever that means) because any speed advantages would be leveraging language features or conventions not present in idiomatic C.
> 
> For example, I've posted benchmarks of a JSON parser here before that I wrote in C and it's considerably faster than anything I've seen done in D.  Does that mean that C is faster than D?  Absolutely not.  I could recompile the same code in D and have it be just as fast as the C version.  The more interesting issue is how easy that problem was to solve in each language, and which is more maintainable.

Right, that was what I was getting at.

And I think on that count, D trumps C because idiomatic D is both of comparable performance *and* more maintainable, whereas highly-optimized C is unreadable.  Not to mention D is easier to write (and write *correctly* -- and again I'm reminded of Milewski's article about how the naïve way to write C++, which I think also applies to C, is more often than not the wrong way, and the right way is very convoluted and unnatural).


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

On 12/10/2013 4:10 PM, H. S. Teoh wrote:
> On Tue, Dec 10, 2013 at 03:48:51PM -0800, Walter Bright wrote:
>> On 12/10/2013 1:37 PM, H. S. Teoh wrote:
>>> That's not too bad. One of my template-heavy projects take almost 10
>>> seconds to compile just a single source file. And a single string
>>> import can add up to 3-4 seconds (well, probably due to CTFE since I
>>> call split() on the string).
>>
>> That isn't C-style code.
>>
>> The issue is convenience of writing C code in D vs C.
>
> So you're trying to say that it's easier to write C code in D, rather
> than in C?
>
> I thought this thread was about the inherent advantages of D over C.

I was referring specifically to Dicebot's post as ancestor:

-- I think it is better to rephrase it as "writing C code in D is possible but even less convenient than in C". --

> And I agree that D has a lot of advantages, but it would be a lie to say
> that there are no disadvantages.

I don't believe anyone made that claim.

On Wednesday, 11 December 2013 at 03:33:47 UTC, Walter Bright wrote:
[snip]

>>> The issue is convenience of writing C code in D vs C.
>>
>> So you're trying to say that it's easier to write C code in D, rather
>> than in C?
>>
>> I thought this thread was about the inherent advantages of D over C.
>
> I was referring specifically to Dicebot's post as ancestor:
>
[snip]

I am finding C is much easier and more pleasant to write with DMD.

At work we're forced, under duress, to write C. I just got a new project with a loose deadline so I thought I'd do a crazy experiment to make it interesting...
(NOTE: I say "under duress" but I secretly like C/C++, especially C++11/14.)

I'm writing my C code with DMD. When tested and tweaked I do a final compile with C compiler (test once more) then commit for our QA to pick up.  Occasionally I'll compile with the C compiler to ensure I haven't leaked any D into the code and to minimise the #include fixups at the end.

Currently this is about 20 C-(D) files with approx. 12,000-15,000 LOC. I doubt this workflow would scale much further, although it doesn't look like becoming an issue yet.

My experiment is a success IMO. My C code is much cleaner, safer and more maintainable because of it. Yes, I know I could write C like this without DMD ... but I'm lazy and fall back into bad C habits :-)

I now advocate that students should be taught C programming with the DMD compiler :D


Cheers,
Ed

On 12/11/2013 6:11 PM, ed wrote:
> I am finding C is much easier and more pleasant to write with DMD.

I find the same thing!

> At work we're forced, under duress, to write C.

My condolences!

> I'm writing my C code with DMD. When tested and tweaked I do a final compile
> with C compiler (test once more) then commit for our QA to pick up.
> Occasionally I'll compile with the C compiler to ensure I haven't leaked any D
> into the code and to minimise the #include fixups at the end.

Wow. This is a pretty interesting use case.

> Currently this is about 20 C-(D) files with approx. 12,000-15,000 LOC. I doubt
> this workflow would scale much further, although it doesn't look like becoming
> an issue yet.
>
> My experiment is a success IMO. My C code is much cleaner, safer and more
> maintainable because of it. Yes, I know I could write C like this without DMD
> ... but I'm lazy and fall back into bad C habits :-)
>
> I now advocate that students should be taught C programming with the DMD
> compiler :D

This really is cool.

BTW, this sounds a lot like when I used to develop real mode MSDOS programs. An errant pointer in MSDOS would frequently crash the system and even scramble the hard disk. It was pretty bad. Therefore, I'd do all my development on a protected mode operating system (Windows NT or OS/2 16 bit), and only when it was bug free would I even attempt to bring it up under MSDOS. This approach saved me endless hours of misery.

On Thursday, 12 December 2013 at 03:34:16 UTC, Walter Bright
wrote:
> On 12/11/2013 6:11 PM, ed wrote:
>> ....
>
> BTW, this sounds a lot like when I used to develop real mode MSDOS programs. An errant pointer in MSDOS would frequently crash the system and even scramble the hard disk. It was pretty bad. Therefore, I'd do all my development on a protected mode operating system (Windows NT or OS/2 16 bit), and only when it was bug free would I even attempt to bring it up under MSDOS. This approach saved me endless hours of misery.

I used Turbo Pascal instead. :)

On Thursday, 12 December 2013 at 02:12:00 UTC, ed wrote:
> On Wednesday, 11 December 2013 at 03:33:47 UTC, Walter Bright wrote:
> [snip]
>
>>>> The issue is convenience of writing C code in D vs C.
>>>
>>> So you're trying to say that it's easier to write C code in D, rather
>>> than in C?
>>>
>>> I thought this thread was about the inherent advantages of D over C.
>>
>> I was referring specifically to Dicebot's post as ancestor:
>>
> [snip]
>
> I am finding C is much easier and more pleasant to write with DMD.
>
> At work we're forced, under duress, to write C. I just got a new project with a loose deadline so I thought I'd do a crazy experiment to make it interesting...
> (NOTE: I say "under duress" but I secretly like C/C++, especially C++11/14.)
>
> I'm writing my C code with DMD. When tested and tweaked I do a final compile with C compiler (test once more) then commit for our QA to pick up.  Occasionally I'll compile with the C compiler to ensure I haven't leaked any D into the code and to minimise the #include fixups at the end.
>
> Currently this is about 20 C-(D) files with approx. 12,000-15,000 LOC. I doubt this workflow would scale much further, although it doesn't look like becoming an issue yet.
>
> My experiment is a success IMO. My C code is much cleaner, safer and more maintainable because of it. Yes, I know I could write C like this without DMD ... but I'm lazy and fall back into bad C habits :-)
>
> I now advocate that students should be taught C programming with the DMD compiler :D
>
>
> Cheers,
> Ed

Currently I always advocate that C and C++ development should
always be done with warnings as errors enabled, coupled with
static analyzers at very least during CI builds, breaking them if
anything is found.

Nice story though, thanks for sharing.

--
Paulo

"ed" <sillymongrel@gmail.com> wrote in message news:ibnfbsvxqzjxyfpnzseh@forum.dlang.org...
>
> I'm writing my C code with DMD. When tested and tweaked I do a final compile with C compiler (test once more) then commit for our QA to pick up.  Occasionally I'll compile with the C compiler to ensure I haven't leaked any D into the code and to minimise the #include fixups at the end.
>

I used to do this for all my university assignments in C/C++/java.

On 12/12/13 10:01, Paulo Pinto wrote:
> Currently I always advocate that C and C++ development should
> always be done with warnings as errors enabled, coupled with
> static analyzers at very least during CI builds, breaking them if
> anything is found.

I do think I owe quite a bit to the university professor who took the scientific programming course, for instructing us to compile with

    gcc -ansi -pedantic -Wall

Not as comprehensive as -Werror etc., but still a good way to be started off in programming life.  It's meant that I've always subsequently appreciated the existence and value of language standards.

And it's generated much amusement among academic colleagues: "Finally, there is such a virtuous saint among us!" or words to that effect :-P