Clang issue with __builtin_expect?

Signature of builtin_expect:

long __builtin_expect (long exp, long c)

It seems that if c isn't constant enough its value doesn't affect codegen.

Example here: https://godbolt.org/z/iy_RUF

If USE_FUNCTION is defined then the value of V doesn't matter. But it does matter if V is used directly.
gcc seems to behave as expected, as does icc.

https://redd.it/fcxx51
@r_cpp

Why does operator== only get generated for *defaulted* operator<=>?

To elaborate on the title, consider a defaulted three-way comparison operator for a type:

```
struct MyType
{
auto operator<=>(const MyType& other) const = default;
int value;
};

int main()
{
MyType a{ 42 }, b{ 24 };
return a == b; // works fine
}
```

Now if we change that three-way comparison operator to no longer be defaulted, but still have the same effect:

```
struct MyType
{
auto operator<=>(const MyType& other) const { return value <=> other.value; }
int value;
};

int main()
{
MyType a{ 42 }, b{ 24 };
return a == b; // ***no longer works***
}
```

Godbolt: https://godbolt.org/z/uyqRo6

It is easy (but annoying) to work around by defining `bool operator==(const MyType& other) const { return std::is_eq(*this <=> other); }`, but I feel like I shouldn't have to do that.

Is there some logical reason why the equality operators can *never* be generated from a non-defaulted three-way comparison operator?

I'm already aware of the potential performance losses with three-way comparisons on complex types, but for simple struct types I feel like this should be automatic and just as performant.

https://redd.it/go7a5p
@r_cpp

importing functions from dlls without having anything placed in .data section

Typically, when people are doing dynamic function imports from dlls, they use global function pointers.

const auto OpenProcess = (void*(*)(int, bool, int))GetProcAddr(GetModuleHandle(L"kernel32.dll"), "OpenProcess");
const auto WriteProcessMemory = (bool(*)(void*,void*,const void*,std::size_t,std::size_t))GetProcAddr(GetModuleHandle(L"kernel32.dll"), "WriteProcessMemory");

The problem with using global function pointers for dynamic import is that, people that looks at your compiled file can see code like this

mov rax, QWORD PTR[somewhere_inside_data_section]
call rax

If they follow somewhere_inside_data_section with a debugger, after your program has finished doing dynamic import, they will see all the functions you imported.

One of the solutions to this problem is that, you can do the import right before calling the function. This way the function pointer is placed on the stack(or in a register) instead of somewhere inside .data section.

int main()
{
const auto OpenProcess = (void*(*)(int, bool, int))GetProcAddr(GetModuleHandle(L"kernel32.dll"), "OpenProcess");
OpenProcess(0x1234,true,0x4567);
}

With that, the function pointer is no longer placed inside .data section, but it obfuscate the source code too much. The goal is to obfuscate the compiled file not the source code.

Here is my solution to this problem.

1. define a stateless class with a operator()(...) that matches the function signature of the original dll function.

2. at the begining of operator()(...), find the address of the dll function. (I will use GetModuleHandle/GetProcAddr in the following example, you probably should implement your own)

`DllCaller.h`

#pragma once
#if !(defined(__GNUC__) || defined(__clang__))
#define Inline __forceinline
#else
#define Inline __attribute__((always_inline))
#endif

#include<tuple>

//Stateless
template<class T, T...Cs>
struct String
{
static constexpr std::size_t size{ sizeof...(Cs) };
};
template<class char_type, class lambda_t, std::size_t...I>
constexpr auto make_string(lambda_t lambda [[maybe_unused]], std::index_sequence<I...>)noexcept
{
static_assert(sizeof(char_type) == sizeof(*lambda()));
return String<char_type, lambda()[I]...>{};
}
#define TS(s) (make_string<char>([]()constexpr{return(s);},std::make_index_sequence<sizeof(s)/sizeof(char) - 1>{}))
#define WTS(s) (make_string<wchar_t>([]()constexpr{return(s);},std::make_index_sequence<sizeof(s)/sizeof(wchar_t) - 1>{}))

//Don't do this. Write your own function to walk peb->ldr->moduleList / pe->exportTable
void* GetProcAddr(void* dllBase, const char*);
void* GetModuleHandle(const wchar_t*);
template<class Signature, class C0, C0...Cs0, class C1, C1...Cs1, std::size_t...I0, std::size_t...I1>
Inline Signature getDllFunctionPtrImpl(String<C0, Cs0...>, String<C1,Cs1...>,std::index_sequence<I0...>,std::index_sequence<I1...>)noexcept
{
C0 dllName[sizeof...(Cs0) + 1];
([&]{const_cast<volatile C0&>(dllName[I0]) = Cs0;}(),...);
const_cast<volatile C0&>(dllName[sizeof...(Cs0)]) = C0{};//null terminator

C1 functionName[sizeof...(Cs1) + 1];
([&]{const_cast<volatile C1&>(functionName[I1]) = Cs1;}(),...);
const_cast<volatile C1&>(functionName[sizeof...(Cs1)]) = C1{};//null terminator

return reinterpret_cast<Signature>(GetProcAddr(GetModuleHandle(dllName), functionName));
}

template<class Signature, class C0, C0...Cs0, class C1, C1...Cs1>
Inline Signature getDllFunctionPtr(String<C0, Cs0...> dllName, String<C1,Cs1...> functionName)noexcept
{
return getDllFunctionPtrImpl<Signature>(dllName, functionName, std::make_index_sequence<dllName.size>{}, std::make_index_sequence<functionName.size>{});
}

struct Stateful{};
struct Stateless{};

template<class State, class DllName, class FunctionName, class Signature>

struct DllCaller;

//Stateless: Resolves function pointer everytime when operator()(...) is called
template<class DllName, class FunctionName, class Signature>
struct DllCaller<Stateless, DllName, FunctionName, Signature>
{
template<class...Args>
Inline auto operator()(Args...args)const noexcept -> decltype(std::declval<Signature>()(args...))
{
return getDllFunctionPtr<Signature>(DllName{}, FunctionName{})(args...);
}
};

//Stateful: Resolves function pointer when constructor is called
template<class DllName, class FunctionName, class Signature>
struct DllCaller<Stateful, DllName, FunctionName, Signature>
{
private:
Signature m_ptr;
public:
Inline DllCaller()noexcept:m_ptr{getDllFunctionPtr<Signature>(DllName{}, FunctionName{})}{}
template<class...Args>
Inline auto operator()(Args...args)const noexcept -> decltype(std::declval<Signature>()(args...))
{
return m_ptr(args...);
}
};

template<class State, class Signature, class DllName, class FunctionName>
Inline constexpr DllCaller<State, DllName, FunctionName, Signature> dllCaller(DllName, FunctionName)noexcept{return {};}


`main.cpp`

#include "DllCaller.h"
constexpr DllCaller OpenProcess = dllCaller<Stateless, void*(*)(int, bool, int)>(WTS(L"kernel32.dll"),TS("OpenProcess"));
constexpr DllCaller WriteProcessMemory = dllCaller<Stateless, bool*(*)(void*,void*,const void*,std::size_t,std::size_t)>(WTS(L"kernel32.dll"),TS("WriteProcessMemory"));
int main()
{
void* hProcess = OpenProcess(0x111,true,0x222);
WriteProcessMemory(hProcess, (void*)0x333,(const void*)0x444, 0x555,0x666);
}

Result: https://godbolt.org/z/TY17G4

*ignore the gcc output, it thinks wchar_t is 32bit for some reason.

https://redd.it/hv7zs1
@r_cpp

revision of [P1642](https://wg21.link/p1642) that folds in the non-feature-test macro parts of P1641. The feature-test macro parts are in [P2198: Freestanding Feature-Test Macros and Implementation-Defined Extensions](https://wg21.link/P2198).

# Feature-test macros

When I started doing freestanding work in 2017 with [P0829](https://wg21.link/p0829), feature test macros were just something in a standing document, and weren't in the standard. Now in 2020, I'm pretty sure that freestanding papers have consumed more than half of all the feature-test macro study group's time. With regards to freestanding, the feature test macros are in a bit of a mess. I feel that, in 2030, it will be nice having all the feature test macro stuff worked out, but in 2020, it certainly is painful.

Here's an optimistic answer to a reasonable question that should be answerable with feature test macros.

*Is the non-parallel version of uninitialized\_default\_construct available?*

#if defined(__cpp_lib_raw_memory_algorithms) && __cpp_lib_raw_memory_algorithms >= 201606L
// hosted success path and freestanding extension path
#elif defined(__cpp_lib_freestanding_memory) && __cpp_lib_freestanding_memory >= 202007L
// freestanding path
#else
// fallback path
#endif

I say this is optimistic, because it is also assuming that `<version>` is available. For pre-C++20 compilers, that isn't a guarantee either, and that detection code isn't trivial either.

There are much sadder questions that can be asked in freestanding contexts though...

*Is thread available?*

`// No good answers here. Currently calling this out of scope.`

Getting feature testing right is surprisingly tricky and error prone, especially since the whole point of the feature is to be usable in codebases that need to work on old toolchains. A time machine would be really handy here.

# What's next for freestanding?

The most important aspect of standard C++ affecting freestanding is the lack of suitable error handling. This is also the area that is the most difficult to gain any kind of consensus. Keep an eye out for a paper in the next few months that looks to discuss the many trade-offs in the various standard and standard-track error handling approaches.

Other than that, there are a lot of papers that need to be written to cover the aspects of [P0829](https://wg21.link/P0829) that haven't been covered in [P1642](https://wg21.link/P1642). There are questions in these future papers that need to be resolved by Library Evolution, like "are we willing to split overload sets that look like `std::abs`", "are we willing to have partial class support for classes like `std::array`", and "are we willing to require more C support for freestanding C++ than C requires from freestanding C". These should be straightforward papers, but they would all be competing with a very clogged back log of LEWG papers.

Language Evolution isn't quite as pressed for time, so now would be a good time to get some freestanding features in here. I have new ideas on how to tackle issues involving `thread_local`, as well as constructors and destructors called during startup and termination, but those ideas would need some implementation experience that I haven't found the time for.

The area that most needs attention (that I don't have time to provide) is compile time programming for freestanding environments. `std::vector` is a poor candidate for runtime kernel and embedded programming, but it *should* be just fine for compile-time kernel and embedded programming. What we need is for someone to see what happens when you take all the non-freestanding `constexpr`'s in the standard library, and make them `consteval`. Do bad things happen? Do we end up splitting overload sets in nasty ways? Does the change in object destruction timing frequently cause bugs? I don't know, and would only really know the answer to these questions with some implementation and usage experience.

On top of all that, the Microsoft STL implementation now has much of the test infrastructure open sourced

in case /kernel is used or there is simply no /EH switch
auto never = bv_.at(22);
```
`at()` is very simple
```cpp
// <vector> #2581
_NODISCARD reference at(size_type _Off) {
if (size() <= _Off) {
_Xran();
}
return (*this)[_Off];
}
```
Where `Xran()` is one of the only two noreturn points available inside the `std::vector<T>`
```cpp
// <vector> # 2837
[[noreturn]] void _Xlen() const {
_Xlength_error("vector<bool> too long");
}
// called from std::vector at() method
[[noreturn]] void _Xran() const {
_Xout_of_range("invalid vector<bool> subscript");
}
```
Where that `_Xout_of_range` is declared inside `<xutility>`, together with friends
```cpp
// <xutility> #5817
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xbad_alloc();
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xinvalid_argument(_In_z_ const char*);
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xlength_error(_In_z_ const char*);
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xout_of_range(_In_z_ const char*);
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xoverflow_error(_In_z_ const char*);
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xruntime_error(_In_z_ const char*);
```
There is eight of them. Above six (and other two for: `bad_function_call` and `regex_error`) are defined (implemented) in the above mentioned https://github.com/microsoft/STL/blob/master/stl/src/xthrow.cpp . Available as part of MS STL open source. Back to our `_Xout_of_range` friend
```cpp
// xthrow.cpp # 24
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xout_of_range(_In_z_ const char* const _Message) {
_THROW(out_of_range(_Message));
}
```
And that _THROW is defined in relation to, do we have, or do we not have C++ exceptions compiled in the current build. Meaning: depending on what is the value of the `_HAS_EXCEPTIONS` macro.

All is in the following section of `<yvals.h>`
```cpp
//<yvals.h> # 447
// EXCEPTION MACROS
#if _HAS_EXCEPTIONS
#define _TRY_BEGIN try {
#define _CATCH(x) \
} \
catch (x) {
#define _CATCH_ALL \
} \
catch (...) {
#define _CATCH_END }

#define _RERAISE throw
#define _THROW(x) throw x

#else // _HAS_EXCEPTIONS
#define _TRY_BEGIN \
{ \
if (1) {
#define _CATCH(x) \
} \
else if (0) {
#define _CATCH_ALL \
} \
else if (0) {
#define _CATCH_END \
} \
}

#ifdef _DEBUG
#define _RAISE(x) _invoke_watson(_CRT_WIDE(#x), __FUNCTIONW__, __FILEW__, __LINE__, 0)
#else // _DEBUG
#define _RAISE(x) _invoke_watson(nullptr, nullptr, nullptr, 0, 0)
#endif // _DEBUG

#define _RERAISE
#define _THROW(x) x._Raise()
#endif // _HAS_EXCEPTIONS
```
Thus if we look back into
```cpp
// xthrow.cpp # 24
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xout_of_range(_In_z_ const char* const _Message) {
_THROW(out_of_range(_Message));
}
```
You will understand, in case of no C++ exceptions that becomes
```cpp
// xthrow.cpp # 24
[[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL _Xout_of_range(_In_z_ const char* const _Message) {
out_of_range(_Message)._Raise() ;
}
```

Which means on the instance of `std::out_of_range` exception type there has to be this little peculiar `_Raise()` method.

And, for some people, this is the point of contention where MS STL is leaving the realm of ISO C++ and entering the realm of Windows C++.

#### 1.2.1.2. Into the realm of Windows

If irrelevant for this analysis, code was left out bellow.

```cpp
#if _HAS_EXCEPTIONS

// <exception> # 32
#include <malloc.h>
#include <vcruntime_exception.h>
```
Thus above one can understand in case of C++ exceptions in use this `<vcruntime_exception.h>` gets involved. If curious please follow that path. That is where `std::exceptions` is actually implemented. Back to `<exception>`:
```cpp
// <exception> # 63
#else // ! _HAS_EXCEPTIONS
```
For `_HAS_EXCEPTIONS == 0`, there is this global `_Raise_handler`
```cpp
using _Prhand =

void(__cdecl*)(const exception&);
// <exception> # 76
extern _CRTIMP2_PURE_IMPORT _Prhand _Raise_handler; // pointer to raise handler
```
And in MS STL there is separate version of `std::exception` in existence for `_HAS_EXCEPTIONS == 0` scenario
```cpp
// <exception> # 81
class exception { // base of all library exceptions
public:
static _STD _Prhand _Set_raise_handler(_STD _Prhand _Pnew) { // register a handler for _Raise calls
const _STD _Prhand _Pold = _STD _Raise_handler;
_STD _Raise_handler = _Pnew;
return _Pold;
}
```
That is obviously called to set the global raise handler, before any of the exceptions can be used in the `_HAS_EXCEPTIONS == 0` scenario.

And here is this above mentioned little and peculiar `_Raise()` method which is used instead of the `throw` keyword which is forbidden in the `_HAS_EXCEPTIONS == 0` scenario:

```cpp
// <exception> # 106
[[noreturn]] void __CLR_OR_THIS_CALL _Raise() const
{ // raise the exception
if (_STD _Raise_handler) {
(*_STD _Raise_handler)(*this); // call raise handler if present
}
_Doraise(); // call the protected virtual
_RAISE(*this); // raise this exception
}

protected:
virtual void __CLR_OR_THIS_CALL _Doraise() const {} // perform class-specific exception handling
}; // eof std::exception for _HAS_EXCEPTIONS == 0 scenario
// <exception> # 198
#endif // _HAS_EXCEPTIONS
```
`bad_alloc`, `bad_array_new_length`, `bad_exception` also have different versions for _HAS_EXCEPTIONS == 0 scenario. Back to investigation. That std exception `_Raise()` method uses two levels of indirection: `_Raise_handler` global function pointer and protected `_Doraise` method, before eventually calling the `_RAISE` macro. Remember all of of that is inside `[[noreturn]] void _Raise() const` method on the non standard MS STL version of `std::exception`.

And if we point back to our above `<yvalsh>` mention we shall understand, for `_HAS_EXCEPTIONS == 0` scenario, `_RAISE(x)` macro is defined as:
```cpp
// <yvals.h> # 475
#ifdef _DEBUG
#define _RAISE(x) _invoke_watson(_CRT_WIDE(#x), __FUNCTIONW__, __FILEW__, __LINE__, 0)
#else // _DEBUG
#define _RAISE(x) _invoke_watson(nullptr, nullptr, nullptr, 0, 0)
#endif // _DEBUG
```

#### 1.2.1.3. Use Watson instead?

And that is interesting, to put it mildly. For `_HAS_EXCEPTIONS == 0` scenario, MS STL on each SEH raised, actually calls [Dr Watson to do the job](https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/28725-use-watson-instead). Sherlock is nowhere to be seen.

But that is fine and OK as we have "come out on the other side" into the wonderful kingdom of Windows Drivers. Driver Technologies, Tools for Testing Drivers and namely this little known office of "Windows Error Reporting" to the inner circle known under the acronym of [WER](https://docs.microsoft.com/en-us/windows/win32/wer/windows-error-reporting).

WER basically is that place from where you can call back to daddy and complain.

*"... enables users to notify Microsoft of application faults, kernel faults, unresponsive applications, and other application specific problems. Microsoft can use the error reporting feature to provide customers with troubleshooting information, solutions, or updates for their specific problems. Developers can use this infrastructure to receive information that can be used to improve their applications..."*

But do not fret. We do not do that.

Windows as you know it today is actually Windows NT. And one of the foundation stones of Win NT are "Structured Exceptions" aka [SEH](https://en.wikipedia.org/wiki/Microsoft-specific_exception_handling_mechanisms#SEH). `_invoke_watson` simply raises the SE aka "Structured Exception". And what I do is I simply catch it on the top level. Hint: `main()` is the good place.

Ditto, in case of [SE caught](https://docs.microsoft.com/en-us/windows/win32/debug/using-an-exception-handler), what I do is create and save a minidump specific to my application. And looking into that minidump file with Visual Studio, I can pinpoint the issue that

made the application misbehave. That includes every possible issue, not just C++ exceptions being thrown. And that is very powerful.

I simply have this standard SE aware main in each and every of my WIN apps. That is **not** very complicated and has a lot of benefits.

Please do understand SE is inbuilt in Windows and in the CL compiler and there are SE intrinsics too. Including the [keywords added](https://docs.microsoft.com/en-us/windows/win32/debug/abnormaltermination) to both C and C++.

### 1.2.2. SEH friendly, standard Windows C++, you can do too

Now you know how that mechanism and design works. You can do that too in your C++ Windows, SEH friendly code.

```cpp
namespace my {
inline namespace constants {
enum error_type {
error_ctype,
error_syntax
};
} // my namespace constants

// my::error does not inherit from std::exception
struct error final
{
error () = default ;
const char * msg_ {"unknown"};
const char * what () const noexcept { return msg_ ;
explicit error( constants::error_type ex_ ) noexcept : err_(ex_)
{ /* here make the message by the code */ }
constants::error_type code() const { return err_ ; }

#ifndef MY_RAISE
#ifdef _DEBUG
#define MY_RAISE(x) _invoke_watson(_CRT_WIDE(#x), __FUNCTIONW__, __FILEW__, __LINE__, 0)
#else // _DEBUG
#define MY_RAISE(x) _invoke_watson(nullptr, nullptr, nullptr, 0, 0)
#endif // _DEBUG
#endif // ! DBJ_RAISE

// we raise the SEH from here
// and through calling _invoke_watson
[[noreturn]] void raise() const {
DBJ_RAISE(*this) ;
}

} ; // eof error
```
We will always use the `MY_THROW` macro
```cpp
#if _HAS_EXCEPTIONS == 0
MY_THROW(x) x.raise() ;
#else
MY_THROW(x) throw x ;
#endif
```
Lastly, there is always a function that does the raise, and does not return. A level of indirection to improve the change-ability of the design always exist:
```cpp
[[noreturn]] inline void __cdecl
error_throw (const constants::error_type code_)
{
MY_THROW( error(code_) ) ;
}
} // eof my ns
```
To enjoy the SEH benefits, your Windows main should always be "SEH enabled"
```cpp
// The "Standard" main()
// build without /EHsc or any other /EH
// or use the /kernel switch
extern "C" int main (int argc, char ** argv)
{
__try
{
__try {
my::error_throw( constants::error_type::error_syntax ) ;
}
__finally {
// will be always visited
}
}
__except ( 1 /* 1 == EXCEPTION_EXECUTE_HANDLER */ )
{
// your code here
}
return 0 ;
}
```
That will always work c++ exception or no C++ exceptions. In case you want C++ exceptions you can not mix that in the same function, so you just call some entry point into your standard C++ app from the `main()` above.

If you build with `/EHsc` your app will be: c++ exceptions **and** SEH enabled. If built without, you will be intrinsic SEH enabled. SEH intrinsics are in `<excpt.h>`

> In Windows C/C++, SEH is always there

### 1.2.3. COM, C++ and /kernel builds

["Compiler COM Support"](https://docs.microsoft.com/en-us/cpp/cpp/compiler-com-support?redirectedfrom=MSDN&view=vs-2019) was designed, implemented and tested to also use C++ exceptions. Not SEH.[MSFT COM](https://en.wikipedia.org/wiki/Component_Object_Model) predates C++ standardizations. Just like SEH does.

In 2020 Q4, if and when attempting C++ `/kernel` or no `/EH` builds, C++ exceptions are replaced with SEH.

You need to know right now [things are happening in there "by accident"](https://github.com/MicrosoftDocs/cpp-docs/issues/2494#issuecomment-701200395). Pleas do not rely on `<comdef.h>` `/kernel` or not `/EH` combination until further notice.

"Compiler COM Support" and SEH is accidental combination that works 2020 Q4.

MSFT ["Compiler COM Support"](https://docs.microsoft.com/en-us/cpp/cpp/compiler-com-support?redirectedfrom=MSDN&view=vs-2019) I do like, it is C++, it is simple and it "just works". But these days it is meeting the not-so-simple standard C++, and WG 21

Speed up integer kernel loops by 10-25% when you avoid Standard C++

The "restrict" keyword has been a long time coming to C++. One of the reasons Fortran can be faster than C/C++ in the normal case is because its language definition assumes no aliasing. Standard C++ doesn't even have that option available. Starting with Blitz++, peeps started writing optimizations with templates outside of the compiler. I'm not sure this is yet another case of C++ getting the defaults wrong but having the option to note the lack of aliasing would be useful.

Here are some timings in microseconds from my ye olde Haswell laptop showing some utility for one particular kernel (100k repeats for the distribution):

||||normal|||restrict||Is normal|
|:-|:-|:-|:-|:-|:-|:-|:-|:-|
|data type|vector size|10%|median|90%|10%|median|90%|slower?|
||||||||||
|i32|64|.018|.020|.039|.015|.016|.031|25%|
||256|.065|.076|.145|.058|.060|.111|26%|
||4096|1.304|1.432|2.163|1.177|1.241|1.846|15%|
||65536|25.474|28.758|38.147|22.467|23.238|25.523|24%|
||||||||||
|f32|64|.070|.077|.154|.066|.070|.129|9%|
||256|.290|.291|.624|.288|.289|.569|1%|
||4096|4.494|4.717|5.341|4.337|4.473|5.384|5%|
||65536|84.910|92.715|149.789|73.627|82.019|116.101|13%|
||||||||||
|i8|4096|.638|.684|.957|.556|.563|.759|21%|
|i16|4096|.663|.695|1.055|.599|.618|1.123|13%|
|i64|4096|3.010|3.435|4.915|2.755|2.879|4.045|19%|
|f64|4096|4.442|4.495|5.483|4.344|4.428|4.974|2%|
|i128|4096|14.504|15.743|23.147|13.674|15.474|22.099|2%|

The example kernel used here looks like this:

template<i64 N>
R foo(pT restrict a, pT restrict b, pT restrict c) {
R result{0};
for( auto i = 0; i<N; ++i) {
ai = aib[i] + c[i];
b[i] = c[i]bi + ai;
result += ai + bi;
}
return result;
}

Assembly generation here FWIW: https://godbolt.org/z/v9q5sdcx5

The most recent standard proposal that may help regards disjoint memory: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1296r0.pdf

Previous papers looked at activating the C restrict keyword for C++, such as: https://www.open-std.org/JTC1/sc22/wg21/docs/papers/2014/n3988.pdf

Most major compilers support a "restrict" qualifier, such as __restrict__ or __restrict, etc: gcc, msvc, intel(edg), hp(edg), ibm, nvcc, ti, clang.

YMMV, but think about using restrict for your performance-sensitive code if it is safe to do so. No mainstream compilers don't have support for a reason.

\--Matt.

https://redd.it/mmuukz
@r_cpp

try {
auto task = whenall(
// write chunk of data into one end repeatedly
pipewrite(wPipe, databuffer, scheduler, stopWrite.gettoken()),
// read the data 1 byte at a time from the other end
sequence(
// read for some time before starting measurement
// this is done to reduce startup effects
pipebench(rPipe, buffer, scheduler, WARMUPDURATION, data, reps, offset),
// reset measurements to exclude warmup
justfrom(& {
// restart reps and keep offset in data
offset = reps%sizeof(data);
reps = 0;
printf("warmup completed!\n");
// exclude the warmup time
startTime = endTime = std::chrono::highresolutionclock::now();
}),
// do more reads and measure how many reads occur
pipebench(rPipe, buffer, scheduler, BENCHMARKDURATION, data, reps, offset),
// report results
justfrom([&] {
endTime = std::chrono::highresolutionclock::now();
printf("benchmark completed!\n");
auto ms = std::chrono::durationcast<std::chrono::milliseconds>(
endTime - startTime)
.count();
auto ns = std::chrono::durationcast<std::chrono::nanoseconds>(
endTime - startTime)
.count();
double reads = 1000000000.0 * reps / ns;
std::cout
<< "completed in "
<< ms << " ms, "
<< ns << "ns, "
<< reps << "ops\n";
std::cout
<< "stats - "
<< reads << "reads, "
<< ns/reps << "ns-per-op, "
<< reps/ms << "ops-per-ms\n";
stopWrite.requeststop();
})
)
);
syncwait(std::move(task));
} catch (const std::systemerror& se) {
std::printf("asyncreadsome systemerror: [%s], [%s]\n", se.code().message().cstr(), se.what());
} catch (const std::exception& ex) {
std::printf("asyncreadsome exception: %s\n", ex.what());
}
return 0;
}

#else // !UNIFEXNOEPOLL
#include <cstdio>
int main() {
printf("epoll support not found\n");
}
#endif // !UNIFEXNOEPOLL

https://redd.it/q0gzkz
@r_cpp