The video is up:

http://www.youtube.com/watch?v=RlVpPstLPEc

-- 
... <IXOYE><

BCS:

> The video is up:
> http://www.youtube.com/watch?v=RlVpPstLPEc

Thank you for the link and thank you to Andrei for the very nice talk. I think the link can be put on Reddit too, if not already present. When Andrei talks he seems a little different from the Andrei that writes in this newsgroup. The talk was quite interactive, and the idea of giving away books for good questions was a good one. The people in the room seem to know how to program.

At 8.56: The video says that D builds structure on the C memory model. Years ago C99 has essentially replaced alloca() with something structurally equal but nicer and more type-safe, the Variable Length Arrays, that I prefer over D alloca().

At 14.00: I did know nothing about the number of times a C++ compiler looks at code chars :-)

At 14.42: You compare the performance of a D compiler with the performance of a C++ compiler. But Delphi compiler was/is very fast (and probably the FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal) code to compile. I think on average it takes only two thousand clock ticks to compile one line of ObjectPascal code. It sounds a lot, but it means that with a modern single-core CPU you can produce your binary file from a one million ObjectPascal lines long program in less than two seconds. ObjectPascal type system looks a bit simpler than D one (despite it has OOP, generics, modules, inline asm, dynamic strings, records, all basic D types, etc), so this isn't a fully apple-to-apple comparison.

27.50, "transactional file copy": this example was script-like, and as short as possible to fit into one single slide, so in this case I think using enforce() is OK. But in true programs I suggest all D programmers to use DesignByContract with assert() more and to use enforce() less. Among other things enforce() kills inlining possibilities and inflates code. In D.learn I have seen people use enforce() in a situation where DbC is designed for. I think the D community needs to learn a bit more DbC, and in my opinion to do this the leaders have to lead the way.

42.00: I don't know what Big-O() encapsulation is. I think later you explain it a bit more, but I have lost the meaning.

53.00, slide 26: regarding sealed containers: I like the idea of an Hierarchical Allocator for C:
http://swapped.cc/halloc/
The idea is simple, when you call a malloc-like function you put the pieces of memory in a hierarchy. And later with a single function call you can free a whole linked list, or a whole data structure that can contain a linked list and and two arrays, or the whole memory allocated by all the data structures used in a whole section of your program. In my opinion this is cool in C. In D with sealed containers you may be able to do something similar.

55.14: Very nice slide :-) In my dlibs1 the Levenshtein distance function is implemented for random accessible inputs only, so it doesn't work correctly with UTF8/UTF16. On an 7-bit ASCII it's probably faster than the Phobos2 one because it is heavily optimized. When the input arrays are small (like two small strings) it uses alloca() to allocate on the stack the array needed by the dynamic programming algorithm, because in my code I often call Levenshtein on small strings and I have seen for this code stack allocation increases performance significantly (another design option that here I have not used is to optionally use heap memory allocated outside the Levenshtein function, as often Tango functions do).

57.36: The Wikipedia Levenshtein entry can be improved a bit, to remove the random access requirement, if not already done :-) Often in practice you have to pay a certain performance price for genericity. So an interesting question is, with the current DMD compiler how much slower than an array-based Levenshtein function is the generic Phobos one when the input is for example a couple of ubyte arrays? If it's only about two or three times slower then it's probably good enough.

1.12.50: Your explanation of the difference between a compiler optimization and an properly defined language feature was nice :-)

1.14.57: I think you have missed to explain the @trusted too that joins the safe and unsafe worlds (in a precedent moment in the talk you have not talked about __gshared, but seems more acceptable).

1.16.04, the question about future success of D: This is not an easy question. Probably the Next Big Language will be JavaScript, that probably will be used in really many situations. Java will probably keep being used a lot in commercial settings, even if only as legacy language. A language that I think has a good chance to become widely used in numerical scientific computations is Chapel, that so far the D community seems to have ignored (I have seen only Bartosz Milewski write about it a bit), despite my repeated attempts to put it in evidence, because I think it contains several very good ideas that are essentially ignored in D. Regarding D2, a problem is of course that D is mostly a system language and the ecological niche for system languages is small and probably will keep being small. Today languages for the Web become way more widespread (and here I have see no enthusiasm in the idea of using D on the Google NaCl platform, to use it on the Web). A language as C#4 is very good in both commercial applications (often database-centric, where LINQ helps a lot) and it can be used to write many desktop/generic applications too, thanks to its IDE, its wide standard library and the possibility to use other languages (like IronPython, F# etc) to create normal dlls that can be used as the C# ones (Mono too helps). Eventually a version of D2 for the CLI platform will partially solve this problem. Young programmers grow up used to program in JavaScript/Python/PHP and see as more and more alien some lower-level knowledge that is almost necessary to program _efficiently_ in D. D also gives you almost all you can find in the pure Java language, but my experience shows me that if you program in D as you program in Java your programs often come out too much slower than the Java ones (often just because of the D GC), so D is not a drop-in replacement for Java: in D you don't have a powerfully optimizing virtual machine under the language that catches and optimizes away a very large number of "efficiency bugs" of your Java code, you have to actually write good D code if you want efficient D programs.

In the time has taken me to see and comment the video the number of people that have seen it has gone from 3 to 322. This is a lot in a short time.

Bye and thank you for the ride,
bearophile

On 08/03/2010 06:04 PM, BCS wrote:
> The video is up:
>
> http://www.youtube.com/watch?v=RlVpPstLPEc
>
On reddit:

http://www.reddit.com/r/programming/comments/cx09f/google_tech_talk_andrei_alexandrescu_three_cool/

Good talk, Andrei!

BCS wrote:
> The video is up:
> http://www.youtube.com/watch?v=RlVpPstLPEc

And Hacker News:

http://news.ycombinator.com/item?id=1572025

bearophile wrote:
> 27.50, "transactional file copy": this example was script-like, and as short
> as possible to fit into one single slide, so in this case I think using
> enforce() is OK. But in true programs I suggest all D programmers to use
> DesignByContract with assert() more and to use enforce() less. Among other
> things enforce() kills inlining possibilities and inflates code. In D.learn I
> have seen people use enforce() in a situation where DbC is designed for. I
> think the D community needs to learn a bit more DbC, and in my opinion to do
> this the leaders have to lead the way.

There's a misunderstanding here. Contract programming is for detecting program bugs. enforce() is for detecting and handling errors such as disk failures and bad user input.

They are COMPLETELY DIFFERENT and must not be conflated.

(For example, assert() goes away when compiled with the -release switch. enforce() does not.)

bearophile wrote:
> At 14.42: You compare the performance of a D compiler with the performance of
> a C++ compiler. But Delphi compiler was/is very fast (and probably the
> FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal)
> code to compile. I think on average it takes only two thousand clock ticks to
> compile one line of ObjectPascal code. It sounds a lot, but it means that
> with a modern single-core CPU you can produce your binary file from a one
> million ObjectPascal lines long program in less than two seconds.
> ObjectPascal type system looks a bit simpler than D one (despite it has OOP,
> generics, modules, inline asm, dynamic strings, records, all basic D types,
> etc), so this isn't a fully apple-to-apple comparison.


Some context is in order. The talk was given at Google and aimed at what would be interesting to Googlers. Google uses C++ extensively, and Rob Pike (of Go) listed as a motivator for Go the compile speed problems with C++. Rob made a point of how fast Go compiled code, and Go's compile speed has been praised a lot on Reddit as well.

Andrei put together a benchmark that shows that D compiles 4 times faster than Go.

As far as I know, Google has no interest in Delphi or ObjectPascal, so how those compilers perform is irrelevant.

On 08/03/2010 04:31 PM, bearophile wrote:
> BCS:
>
>> The video is up: http://www.youtube.com/watch?v=RlVpPstLPEc
>
> Thank you for the link and thank you to Andrei for the very nice
> talk. I think the link can be put on Reddit too, if not already
> present. When Andrei talks he seems a little different from the
> Andrei that writes in this newsgroup. The talk was quite interactive,
> and the idea of giving away books for good questions was a good one.
> The people in the room seem to know how to program.

Thanks. I hope the difference is in the "good" direction. Somehow I find it difficult to grok the right tone on the Usenet.

Regarding this talk, I was so nervous during it that I was (and am after watching the recording) unable to assess the talk's quality. I was mostly on autopilot throughout; for example I seem to vaguely recall at some point there were some people standing in the back, but I have no idea when they appeared.

> 27.50, "transactional file copy": this example was script-like, and
> as short as possible to fit into one single slide, so in this case I
> think using enforce() is OK. But in true programs I suggest all D
> programmers to use DesignByContract with assert() more and to use
> enforce() less. Among other things enforce() kills inlining
> possibilities and inflates code. In D.learn I have seen people use
> enforce() in a situation where DbC is designed for. I think the D
> community needs to learn a bit more DbC, and in my opinion to do this
> the leaders have to lead the way.

I agree with Walter that enforce() is the only right choice there.

> 42.00: I don't know what Big-O() encapsulation is. I think later you
> explain it a bit more, but I have lost the meaning.

Sorry. By that I mean an abstraction that uses information hiding to make complexity an implementation detail, instead of an interface requirement. Consider e.g. at(int) for a sequence container which makes no claim about complexity.

> 57.36: The Wikipedia Levenshtein entry can be improved a bit, to
> remove the random access requirement, if not already done :-) Often
> in practice you have to pay a certain performance price for
> genericity. So an interesting question is, with the current DMD
> compiler how much slower than an array-based Levenshtein function is
> the generic Phobos one when the input is for example a couple of
> ubyte arrays? If it's only about two or three times slower then it's
> probably good enough.

The implementation using only forward access is not slower in theory because it never needs to search to an index. It is a bit slower on ASCII strings because it needs one extra test per character to assess its width. But on UTF strings it saves time by avoiding copying and by working correctly :o).


Thanks,

Andrei

Andrei Alexandrescu:

> > 57.36: The Wikipedia Levenshtein entry can be improved a bit, to remove the random access requirement, if not already done :-) Often in practice you have to pay a certain performance price for genericity. So an interesting question is, with the current DMD compiler how much slower than an array-based Levenshtein function is the generic Phobos one when the input is for example a couple of ubyte arrays? If it's only about two or three times slower then it's probably good enough.
> 
> The implementation using only forward access is not slower in theory because it never needs to search to an index. It is a bit slower on ASCII strings because it needs one extra test per character to assess its width. But on UTF strings it saves time by avoiding copying and by working correctly :o).

I have done three benchmarks, because I am curious. This is compiled with dmd 2.047 with -O -release -inline, the strings used are longhish, about 1200 chars long. To test what you have said I have cast the strings to immutable(ubyte)[] before calling levenshteinDistance, this can be done when you are sure the strings are 7 bit ASCII, and indeed the running times are different, about 1.66 seconds against 2.57 seconds on a slow 32 bit Windows PC:


import std.algorithm: levenshteinDistance;
import std.c.stdio: printf;

void main() {
    string s1 = "Returns the Levenshtein distance between s and t." ~
                "The Levenshtein distance computes the minimal amount of edit operations" ~
                "necessary to transform s into t.";
    string s2 = "Returns the Lovenshtein distonce between p and q." ~
                "The Lovenshtein distonce computes the minimal amount of odit operations" ~
                "necessary to transform p into q.";
    for (int i; i < 3; i++) {
        s1 ~= s1;
        s2 ~= s2;
    }

    int d;
    for (int i; i < 40; i++) {
        static if (1) {
            // 2.57 seconds
            d += levenshteinDistance(s1, s2);
        } else {
            // 1.66 seconds
            alias immutable(ubyte)[] ImmutableubytesArray;
            d += levenshteinDistance(cast(ImmutableubytesArray)s1, cast(ImmutableubytesArray)s2);
        }
    }

    printf("%d\n", d);
}


Then I have tried the same strings with the Levenshtein distance functions of the dlibs1, with dmd v1.042 (I have not yet ported the dlibs1 to D2, and probably there will be no need to port lot of the stuff, because Phobos2 contains more stuff) with -O -release -inline, using the same strings, the running time is about 0.25 seconds:


import std.c.stdio: printf;
import d.func: editDistanceFast;

void main() {
    string s1 = "Returns the Levenshtein distance between s and t." ~
                "The Levenshtein distance computes the minimal amount of edit operations" ~
                "necessary to transform s into t.";
    string s2 = "Returns the Lovenshtein distonce between p and q." ~
                "The Lovenshtein distonce computes the minimal amount of odit operations" ~
                "necessary to transform p into q.";
    for (int i; i < 3; i++) {
        s1 ~= s1;
        s2 ~= s2;
    }

    int d;
    for (int i; i < 40; i++) {
        // 0.25 seconds
        d += editDistanceFast(s1, s2);
    }

    printf("%d\n", d);
}


Unfortunately my editDistanceFast can't be used in Phobos2 for licence issues, because this pure-D1 (no asm used) routine is an improvement of C code written by another person that is not compatible with the Boost licence :-(

Bye,
bearophile

Walter Bright, el  3 de agosto a las 15:08 me escribiste:
> bearophile wrote:
> >At 14.42: You compare the performance of a D compiler with the performance of a C++ compiler. But Delphi compiler was/is very fast (and probably the FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal) code to compile. I think on average it takes only two thousand clock ticks to compile one line of ObjectPascal code. It sounds a lot, but it means that with a modern single-core CPU you can produce your binary file from a one million ObjectPascal lines long program in less than two seconds. ObjectPascal type system looks a bit simpler than D one (despite it has OOP, generics, modules, inline asm, dynamic strings, records, all basic D types, etc), so this isn't a fully apple-to-apple comparison.
> 
> 
> Some context is in order. The talk was given at Google and aimed at what would be interesting to Googlers. Google uses C++ extensively, and Rob Pike (of Go) listed as a motivator for Go the compile speed problems with C++. Rob made a point of how fast Go compiled code, and Go's compile speed has been praised a lot on Reddit as well.
> 
> Andrei put together a benchmark that shows that D compiles 4 times faster than Go.

I was surprised by that, can you publish what the benchmark was, and what compilers were used? I tried Go when it came out and it felt faster than D to compile (which is reasonable because is a much simpler language).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
EXTRAÑA RELACION ENTRE UN JUBILADO Y UN JABALI
	-- Crónica TV

BCS, el  3 de agosto a las 16:04 me escribiste:
> The video is up:
> 
> http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
no longer afraid of the dark or midday shadows
nothing so ridiculously teenage and desperate,
nothing so childish - at a better pace,
slower and more calculated,
no chance of escape,