7

I (mostly) like the new C++ Core Guidelines initiative, and what the Guidelines Support Libary offers. Specifically, I want to use spans more. However, I'm coming up against the issue of __restrict__ not being part of C++ while I want to/need to use it.

To be more concrete: Without span's, I would declare:

void foo(int* __restrict__ p, size_t len);

But if I now declare:

void foo(gsl::span<int> s);

I don't get the __restrict__ effect unless my compiler super-smart. I could pray real hard to the gods of gcc/clang/msvc and say:

void foo(gsl::span<int> __restrict__ s);

or alternatively, I could tweak the GSL span<T> implementation so that the T* begin and T* end pointers are themselves __restrict__'ed. However, it's not at all certain this will be respected.

So, can I force the __restrict__'ion somehow? Or should I just give it up? This kind of takes the fun out of switching to span's...

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • My personal opinion: If you care enough about performance that you want to use `__restrict__` on `gsl::span`you probably don't want to use `gsl::span` in the first place, but first I'd make sure that switching to span actually slows down your program. – MikeMB Feb 21 '17 at 13:53
  • @MikeMB: Why would you say that? It's the exact opposite. We're in C++ ... I want to use a _higher_ level of abstraction _and_ improve performance at the same time... :-) Also, I want to avoid my API blowing up with ever more parameters. – einpoklum Feb 21 '17 at 13:59
  • @MikeMB: But let me ask you this: How about only using a pointer-and-length pair internally? That is, assigning `int* __restrict__ p = s.data();` ? – einpoklum Feb 21 '17 at 14:02
  • Of course this depends on the particular use case, platform, compiler etc. and my opinion is based on a pretty small data set. However, my general assumption (until I determined otherwise via benchmarks) is that if you care about the 0-10% performance improvement that `__restrict__` may provide, the overhead introduced by `gsl::span` will probably forbidding. If you care about a particular piece of code, where `__restrict__` allows the compiler to generate significantly more efficient code then it is very likely, that the added indirection will break those compiler optimizations. – MikeMB Feb 21 '17 at 15:05
  • And when I say *"use"* I mean actually using the span to access the data (via iterators or the index operator) - not just having a struct that bundles a pointer and a length, which you then split up again – MikeMB Feb 21 '17 at 15:06

0 Answers0