• Bruce Carneal (7/7) Jul 30 2024 Would an @restrict function attribute that applied to all ptr and
• kinke (5/7) Jul 31 2024 I don't think it'd be a good idea in general, and it wouldn't
• Bruce Carneal (13/20) Jul 31 2024 Not a good idea eh? Well, using the alternative available today
• sternwaytrysail (3/10) Sep 12 2024 So do you have any other solutions to the problems people are
• JasonKitty (4/15) Oct 31 2024 You might consider other approaches, such as using pointer-based
• Gladstone (10/17) Oct 31 2024 For performance-critical functions, especially in environments
• NadiaEira (8/15) Aug 08 2024 It sounds like the @restrict function attribute would be really
• Sergey (2/8) Aug 08 2024 AI that we deserved :D

Bruce Carneal <bcarneal gmail.com> writes:

Would an  restrict function attribute that applied to all ptr and 
slice arguments be hard to implement?

I'd use this on most if not all of my performance critical 'leaf' 
functions for both auto-vec and dcompute environments.  Nested 
functions accepting individual  restrict pointer arguments are an 
OK alternative but when working with multiple inputs and outputs 
things get a little tangled.

kinke <noone nowhere.com> writes:

On Tuesday, 30 July 2024 at 16:50:05 UTC, Bruce Carneal wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

I don't think it'd be a good idea in general, and it wouldn't 
simplify the implementation of ` restrict` for slices at all, 
which would most likely need an ABI change 
(https://forum.dlang.org/post/vgfxycegiagawfxaenwg forum.dlang.org).

Bruce Carneal <bcarneal gmail.com> writes:

On Wednesday, 31 July 2024 at 10:16:57 UTC, kinke wrote:
 On Tuesday, 30 July 2024 at 16:50:05 UTC, Bruce Carneal wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

 I don't think it'd be a good idea in general, and it wouldn't 
 simplify the implementation of ` restrict` for slices at all, 
 which would most likely need an ABI change 
 (https://forum.dlang.org/post/vgfxycegiagawfxaenwg forum.dlang.org).

Not a good idea eh?  Well, using the alternative available today 
extensively I disagree.  The use case is for  safe performance 
critical programming where the compiler can not readily determine 
the aliasing (you'll see some code expansion in current LDC for 
very simple cases where the generated code first proves 
independence).

Still, thanks for the response.  I'll stick with the 
manual/ trusted nested functions workaround.  It is *much* better 
than nothing, having allowed me to ditch my entire explicit SIMD 
code base.  Well, almost everything.  I still have need for an 
efficient mapping of conditionals to bit vectors and don't know 
how to do that without dropping into SIMD land.

sternwaytrysail <bairdhoward50 gmail.com> writes:

On Wednesday, 31 July 2024 at 10:16:57 UTC, kinke wrote:
 On Tuesday, 30 July 2024 at 16:50:05 UTC, Bruce Carneal wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

 I don't think it'd be a good idea in general, and it wouldn't 
 simplify the implementation of ` restrict` for slices at all, 
 which would most likely need an ABI change 
 (https://forum.dlang.org/post/vgfxycegiagawfxaenwg forum.dlang.org
https://planet-clicker.com).

So do you have any other solutions to the problems people are 
facing?

JasonKitty <angelaesper43 gmail.com> writes:

On Thursday, 12 September 2024 at 16:20:34 UTC, sternwaytrysail 
wrote:
 On Wednesday, 31 July 2024 at 10:16:57 UTC, kinke wrote:
 On Tuesday, 30 July 2024 at 16:50:05 UTC, Bruce Carneal wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

 I don't think it'd be a good idea in general, and it wouldn't 
 simplify the implementation of ` restrict` for slices at all, 
 which would most likely need an ABI change 
 (https://forum.dlang.org/post/vgfxycegiagawfxaenwg forum.dlang.orghttps://sexdolltech.com/).

 So do you have any other solutions to the problems people are 
 facing?

You might consider other approaches, such as using pointer-based 
methods or reference counting to manage memory safely.

Gladstone <charlesyhz06 outlook.com> writes:

On Wednesday, 31 July 2024 at 10:16:57 UTC, kinke wrote:
 On Tuesday, 30 July 2024 at 16:50:05 UTC, Bruce Carneal wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

 I don't think it'd be a good idea in general, and it wouldn't 
 simplify the implementation of ` restrict` for slices at all, 
 which would most likely need an ABI change 
 (https://forum.dlang.org/post/vgfxycegiagawfxaenwg forum.dlang.org)
(https://bestrealdoll.com/).

For performance-critical functions, especially in environments 
like auto-vectorization and DCompute, it's crucial to maintain 
clarity while ensuring optimal performance. While nested 
functions can be a workaround, they might complicate the code 
when dealing with multiple inputs and outputs. If you’re 
considering an implementation change, it’s wise to weigh the 
benefits against potential ABI changes and the complexity it 
might introduce. Keeping the code maintainable while optimizing 
performance is a delicate balance.

NadiaEira <nadiaeira00 gmail.com> writes:

On Tuesday, 30 July 2024 at 16:50:05 UTC, [cookie clicker 
2](https://cookieclicker-2.com) wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

 I'd use this on most if not all of my performance critical 
 'leaf' functions for both auto-vec and dcompute environments.  
 Nested functions accepting individual  restrict pointer 
 arguments are an OK alternative but when working with multiple 
 inputs and outputs things get a little tangled.

It sounds like the  restrict function attribute would be really 
useful for optimizing performance in your code. Implementing it 
for all ptr and slice arguments could definitely simplify things, 
especially for complex functions with multiple inputs and 
outputs. It's a great idea to consider for both auto-vec and 
dcompute environments.

Sergey <kornburn yandex.ru> writes:

On Thursday, 8 August 2024 at 07:33:37 UTC, NadiaEira wrote:
 It sounds like the  restrict function attribute would be really 
 useful for optimizing performance in your code. Implementing it 
 for all ptr and slice arguments could definitely simplify 
 things, especially for complex functions with multiple inputs 
 and outputs. It's a great idea to consider for both auto-vec 
 and dcompute environments.

AI that we deserved :D