03-Apr-2014 00:46, Walter Bright пишет:
> On 4/2/2014 12:38 PM, Dmitry Olshansky wrote:
>> Ideally we'd need:
>> a) A collection of meaningful (high-level compared to std.simd)
>> primitives that
>> can be accelerated by SIMD, in Phobos. Such as searching, bit-counting
>> etc.
>
> memchr is already optimized by SIMD, and std.algorithm.find uses memchr.
> In general, enormous effort has been poured into optimizing C standard
> library functions. If an algorithm can be implemented using such
> functions, we ought to.
>

This is all good and well, but...
memchr is working on the level of a single byte, leaving nothing for 2, 4, 8 byte-wide needles. Not type-safe. No fallback for CTFE.

Obviously C standard is lacking many things, hence the endless row of extensions.

-- 
Dmitry Olshansky

On 4/2/2014 1:54 PM, Dmitry Olshansky wrote:
> If we can alter semantics of
> return foo(arg);
> to _always_ be a goto, guarantee a jump and reuse of the stack,  then I'm all
> for it.

I don't see why not. Note that we couldn't do this for extern(C) functions, or variadics, or caller functions with parameters that need destruction, or parameters that may refer to any locals. That last constraint might be a doozy, however.

Why not submit an enhancement request to bugzilla?

Brad Anderson:

>> immutable bool[256] tab3 =
>>    ubyte
>>    .max
>>    .iota!"[]"
>
> I can't decide if this part is brilliant or terrible. Clever, either way.

That iota enhancement has nothing terrible: the "[]" syntax is already used in Phobos for std.range.uniform, and it's quite needed, otherwise it can't generate the right bound of a type (like the last ubyte, last byte, last char, last int, etc).

Bye,
bearophile

Walter Bright:

> I don't see why not. Note that we couldn't do this for extern(C) functions, or variadics, or caller functions with parameters that need destruction, or parameters that may refer to any locals. That last constraint might be a doozy, however.
>
> Why not submit an enhancement request to bugzilla?

So what does it happen if I (by mistake or by ignorance) try to use this on a function that doesn't satisfy one of those requirements? D can't give an error in that case because it's a big breaking change. So is D in that case just silently not performing the tail call as the programmer meant?

Bye,
bearophile

On 4/2/2014 3:06 PM, bearophile wrote:
> Walter Bright:
>
>> I don't see why not. Note that we couldn't do this for extern(C) functions, or
>> variadics, or caller functions with parameters that need destruction, or
>> parameters that may refer to any locals. That last constraint might be a
>> doozy, however.
>>
>> Why not submit an enhancement request to bugzilla?
>
> So what does it happen if I (by mistake or by ignorance) try to use this on a
> function that doesn't satisfy one of those requirements?

Then it won't tail call it.

> D can't give an error in that case because it's a big breaking change. So is D in that case just
> silently not performing the tail call as the programmer meant?

That's right.

Walter Bright:

>> D can't give an error in that case because it's a big breaking change. So is D in that case just
>> silently not performing the tail call as the programmer meant?
>
> That's right.

Then this feature needs a specific and explicit syntax, or it has _no_ point at all.
(Note: I am currently not asking for this feature in D. I have just shown one of its minimal requirements).

Bye,
bearophile

On Wednesday, 2 April 2014 at 21:58:33 UTC, bearophile wrote:
> Brad Anderson:
>
>>> immutable bool[256] tab3 =
>>>   ubyte
>>>   .max
>>>   .iota!"[]"
>>
>> I can't decide if this part is brilliant or terrible. Clever, either way.
>
> That iota enhancement has nothing terrible: the "[]" syntax is already used in Phobos for std.range.uniform, and it's quite needed, otherwise it can't generate the right bound of a type (like the last ubyte, last byte, last char, last int, etc).
>
> Bye,
> bearophile

I was more referring to ubyte.max.iota :)

On 4/2/2014 6:21 PM, bearophile wrote:
> Then this feature needs a specific and explicit syntax, or it has _no_ point at
> all.

That's like saying inlining has no point because it doesn't have a particular syntax.

On Wednesday, 2 April 2014 at 21:18:19 UTC, Dmitry Olshansky wrote:
> 03-Apr-2014 00:46, Walter Bright пишет:
>> On 4/2/2014 12:38 PM, Dmitry Olshansky wrote:
>> memchr is already optimized by SIMD, and std.algorithm.find uses memchr.
>> In general, enormous effort has been poured into optimizing C standard
>> library functions. If an algorithm can be implemented using such
>> functions, we ought to.
>
> This is all good and well, but...
> memchr is working on the level of a single byte, leaving nothing for 2, 4, 8 byte-wide needles. Not type-safe. No fallback for CTFE.

I found myself needing "wmemchr" (and optionally "dmemchr") for speeding up find for wstrings and dstrings.

I realized "wmemchr" exists, but it is platform defined: ushort (w) on windows, and uint (d) on linux.

So it's hard to use, and definitely not the "W" version I'd expect in D code.

If I were to request the actual "memchr"/"wmemchr"/"dmemchr" functions in some "core.???" module, is this something we'd want, and would somebody know how to provide an efficient implementation?

Walter Bright:

> That's like saying inlining has no point because it doesn't have a particular syntax.

Hopefully Dmitry Olshansky can explain why you are probably wrong regarding the proposed feature.

Bye,
bearophile