otherwise how do you differentiate Get on PtrType<T> vs Get on PtrType<Ptr<T>>

M

MaxineOP•8/4/23, 8:35 PM

there isn't a generic for "not this"

M

MaxineOP•8/4/23, 8:36 PM

at one point there was a proposal for extension indexers but it never happened

P

Perksey•8/4/23, 8:36 PM

it'd be

Get<T>(this Ptr<T> x)

Get<T>(this Ptr<T> x)

Get<T>(this Ptr<T> x)

Get<T>(this Ptr<T> x) where

T

T does not allow ref structs as a generic

P

Perksey•8/4/23, 8:36 PM

oh fuck yeah

P

Perksey•8/4/23, 8:36 PM

shit

K

Kai•8/4/23, 8:37 PM

can implement it on the inside with

public static class PtrAccessor  
{
    public static PtrType<T2> Get<T2, T>(this PtrType<T> self, int i)
        where T: IPtrMarker<T2>
    {
         // IDK take an index and do magic with the inner of PtrType
        throw null;
    }
    public static PtrType<T3> Get<T3, T2, T>(this PtrType<T> self, int i, int j)
        where T: IPtrMarker<T2>
        where T2: IPtrMarker<T3>
    {
        return self.Get(i).Get(j);
    }
}

public static class PtrAccessor  
{
    public static PtrType<T2> Get<T2, T>(this PtrType<T> self, int i)
        where T: IPtrMarker<T2>
    {
         // IDK take an index and do magic with the inner of PtrType
        throw null;
    }
    public static PtrType<T3> Get<T3, T2, T>(this PtrType<T> self, int i, int j)
        where T: IPtrMarker<T2>
        where T2: IPtrMarker<T3>
    {
        return self.Get(i).Get(j);
    }
}

public static class PtrAccessor  
{
    public static PtrType<T2> Get<T2, T>(this PtrType<T> self, int i)
        where T: IPtrMarker<T2>
    {
         // IDK take an index and do magic with the inner of PtrType
        throw null;
    }
    public static PtrType<T3> Get<T3, T2, T>(this PtrType<T> self, int i, int j)
        where T: IPtrMarker<T2>
        where T2: IPtrMarker<T3>
    {
        return self.Get(i).Get(j);
    }
}

public static class PtrAccessor  
{
    public static PtrType<T2> Get<T2, T>(this PtrType<T> self, int i)
        where T: IPtrMarker<T2>
    {
         // IDK take an index and do magic with the inner of PtrType
        throw null;
    }
    public static PtrType<T3> Get<T3, T2, T>(this PtrType<T> self, int i, int j)
        where T: IPtrMarker<T2>
        where T2: IPtrMarker<T3>
    {
        return self.Get(i).Get(j);
    }
}

K

Kai•8/4/23, 8:37 PM

try not to stare into the sun too long

M

MaxineOP•8/4/23, 8:37 PM

we don't need the interface for this

M

MaxineOP•8/4/23, 8:37 PM

i reckon

K

Kai•8/4/23, 8:37 PM

we do cause there is

PtrType

PtrType

PtrType

PtrType/

Ptr

Ptr

Ptr

Ptr and also

ConstPtrType

ConstPtrType

ConstPtrType

ConstPtrType/

ConstPtr

ConstPtr

ConstPtr

ConstPtr

M

MaxineOP•8/4/23, 8:37 PM

hmm

M

MaxineOP•8/4/23, 8:37 PM

fair

K

Kai•8/4/23, 8:38 PM

Gotta bend the type system to your will

M

MaxineOP•8/4/23, 8:38 PM

this is so stupid i can't believe we're doing it

K

Kai•8/4/23, 8:38 PM

have you looked at Scalar.As https://github.com/dotnet/Silk.NET/blob/main/src/Maths/Silk.NET.Maths/Scalar.As.cs

M

MaxineOP•8/4/23, 8:39 PM

never speak to me again /j

AAqua hmm that's where i disagree one of the big benefits of C# is that it *has* overl...

P

Perksey•8/4/23, 8:39 PM

this was the start of the 3 year journey of Silk.NET's overloads.
in Silk.NET 1.0 it was exactly like that, we had a pointer, a ref, and an array overload. however this locks you into using all unsafe, all refs, or all arrays. no in between.
in 2.0 I tried an experiment to allow our users more flexibility and generate permutations of our overloads. this worked well until we brought non-Khronos bindings into the mix and things weren't as simple. we started generating too many.
it is all or nothing, and the .NET Foundation is embracing that. Silk.NET 3.0 is the start of my goal to harmonize the .NET Foundation's bindings offerings, with ClangSharp being the common denominator, TerraFX being the "completely raw" option, and Silk.NET being the "at home with C#" option. the idea being there is no sacrifice in API coverage in going between any of the mutual bindings, you just pick the style you prefer.

Silk.NET remains committed to making unsafe possible, but silk will prioritise not unsafe just as much as unsafe because unsafe is TerraFX's forte. I will explain the DSL in detail in docs (the idea is I want something simple so that we can just tell our users "want to take a ref? use an

AsPtr

AsPtr

AsPtr

AsPtr method on the thing you want to take a ref to"), the SDP requires docs and unless we want to ignore our approved proposals we are not allowed to ship without docs.

P

Perksey•8/4/23, 8:40 PM

but even with these designs, it is still perfectly possible to just pretend the signatures are unsafe still.

K

Kai•8/4/23, 8:40 PM

remember that C# has lots of implicit type changes to help you here

M

MaxineOP•8/4/23, 8:40 PM

yeah

K

Kai•8/4/23, 8:40 PM

and hopefully it doesn't matter after the JIT has had a thorough look at it

M

MaxineOP•8/4/23, 8:40 PM

you guys know that if there is sufficient IL in a method the JIT will just refuse to inline it even with AggressiveInlining

M

MaxineOP•8/4/23, 8:40 PM

i hope we don't run into that

P

Perksey•8/4/23, 8:41 PM

so Silk.NET.Maths is one of the reasons why the JIT is a lot more lax about that now

M

MaxineOP•8/4/23, 8:42 PM

i guess tanner being here gives you some pull

P

Perksey•8/4/23, 8:42 PM

it still has limits sure, but we were able to do more generic instantiations in recent JITs

MMaxine i guess tanner being here gives you some pull

P

Perksey•8/4/23, 8:42 PM

this was actually Andy Ayers responding to one of Kai's issues, with impressive turnaround too

M

MaxineOP•8/4/23, 8:42 PM

oh, sweet!

L

Lyris the Kitori•8/4/23, 8:42 PM

im going to inline every function and have a gigabyte bin

PPerksey this was the start of the 3 year journey of Silk.NET's overloads. in Silk.NET 1....

A

Aqua•8/4/23, 8:42 PM

i can't think of a situation where someone would reasonably need to mix and match refs arrays and unsafe, in any combination
99.9% of people will either be using fully managed, or fully unsafe, i can almost guarantee
just look at opentk, i have never once seen anyone use the pointer overloads, span overloads, etc
i've only ever seen people use the safe overloads

LLyris the Kitori im going to inline every function and have a gigabyte bin

M

MaxineOP•8/4/23, 8:43 PM

the point of most of these functions is that they can be squished down to 0 native code when called :P

K

Kai•8/4/23, 8:43 PM

Honestly the JIT team has impressive speed when you show the some IL -> ASM dump that is "bad" and have at least a batshit crazy reason to do this (at least any reason)

A

Aqua•8/4/23, 8:43 PM

i get wanting to make it feel at home in C#, i think that's a good way to go about doing things
but i don't personally think adding extra types is the right way to go

A

Aqua•8/4/23, 8:43 PM

I did that with pie a long time ago, it was absolutely horrible to use

M

MaxineOP•8/4/23, 8:44 PM

what's your idea then?

M

MaxineOP•8/4/23, 8:44 PM

keep as-is, unsafe everything?

P

Perksey•8/4/23, 8:44 PM

it's worth noting what we're discussing here is not Silk.NET 3.0. This is SilkX, a completely different library. there is still room for another contributor to create a different library to propose that it gets blessed as 3.0

AAqua i can't think of a situation where someone would reasonably need to mix and matc...

K

khitiara•8/4/23, 8:44 PM

ive mixed arrays and ref at the same time in calls a ton actually, albeit not mixing safe and unsafe, mixing ref and span is useful a ton actually

MMaxine you guys know that if there is sufficient IL in a method the JIT will just refus...

K

Kai•8/4/23, 8:45 PM

Idk if this is up to date btw, but technically AggressiveInlining is guaranteed for top-level inlines so function A calling function B with AggressiveInlining is guaranteed, but then anything beyond is not, just a strong hint.
And then if it's huge huge you can just make it multiple functions, which will the also help with JIT not perishing when tracking variables and that.

K

Kai•8/4/23, 8:45 PM

but really if those functions have locals and things like that you're probably doing something wrong with AggressiveInlining....

P

Perksey•8/4/23, 8:45 PM

it's not guaranteed, there are still limits but there's just a lot of things that relax those limits now.

P

Perksey•8/4/23, 8:45 PM

oh right

P

Perksey•8/4/23, 8:46 PM

yeah just read your whole comment

P

Perksey•8/4/23, 8:46 PM

I WITHDRAW MY REMARK

V

Volte•8/4/23, 8:47 PM

Deleted User#0000

//   However, there are some caveats to this:
// - We use local functions in addition to the generic typeof(T) == typeof(whatever) pattern to work around some
//   unfortunate inlining issues in platforms older that .NET 5, where the inliner was going over budget despite
//   aggressively inlined functions supposedly being exempt from budgeting.
//   See also: https://github.com/dotnet/runtime/issues/38106

//   However, there are some caveats to this:
// - We use local functions in addition to the generic typeof(T) == typeof(whatever) pattern to work around some
//   unfortunate inlining issues in platforms older that .NET 5, where the inliner was going over budget despite
//   aggressively inlined functions supposedly being exempt from budgeting.
//   See also: https://github.com/dotnet/runtime/issues/38106

//   However, there are some caveats to this:
// - We use local functions in addition to the generic typeof(T) == typeof(whatever) pattern to work around some
//   unfortunate inlining issues in platforms older that .NET 5, where the inliner was going over budget despite
//   aggressively inlined functions supposedly being exempt from budgeting.
//   See also: https://github.com/dotnet/runtime/issues/38106

//   However, there are some caveats to this:
// - We use local functions in addition to the generic typeof(T) == typeof(whatever) pattern to work around some
//   unfortunate inlining issues in platforms older that .NET 5, where the inliner was going over budget despite
//   aggressively inlined functions supposedly being exempt from budgeting.
//   See also: https://github.com/dotnet/runtime/issues/38106

note that on net5 this is only solved for top-level inlines.

Original Message

Click here

Quoted by kaijellinghaus#0000

MMaxine keep as-is, unsafe everything?

A

Aqua•8/4/23, 8:47 PM

not quite
keep unsafe, but have safe overloads as well
aka taking arrays
and perhaps a span as well, although as spans can be converted to pointers very easily i wouldn't say that span is a high priority - i don't see many people using spans (myself included, never seen the point of them)
if you remove the mix and matching, even with spans, you'd have a max of 3 overloads, and as i said before, i'm fairly confident 99% of people will only ever use the fully safe overloads
and having it obvious what they do will really help development and UX
i can say that as a beginner if I saw a

Ptr<T>

Ptr<T>

Ptr<T>

Ptr<T> type instead of an array, I would be very confused
even now I would question why it is using a custom type instead of pure unsafe or safe
on a personal level, I just think

Ptr<T>

Ptr<T>

Ptr<T>

Ptr<T> causes more problems than it solves
i may be missing something here, so this is just a personal opinion on what i've seen so far

P

Perksey•8/4/23, 8:47 PM

this is my point, this is literally Silk.NET 1.X

M

MaxineOP•8/4/23, 8:48 PM

arrays blow, we'd be constantly marshalling and allocating stuff

A

Aqua•8/4/23, 8:48 PM

just internally convert it to a pointer?

K

Kai•8/4/23, 8:48 PM

tbh I'm not against having TerraFX style functions with raw ptr + the typed ptrs

otherwise how do you differentiate Get on PtrType<T> vs Get on PtrType<Ptr<T>>

Similar Threads