By: Brett (ggtgp.delete@this.yahoo.com), May 21, 2022 5:18 pm
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on May 21, 2022 12:33 pm wrote:
> anon2 (anon.delete@this.anon.com) on May 21, 2022 1:45 am wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on May 21, 2022 12:06 am wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on May 20, 2022 8:42 pm wrote:
> > > >
> > > > Just because a thread got migrated to a P core doesn't mean it has to stay there - you could migrate
> > > > a thread back to the E core for a while (until it uses the library again) if you want.
> > >
> > > That's the "hey, this can be fixed" thing.
> > >
> > > But the unfixable thing is much more fundamental: 'cpuid' is suddenly not reliable or meaningful.
> > >
> > > Basically, what does 'cpuid' mean?
> > >
> > > Does it mean "what are the capabilities of the CPU I happen to be running on right now"? But
> > > then it's useless in any system where the load can be migrated to another CPU at any time.
> > >
> > > Or does 'cpuid' mean "Ok, I now give you a set of capabilities that I guarantee"? So now any
> > > process that has ever run 'cpuid' will be tied to a code that matches what it was told?
> >
> > Have all cores report AVX-512 is available even the small cores. When a small core tries
> > to execute an AVX-512 instruction it will trap and the OS can move it to a big core
> > then resume it. They don't have to be stuck there, you can have heuristics (time interval,
> > or look at AVX-512 activity) to allow it to move back to a small core.
>
>
> Did you miss his subsequent prebuttal to that idea?
>
>
> > > If you claim you do AVX512, then all processes end up getting pinned to
> > > big cores just because some random library goes "oh, then I'll use it".
>
>
> In another thread dmcq suggests that strlen() not only could but should be implemented with inline SVE2
> code had Apple included it on M1 and thus made it a standard feature of all Apple Silicon Macs.
C style string functions are the origins of most security holes, Swift does not use C stings.
Also C stings are fundamentally slow, another reason Apple does not use them.
Use a real language like Swift or Rust, etc.
> The possibility of supporting SVE2 on big cores only would be out the window in
> such a case. Even if your own code doesn't call strlen() directly, for every library
> call you make the chance your code uses strlen() quickly approaches 100%.
>
> It only takes one "clever" programmer deciding to utilize AVX-512 in libc or some GUI library
> everyone needs for it to become a limitation on how much code can run on cores that lack it.
>
> anon2 (anon.delete@this.anon.com) on May 21, 2022 1:45 am wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on May 21, 2022 12:06 am wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on May 20, 2022 8:42 pm wrote:
> > > >
> > > > Just because a thread got migrated to a P core doesn't mean it has to stay there - you could migrate
> > > > a thread back to the E core for a while (until it uses the library again) if you want.
> > >
> > > That's the "hey, this can be fixed" thing.
> > >
> > > But the unfixable thing is much more fundamental: 'cpuid' is suddenly not reliable or meaningful.
> > >
> > > Basically, what does 'cpuid' mean?
> > >
> > > Does it mean "what are the capabilities of the CPU I happen to be running on right now"? But
> > > then it's useless in any system where the load can be migrated to another CPU at any time.
> > >
> > > Or does 'cpuid' mean "Ok, I now give you a set of capabilities that I guarantee"? So now any
> > > process that has ever run 'cpuid' will be tied to a code that matches what it was told?
> >
> > Have all cores report AVX-512 is available even the small cores. When a small core tries
> > to execute an AVX-512 instruction it will trap and the OS can move it to a big core
> > then resume it. They don't have to be stuck there, you can have heuristics (time interval,
> > or look at AVX-512 activity) to allow it to move back to a small core.
>
>
> Did you miss his subsequent prebuttal to that idea?
>
>
> > > If you claim you do AVX512, then all processes end up getting pinned to
> > > big cores just because some random library goes "oh, then I'll use it".
>
>
> In another thread dmcq suggests that strlen() not only could but should be implemented with inline SVE2
> code had Apple included it on M1 and thus made it a standard feature of all Apple Silicon Macs.
C style string functions are the origins of most security holes, Swift does not use C stings.
Also C stings are fundamentally slow, another reason Apple does not use them.
Use a real language like Swift or Rust, etc.
> The possibility of supporting SVE2 on big cores only would be out the window in
> such a case. Even if your own code doesn't call strlen() directly, for every library
> call you make the chance your code uses strlen() quickly approaches 100%.
>
> It only takes one "clever" programmer deciding to utilize AVX-512 in libc or some GUI library
> everyone needs for it to become a limitation on how much code can run on cores that lack it.
>