On Tue, Aug 13, 2013 at 11:52:23AM +0200, Chris wrote:
> On Tuesday, 13 August 2013 at 01:00:12 UTC, deadalnix wrote:
[...]
> >Rewind history back to early 2000 and you'll understand. At the time, PHP was the best solution (which says more about how bad the situation was than how great PHP was :D).
> 
> True, true. There weren't many options back in the day. But that's no excuse for bad or absurd language design. $asolutely $no $need $to $have $a $syntax $like $this =>
> 
> At least it does its job ok.

I honestly don't understand what's so bad about using $ for variables. That has nothing to do with PHP's *real* design flaws, which are many and varied. To fixate on $ only hides the real problems, described here:

	http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Note that using $ for variables isn't listed there.


T

-- 
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr

On 08/11/2013 04:22 AM, Walter Bright wrote:
> http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf

This article claims the "Performance [of D] is equivalent to C".

Is that true? I mean even if D reaches 90% of C's performance, I still consider it great because of its productive features, but are there any benchmarks done?

On Sun, 2013-08-18 at 01:59 -0400, John Joyus wrote:
> On 08/11/2013 04:22 AM, Walter Bright wrote:
> > http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf
> 
> This article claims the "Performance [of D] is equivalent to C".
> 
> Is that true? I mean even if D reaches 90% of C's performance, I still consider it great because of its productive features, but are there any benchmarks done?

Not a statistically significant benchmark but an interesting data point:

C:

==================== Sequential
	pi = 3.141592653589970752
	iteration count = 1000000000
	elapse time = 8.623442

C++:

==================== Sequential
	pi = 3.14159265358997075
	iteration count = 1000000000
	elapse = 8.61212399999999967

D:

======================== pi_sequential.d
	π = 3.141592653589970752
	iteration count = 1000000000
	elapse time = 8.612256


C and C++ were compiled with GCC 4.8.1 full optimization, D was compiled with LDC full optimization. Oh go on, let's do it with GDC as well:

======================== pi_sequential.d
	π = 3.141592653589970752
	iteration count = 1000000000
	elapse time = 8.616558


And you are going to ask about DMD aren't you :-)

======================== pi_sequential.d
	π = 3.141592653589970752
	iteration count = 1000000000
	elapse time = 9.495549

Remember this is 1 and only 1 data point and not even a sample just a single data point. Thus only hypothesis building is allowed, no deductions.  But I begin to believe that D is as fast as C and C++ using GDC and LDC. DMD is not in the execution performance game.

Further fudging, the code is just one for loop.  The parallel results are just as encouraging for D.  I will say though that std.concurrency and std.parallelism could do with some more work. On the other hand C has nothing like it, whilst C++ has a few options including TBB.

As I say, indicators, not statistically significant results without big data samples and serious ANOVA.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 08/18/2013 01:59 AM, John Joyus wrote:
> On 08/11/2013 04:22 AM, Walter Bright wrote:
>> http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf
>
> This article claims the "Performance [of D] is equivalent to C".
>
> Is that true? I mean even if D reaches 90% of C's performance, I still
> consider it great because of its productive features, but are there any
> benchmarks done?

That claim is highly dubious. D's garbage collector is a known performance bottleneck. I read the paper and didn't see any benchmarks. It was mostly about how they interfaced with a C library. Yes, in limited circumstances if you write D like you would write C, you can get comparative performance.

However, the point of D is to allow high-level coding and to make use of garbage collector by default, so that's where the interesting comparisons are to be made.

On Sun, 18 Aug 2013 06:35:30 -0400
Jeff Nowakowski <jeff@dilacero.org> wrote:

> On 08/18/2013 01:59 AM, John Joyus wrote:
> > On 08/11/2013 04:22 AM, Walter Bright wrote:
> >> http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf
> >
> > This article claims the "Performance [of D] is equivalent to C".
> >
> > Is that true? I mean even if D reaches 90% of C's performance, I still consider it great because of its productive features, but are there any benchmarks done?
> 
> That claim is highly dubious. D's garbage collector is a known performance bottleneck.

Well, but aside from that one thing, people need to keep in mind that D is not dynamic/interpreted/VMed, and does have full low-level capabilities. Those are the things that make C fast, and D shares them. Plus modern C codegen also makes things fast, but D generally uses C backends, so again D shares that, too.

On Sunday, 11 August 2013 at 18:25:02 UTC, Andrei Alexandrescu wrote:
> For a column of text to be readable it should have not much more than 10 words per line. Going beyond that forces eyes to scan too jerkily and causes difficulty in following line breaks.

This.
Also some people can read a line a second because they read downward instead of left to right. Although I heard this through hearsay

On 18 August 2013 18:24, ProgrammingGhost <dsioafiseghvfawklncfskzdcf@sdifjsdiovgfdisjcisj.com> wrote:
> On Sunday, 11 August 2013 at 18:25:02 UTC, Andrei Alexandrescu wrote:
>>
>> For a column of text to be readable it should have not much more than 10 words per line. Going beyond that forces eyes to scan too jerkily and causes difficulty in following line breaks.
>
>
> This.
> Also some people can read a line a second because they read downward instead
> of left to right. Although I heard this through hearsay

Probably more like two lines at once, if they are reading a book. Reading code? I reckon you can read downwards on that. :)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

> Yes, in limited circumstances if you write D like you would write C, you can get comparative performance.

I'd say in all cases when you mimic C behavior in D one should expect same or better performance with ldc/gdc unless you hit a bug.

On Sunday, 18 August 2013 at 18:08:58 UTC, Dicebot wrote:
>> Yes, in limited circumstances if you write D like you would write C, you can get comparative performance.
>
> I'd say in all cases when you mimic C behavior in D one should expect same or better performance with ldc/gdc unless you hit a bug.

array literal allocations. I guess that's debatably a performance bug.

On 08/18/2013 08:26 PM, John Colvin wrote:
> On Sunday, 18 August 2013 at 18:08:58 UTC, Dicebot wrote:
>>> Yes, in limited circumstances if you write D like you would write C,
>>> you can get comparative performance.
>>
>> I'd say in all cases when you mimic C behavior in D one should expect
>> same or better performance with ldc/gdc unless you hit a bug.
>
> array literal allocations. I guess that's debatably a performance bug.

I guess that's debatably mimicking C behaviour.