while trying to create an object oriented OpenACC implementation I stumbled upon this question.
From there I took the code provided by #mat-colgrove at the GTC15 (code available at http://www.pgroup.com/lit/samples/gtc15_S5233.tar).
Since I am interested how to use objects to manage data on with OpenACC I posted another question.
I was quite impressed by the ease of the OpenACCArray::swap function, so I created a small example to test it (see gist).
First I tried to just swap and hope that it is sufficient to swap the pointers on the host, but this ends in a fatal memory error. (presumably because the size and capacity members are not updated on the device)
A safer approach, that I assumed to work is to update the host, swap arrays and update device. This runs but creates wrong results.
I am compiling for nvidia accelerators.
Looks like this is my fault since I didn't test the swap routine.
The problem here is while the code is swapping the data on the host, the device copy of the objects still point to the old array. The fix is to re-attach (i.e. set the object's device pointers to the correct arrays) the lists.
void swap(OpenACCArray<type>& x)
{
type* tmp_list = list;
int tmp_size = _size;
int tmp_capacity = _capacity;
list = x.list;
_size = x._size;
_capacity = x._capacity;
x.list = tmp_list;
x._size = tmp_size;
x._capacity = tmp_capacity;
#ifdef _OPENACC
#pragma acc update device(_size,_capacity,x._size,x._capacity)
acc_attach((void**)&list);
acc_attach((void**)&x.list);
#endif
}
"acc_attach" is a PGI extension that hopefully will be adopted in the OpenACC 3.0 standard.
Thanks for trying things out and let me know if you encounter other issues.
- Mat
Related
I have an issue with some unit test code which is giving different results for every execution.
I tracked it back to libsoxr (0.1.3) and discovered that is its down to the dithering option:
That is, if soxr_create() is invoked with:
soxr_io_spec_t soxIoSpec = soxr_io_spec(SOXR_INT16_I, SOXR_INT16_I);
sxIoSpec.flags |= SOXR_NO_DITHER;
The output of soxr_process() is deterministic.
But without adding the SOXR_NO_DITHER flag the output is slightly different for each execution.
There is another thing about the library which surprises me here.
soxr_oneshot() does not suffer from this problem (the non-determinism).
What is going on here?
Looking into the code I see that in soxr.c the dither uses a pseudo random number generator
but the seed is an implementation detail generated from the time by:
p->seed = (unsigned long)time(0) ^ (unsigned long)(size_t)p;
It does not seem to be exposed by the library thus preventing you from setting a particular seed which you could otherwise do tog et the same result each time the test is run.
I have suggested a minor enhanced to the API like the below to facilitate this,
though someone with more knowledge of the library may be able to suggest a better way.
In Soxr.h add:
typedef unsigned long soxr_seed_t;
// set or retrieve the random seed used by the dithering function
void soxr_setseed(soxr_t resampler, soxr_seed_t new_seed);
soxr_seed_t soxr_getseed(soxr_t* resampler);
In Soxr.c add:
void soxr_setseed(soxr_t resampler, soxr_seed_t new_seed)
{
resampler->seed = new_seed;
}
soxr_seed_t soxr_getseed(soxr_t resampler)
{
return resampler->seed;
}
One thing about the library which still surprises me here is that
soxr_oneshot() does not suffer from this problem (the non-determinism).
I can’t see how the seed is fixed or SOXR_NO_DITHER set by the internal call to soxr_create().
I have obviously missed something here which someone with more knowledge of the library may be able to explain.
I'm aware of many similar questions on this site. I really like the solution mention in the following link:
https://stackoverflow.com/a/25021520/884553
with some modification, you can include text file at compile time, for example:
constexpr const char* s =
#include "file.txt"
BUT to make this work you have to add string literal prefix and suffix to your original file, for example
R"(
This is the original content,
and I don't want this file to be modified. but i
don't know how to do it.
)";
My question is: is there a way to make this work but not modifying file.txt?
(I know I can use command line tools to make a copy, prepend and append to the copy, remove the copy after compile. I'm looking for a more elegant solution than this. hopefully no need of other tools)
Here's what I've tried (but not working):
#include <iostream>
int main() {
constexpr const char* s =
#include "bra.txt" // R"(
#include "file.txt" //original file without R"( and )";
#include "ket.txt" // )";
std::cout << s << "\n";
return 0;
}
/opt/gcc8/bin/g++ -std=c++1z a.cpp
In file included from a.cpp:5:
bra.txt:1:1: error: unterminated raw string
R"(
^
a.cpp: In function ‘int main()’:
a.cpp:4:27: error: expected primary-expression at end of input
constexpr const char* s =
^
a.cpp:4:27: error: expected ‘}’ at end of input
a.cpp:3:12: note: to match this ‘{’
int main() {
^
No, this cannot be done.
There is a c++2a proposal to allow inclusion of such resources at compile time called std::embed.
The motivation part of ths p1040r1 proposal:
Motivation
Every C and C++ programmer -- at some point -- attempts to #include large chunks of non-C++ data into their code. Of course, #include expects the format of the data to be source code, and thusly the program fails with spectacular lexer errors. Thusly, many different tools and practices were adapted to handle this, as far back as 1995 with the xxd tool. Many industries need such functionality, including (but hardly limited to):
Financial Development
representing coefficients and numeric constants for performance-critical algorithms;
Game Development
assets that do not change at runtime, such as icons, fixed textures and other data
Shader and scripting code;
Embedded Development
storing large chunks of binary, such as firmware, in a well-compressed format
placing data in memory on chips and systems that do not have an operating system or file system;
Application Development
compressed binary blobs representing data
non-C++ script code that is not changed at runtime; and
Server Development
configuration parameters which are known at build-time and are baked in to set limits and give compile-time information to tweak performance under certain loads
SSL/TLS Certificates hard-coded into your executable (requiring a rebuild and potential authorization before deploying new certificates).
In the pursuit of this goal, these tools have proven to have inadequacies and contribute poorly to the C++ development cycle as it continues to scale up for larger and better low-end devices and high-performance machines, bogging developers down with menial build tasks and trying to cover-up disappointing differences between platforms.
MongoDB has been kind enough to share some of their code below. Other companies have had their example code anonymized or simply not included directly out of shame for the things they need to do to support their workflows. The author thanks MongoDB for their courage and their support for std::embed.
The request for some form of #include_string or similar dates back quite a long time, with one of the oldest stack overflow questions asked-and-answered about it dating back nearly 10 years. Predating even that is a plethora of mailing list posts and forum posts asking how to get script code and other things that are not likely to change into the binary.
This paper proposes <embed> to make this process much more efficient, portable, and streamlined. Here’s an example of the ideal:
#include <embed>
int main (int, char*[]) {
constexpr std::span<const std::byte> fxaa_binary = std::embed( "fxaa.spirv" );
// assert this is a SPIRV file, compile-time
static_assert( fxaa_binary[0] == 0x03 && fxaa_binary[1] == 0x02
&& fxaa_binary[2] == 0x23 && fxaa_binary[3] == 0x07
, "given wrong SPIRV data, check rebuild or check the binaries!" )
auto context = make_vulkan_context();
// data kept around and made available for binary
// to use at runtime
auto fxaa_shader = make_shader( context, fxaa_binary );
for (;;) {
// ...
// and we’re off!
// ...
}
return 0;
}
I have a metal 2 shader on macOS 10.12 that I am trying to pass an array of int into, but XCode is giving me a compile-time error Unknown type name 'array'. Here is the code I am using:
kernel void computeMandelbrot(texture2d<float, access::write> output [[texture(0)]], constant int &maxIterations [[buffer(1)]], const array<int, 10> &hist [[buffer(2)]], uint2 gid [[thread_position_in_grid]]) {
// Compute Mandelbrot
}
I have also tried using the keyword constant instead of const but then I also get an error of Parameter may not be qualified with an address space. I had read that arrays of textures were not supported in metal on macOS, but I was not sure if this appled to arrays of other types. Any help would be greatly appriciated, thank you!
A few things:
Metal 2 is not available in macOS 10.12. It is new with 10.13.
array is only usable with textures and samplers.
array is not available on macOS <=10.12. It's available on macOS 10.13+ with Metal 2.
You can declare your parameter as constant int *hist [[buffer(2)]]. It won't have an explicit length, but just limit what elements you reference.
Edit: I was wrong about array only being usable with textures and samplers. The spec suggests that to be the case by introducing it in a section titled "Arrays of Textures and Samplers" and only illustrating its use that way, but the template class itself seems generically useful.
However, until Metal 2, it's not available on macOS. In other words, it's only available on macOS 10.13+.
Now that we've reached Swift 2.0, I've decided to convert my, as yet unfinished, OS X app to Swift. Making progress but I've run into some issues with using termios and could use some clarification and advice.
The termios struct is treated as a struct in Swift, no surprise there, but what is surprising is that the array of control characters in the struct is now a tuple. I was expecting it to just be an array. As you might imagine it took me a while to figure this out. Working in a Playground if I do:
var settings:termios = termios()
print(settings)
then I get the correct details printed for the struct.
In Obj-C to set the control characters you would use, say,
cfmakeraw(&settings);
settings.c_cc[VMIN] = 1;
where VMIN is a #define equal to 16 in termios.h. In Swift I have to do
cfmakeraw(&settings)
settings.c_cc.16 = 1
which works, but is a bit more opaque. I would prefer to use something along the lines of
settings.c_cc.vim = 1
instead, but can't seem to find any documentation describing the Swift "version" of termios. Does anyone know if the tuple has pre-assigned names for it's elements, or if not, is there a way to assign names after the fact? Should I just create my own tuple with named elements and then assign it to settings.c_cc?
Interestingly, despite the fact that pre-processor directives are not supposed to work in Swift, if I do
print(VMIN)
print(VTIME)
then the correct values are printed and no compiler errors are produced. I'd be interested in any clarification or comments on that. Is it a bug?
The remaining issues have to do with further configuration of the termios.
The definition of cfsetspeed is given as
func cfsetspeed(_: UnsafeMutablePointer<termios>, _: speed_t) -> Int32
and speed_t is typedef'ed as an unsigned long. In Obj-C we'd do
cfsetspeed(&settings, B38400);
but since B38400 is a #define in termios.h we can no longer do that. Has Apple set up replacement global constants for things like this in Swift, and if so, can anyone tell me where they are documented. The alternative seems to be to just plug in the raw values and lose readability, or to create my own versions of the constants previously defined in termios.h. I'm happy to go that route if there isn't a better choice.
Let's start with your second problem, which is easier to solve.
B38400 is available in Swift, it just has the wrong type.
So you have to convert it explicitly:
var settings = termios()
cfsetspeed(&settings, speed_t(B38400))
Your first problem has no "nice" solution that I know of.
Fixed sized arrays are imported to Swift as tuples, and – as far as I know – you cannot address a tuple element with a variable.
However,Swift preserves the memory layout of structures imported from C, as
confirmed by Apple engineer Joe Groff:. Therefore you can take the address of the tuple and “rebind” it to a pointer to the element type:
var settings = termios()
withUnsafeMutablePointer(to: &settings.c_cc) { (tuplePtr) -> Void in
tuplePtr.withMemoryRebound(to: cc_t.self, capacity: MemoryLayout.size(ofValue: settings.c_cc)) {
$0[Int(VMIN)] = 1
}
}
(Code updated for Swift 4+.)
What's the purpose of ANYSIZE_ARRAY, located in WinNT.h?
I see an MSDN blog post about it from 2004 but it doesn't make sense to me.
I assume you are talking about this blog post.
It is often used when a variable-sized (unknown at compile time) array is part of a struct:
typedef struct {
int CommonFlags
int CountOfThings;
THING Things[ANYSIZE_ARRAY]; //Things[1];
} THINGSANDFLAGS;
To work with those structures you often first call the desired API to get the size of the data, then allocate a block of memory big enough and finally call the same API again so it can fill in the data...
From this page:
In C, a variable-size array is declared as a[1] or a[ANYSIZE_ARRAY], where ANYSIZE_ARRAY is defined as 1. Then it is used as if it were bigger.