Phobos 3 Discussion Notes - 02-01-2024

[jmh530]

On Friday, 2 February 2024 at 18:39:33 UTC, Hipreme wrote:
> On Friday, 2 February 2024 at 18:19:47 UTC, jmh530 wrote:
>> On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote:
>>> Walter and I had a productive conversation yesterday about 
>>> Phobos 3 and we felt it would be appropriate to share some 
>>> notes on our discussion.
>>>
>>> [snip]
>>
>> When it comes to discussions around functions that allocate to 
>> the heap, I think there is some benefit in implementing 
>> lower-level functionality in functions that do not do any 
>> allocations whatsoever. You can then have higher level API 
>> above that that controls allocation and is more convenient to 
>> use. That way users can opt in to whatever they want or write 
>> their own more convenient API on top of the lower level 
>> functions.
>>
>> May not work for everything, but could be a useful approach.
>
>
> It may be still a bad solution. Countless times I have done 
> functions which know how much to preallocate. The eager 
> solution always seems to be a lot faster, and I have noticed 
> the pattern of using `map` or `filter` or anything more + 
> `.array` looking to infinitely slower than if you had a direct 
> version. And I don't know about `release` versions. The thing 
> is that 99% of the time I'm testing on debug builds and getting 
> less speed only because I'm on debug looks really bad.
>

The work I’ve been doing is related to linear algebra. Nothing 
really lazy or map-like. For instance, think of it like dgemm 
doing matrix multiplication without doing any allocations. It 
takes a pointer to the result matrix as an input and requires 
information about how  if that will be. A higher level D version 
could work in terms of slices so that the API is cleaner. A 
higher level API could handle the case where the result is 
allocated with GC.