On 2015-03-20 at 16:25, weaselcat wrote:
> On Friday, 20 March 2015 at 15:12:44 UTC, David Gileadi wrote:
>> Someone who knows about copyright/licensing would probably need to check that it's okay if we plan to use them verbatim. If we can't then it might be worth linking to the above page from somewhere on dlang.org.
>
> All of the content on rosettacode appears to be licensed under GNU FDL, I believe it would just have to be released under the GNU FDL or a similar copyleft license that fulfills the GNU FDL.

Definitely, having a link to http://rosettacode.org/wiki/Category:D would be useful.

As for providing some of the examples in-place, there are two pieces of that legal puzzle:

1. The definitions of the problem to solve
Most tasks on Rosetta code are common and generic: concatenate strings, sort a collection of integers using merge/quick/whatever sort, etc., so they aren't anything that had its first appearance on RC. Copy-pasting the exact phrasing of those problems from RC would be a violation, but describing them on your own certainly is not.

2. The solutions to problems
Copying those code snippets in general may violate GNU FDL (if it exceeds the scope of citation), but if the complete D answer to a challenge on RC was provided by bearophile, and wasn't a modification of an existing answer, *he himself* can give you a separate licensing deal to re-use his code in whatever way you want, because when posting a solution to RC there is no mention (I assume that there isn't, because it would make no sense, but please verify) that you sign over your work to them, giving RC an *exclusive* license to use it.

> Yah, nitpicks should go there too. We need to have an understanding that statistically everybody is on SO and nobody here :o).

I have seen repeatedly - on stack overflow and elsewhere - people benchmarking 'D' against other languages using dmd.  The messaging on the home page and download page is not clear.  We might consider making it clearer - dmd for fast compilation and ldc/gdc for fast code if you need it - because not doing so undermines a key benefit of D.

And an article on general techniques to make D code fast would be good both for the web site and for Adam's newsletter.  I am not the person to write this for now.


Laeeth.

On 2015-03-21 at 12:34, Laeeth Isharc wrote:
> has he actually given his sole rights to use his work them? [...]

ROTFL, we must be telepathically linked. :)

On 2015-03-19 at 09:41, Walter Bright wrote:
> On 3/18/2015 4:41 PM, Walter Bright wrote:
>> #include <stdbool.h>
>> #include <stdio.h>
>>
>> typedef long T;
>> bool find(T *array, size_t dim, T t) {
>>   int i;
>>   for (i = 0; i <= dim; i++);
>>   {
>>      int v = array[i];
>>      if (v == t)
>>          return true;
>>   }
>> }
>
> Bugs:
>
> 1. i should be size_t
> 2. <= should be <
> 3. extraneous ;
> 4. v should be type T
> 5. missing return

Two more things, I believe, but they aren't really internal bugs of find:
a null array or array > 2GB on 32-bit that would cause negative indexing:

assert(array != 0);
assert(dim <= PTRDIFF_MAX);

On 3/20/15 9:43 PM, Sebastiaan Koppe wrote:
> On Saturday, 21 March 2015 at 01:31:21 UTC, Andrei Alexandrescu wrote:
>> On 3/20/15 5:56 PM, Walter Bright wrote:
>>> On 3/20/2015 5:23 PM, Andrei Alexandrescu wrote:
>>>> Yah, and uses reference counting for management. -- Andrei
>>>
>>> Ref counting won't improve splitLines, because it must keep them all.
>>
>> Yah, all solution based on "let's keep all lines so we count them at
>> the end" are suboptimal. -- Andrei
>
> What about `.count("\n")` ?

Using "count" is among the solutions I measured: http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d/29153508#29153508 -- Andrei

On 3/20/2015 3:50 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> High level constructs may be  cleaner if done right, and sometimes saves
> programmer time, but it will never be as fast on the standard CPU architectures
> we have today. The hardware favours carefully planned iterative, imperative
> approaches. That was true before SIMD and caching, and it is even more true now.

It's less true for SIMD. To take advantage of SIMD, compilers have to reverse engineer low level loops into a higher level construct, then re-compile for SIMD.

On Saturday, 21 March 2015 at 17:55:09 UTC, Walter Bright wrote:
> On 3/20/2015 3:50 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> High level constructs may be  cleaner if done right, and sometimes saves
>> programmer time, but it will never be as fast on the standard CPU architectures
>> we have today. The hardware favours carefully planned iterative, imperative
>> approaches. That was true before SIMD and caching, and it is even more true now.
>
> It's less true for SIMD. To take advantage of SIMD, compilers have to reverse engineer low level loops into a higher level construct, then re-compile for SIMD.

No. You have to design so that you don't get dependencies on the same vector register.

On 3/21/2015 11:02 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Saturday, 21 March 2015 at 17:55:09 UTC, Walter Bright wrote:
>> On 3/20/2015 3:50 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> High level constructs may be  cleaner if done right, and sometimes saves
>>> programmer time, but it will never be as fast on the standard CPU architectures
>>> we have today. The hardware favours carefully planned iterative, imperative
>>> approaches. That was true before SIMD and caching, and it is even more true now.
>>
>> It's less true for SIMD. To take advantage of SIMD, compilers have to reverse
>> engineer low level loops into a higher level construct, then re-compile for SIMD.
>
> No. You have to design so that you don't get dependencies on the same vector
> register.

I know I shouldn't, but I'll bite. Show me the "low level C code" that effectively uses SIMD vector registers.

On Saturday, 21 March 2015 at 19:35:02 UTC, Walter Bright wrote:
> I know I shouldn't, but I'll bite. Show me the "low level C code" that effectively uses SIMD vector registers.

You are right, you should not bite. C code is superflous, this is a general issue with efficient parallel computations. You want to avoid dependencies within a single register.

E.g. Take a recurrence relation and make an efficient simd implementation for it.  You might need to try to expand the terms so you have N independent formulas. If it uses floating point you will have to be careful about drift between the N formulas that are computed in parallel.

On 3/21/2015 2:08 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Saturday, 21 March 2015 at 19:35:02 UTC, Walter Bright wrote:
>> I know I shouldn't, but I'll bite. Show me the "low level C code" that
>> effectively uses SIMD vector registers.
>
> You are right, you should not bite. C code is superflous, this is a general
> issue with efficient parallel computations. You want to avoid dependencies
> within a single register.
>
> E.g. Take a recurrence relation and make an efficient simd implementation for
> it.  You might need to try to expand the terms so you have N independent
> formulas. If it uses floating point you will have to be careful about drift
> between the N formulas that are computed in parallel.
>

I.e. there isn't low level C code that effectively uses SIMD vector registers. You have to use the auto-vectorizer, which tries to reconstruct high level operations out of C low level code, then recompile.