Re: Simple parallel foreach and summation/reduction
On Thursday, 20 September 2018 at 05:34:42 UTC, Chris Katko wrote: All I want to do is loop from 0 to [constant] with a for or foreach, and have it split up across however many cores I have. You're looking at std.parallelism.TaskPool, especially the amap and reduce functions. Should do pretty much exactly what you're asking. auto taskpool = new TaskPool(); taskpool.reduce!((a, b) => a + b)(iota(1_000_000_000_000L));
Simple parallel foreach and summation/reduction
All I want to do is loop from 0 to [constant] with a for or
foreach, and have it split up across however many cores I have.
ulong sum;
foreach(i; [0 to 1 trillion])
{
//flip some dice using
float die_value = uniform(0F,12F);
if(die_value > [constant]) sum++;
}
writeln("The sum is %d", sum);
However, there are two caveats.:
- One: I can't throw a range of values into an array and foreach
on that like many examples use. Because 1 trillion (counting from
zero) might be a little big for an array. (I'm using 1 trillion
to illustrate a specific bottleneck / problem form.)
- I want to merge the results at the end.
Which means I either need to use mutexes (BAD. NO. BOO. HISS.)
or each "thread" would need to know if it's separate, and then
store their sums in, say, a thread[#].sum variable and then once
all were completed, add those sums together.
I know this is an incredibly simple conceptual problem to solve.
So I feel like I'm missing some huge, obvious, answer for doing
it elegantly in D.
And this just occurred to me, if I had a trillion foreach, will
that make 1 trillion threads? What I want is, IIRC, what OpenMP
does. It divides up your range (blocks of sequential numbers) by
the number of threads. So domain of [1 to 1000] with ten threads
would become workloads on the indexes of [1-100], [101-200],
[201-300], and so on. for each CPU. They each get a 100 element
chunk.
So I guess foreach won't work here for that, will it? Hmmm...
> But again, conceptually this is simple: I have, say, 1
trillion sequential numbers. I want to assign a "block" (or
"range") to each CPU core. And since their math does not actually
interfer with each other, I can simply sum each core's results at
the end.
Thanks,
--Chris
Re: How to use math functions in dcompute?
On Wednesday, 19 September 2018 at 00:22:44 UTC, Nicholas Wilson wrote: On Wednesday, 19 September 2018 at 00:11:13 UTC, Nicholas Wilson wrote: On Tuesday, 18 September 2018 at 06:25:33 UTC, Sobaya wrote: On Tuesday, 18 September 2018 at 01:39:51 UTC, Nicholas Wilson wrote: On Tuesday, 18 September 2018 at 00:25:33 UTC, Sobaya wrote: I'm waiting for the update. How's your progress? I t appears I have broke SPIR-V completely somewhere along the line, I may release a v0.2 with out it, hopefully within the week. I declared like: pragma(LDC_intrinsic, "llvm.nvvm.cos.f32") T cos(T)(T val) if (__traits(isFloating, T)); It also doesn't work. pragma(LDC_intrinsic, "llvm.nvvm.cos.f#") // note the # in place of 32 T cos(T)(T val) if (__traits(isFloating, T)); (Just don't use real with it.) OR pragma(LDC_intrinsic, "llvm.nvvm.cos.f32") float cos(float val) And if they don't work, use pragma(LDC_intrinsic, "llvm.cos.f#") // note the # in place of 32 T cos(T)(T val) if (__traits(isFloating, T)); (Just don't use real with it.) "llvm.nvvm.cos.f#" and "llvm.nvvm.cos.f32" don't work. And when I use "llvm.cos.f#", Another error occurred in linking. LLVM ERROR: Cannot select: 0xe0d4798: f32 = fcos ConstantFP:f32<0.00e+00> 0xe0b9db0: f32 = ConstantFP<0.00e+00>
Re: Is it possible to translate this API's C headers?
On Tuesday, September 18, 2018 7:39:40 AM MDT Atila Neves via Digitalmars-d- learn wrote: > On Monday, 17 September 2018 at 19:13:06 UTC, Jonathan M Davis > > wrote: > > On Monday, September 17, 2018 7:43:21 AM MDT Kagamin via > > > > Digitalmars-d-learn wrote: > >> try dpp https://github.com/atilaneves/dpp > > > > Since according to Mike's post, it's C++ code, dpp wouldn't > > help, because it currently only supports C and not C++. > > > > - Jonathan M Davis > > It does C++ as well, just not all (or even close at this point) > of it. I doubt it'd work on any real C++ codebase right now, but > who knows. It definitely won't if any of the headers use the > standard library, which is likely to happen. Well, the repo claims that it currently only does C - hence why I said that it will only do C (though even if it partially supports C++, odds are it's not enough to matter unless you know what you're doing - which the OP clearly doesn't, since they don't know C/C++). > It turns out that parsing C++ is a lot of work. Who knew? :P Yeah... - Jonathan M Davis
Re: Manual delegates
On 2018-09-16 16:12, Guillaume Piolat wrote:
Anyone has any information about the ABI of delegates?
In particular how to call them with a particular "this"/frame pointer?
You can explicitly set the context pointer of a delegate using the
".ptr" property:
class Foo
{
void bar() { }
}
void main()
{
auto a = new Foo;
void delegate () dg;
dg.ptr = cast(void*) a;
dg.funcptr =
dg();
}
To solve a hairy problem I need a delegate with a synthesized frame
pointer.
https://dpaste.dzfl.pl/cf44417c98f9
The problem is that delegate forwarding seems to require GC closures. I
want manually-managed closures.
--
/Jacob Carlborg
Re: Pass 'this' as reference
On Saturday, 15 September 2018 at 20:13:51 UTC, Jonathan M Davis wrote: On Saturday, September 15, 2018 11:44:05 AM MDT Jan via Digitalmars-d-learn wrote: [...] No. variables are _always_ lvalues. An lvalue is an object which is addressable and which can therefore be assigned a value (ignoring issues of constness). The name comes from the fact that lvalues are allowed on the left-hand side of an assignment operation, whereas rvalues are only allowed on the right. e.g. [...] Many thanks Jonathan! :)
Re: BetterC + Windows + setjmp longjmp
On Wednesday, 19 September 2018 at 11:12:41 UTC, Diederik de Groot wrote: On Wednesday, 19 September 2018 at 11:06:23 UTC, Diederik de Groot wrote: On Tuesday, 18 September 2018 at 19:45:18 UTC, SrMordred wrote: Only the exact size of the jmp_buf is important (not the details about the content). We only call a function with it, we never look inside. I don't own any windows machines so had to use these references (and could not test anything): - WinSDK10: goo.gl/m9DjZt - MARS: goo.gl/Qoc6g2 Code above does not yet cover the Mars case, but the i386 sizes should be the same. Please Note: setjmp/longjmp should only be used in "@system + @nogc + nothrow / -betterC" code. g++ and clang give me sizeof = 256. dmc give me 64. I tried all this sizes and other, but still crashes.
Re: BetterC + Windows + setjmp longjmp
On Wednesday, 19 September 2018 at 11:06:23 UTC, Diederik de Groot wrote: On Tuesday, 18 September 2018 at 19:45:18 UTC, SrMordred wrote: Only the exact size of the jmp_buf is important (not the details about the content). We only call a function with it, we never look inside. I don't own any windows machines so had to use these references (and could not test anything): - WinSDK10: goo.gl/m9DjZt - MARS: goo.gl/Qoc6g2 Code above does not yet cover the Mars case, but the i386 sizes should be the same. Please Note: setjmp/longjmp should only be used in "@system + @nogc + nothrow / -betterC" code.
Re: BetterC + Windows + setjmp longjmp
On Tuesday, 18 September 2018 at 19:45:18 UTC, SrMordred wrote:
On Tuesday, 18 September 2018 at 03:09:18 UTC, Mike Parker
wrote:
On Tuesday, 18 September 2018 at 00:24:23 UTC, SrMordred wrote:
Yes, i'm using signal(SIGSEGV, sigfn_t func), it catches
correctly, but end the execution after.
I find the alternatives of setjmp/longjmp and sigaction, but
none are avaliable on windows afaik.
setjmp/longjmp are available on windows (image loaders using
libpng, lua, quake3, and lots of old C code make use of them):
https://msdn.microsoft.com/en-us/library/xe7acxfb.aspx?f=255=-2147217396
https://msdn.microsoft.com/en-us/library/3ye15wsy.aspx
You can declare the functions in your own code and they should
link just fine. It would be helpful if you also submit a PR to
add them to DRuntime for Windows.
As for sigaction, a quick search suggests it isn't available
(and it doesn't show up in MSDN):
https://stackoverflow.com/questions/32389905/sigaction-and-porting-linux-code-to-windows
I think this may be going beyond my knowledge ;/
(Trying to follow setjmp.h, don´t have experience doing this)
enum _SIGSET_NWORDS = (1024 / (8 * (ulong.sizeof)));
struct __sigset_t
{
ulong[_SIGSET_NWORDS] __val;
}
struct __jmp_buf_tag
{
long[8] __jmpbuf;
int __mask_was_saved;
__sigset_t __saved_mask;
};
alias __jmp_buf_tag[1] jmp_buf;
extern (C) @nogc nothrow int setjmp(ref jmp_buf) ;
extern (C) @nogc nothrow void longjmp(ref jmp_buf, int);
I think your definition should look more like this:
Notes:
- modulename using druntime path.
- Not 100% sure about all the sizes (lifted from winsdk10).
- long/c_long
- JBLEN or JBLEN+1
- Compatible with MARS setjmp.h x86 sizes
--
module core.sys.windows.setjmp;
extern (C):
@system:
nothrow:
@nogc:
private import core.sys.windows.config;
import core.stdc.signal;
version ( Windows ):
version( X86 )
{
enum _JBLEN 16
struct _jmp_buf { int[_JBLEN + 1] _ssjb; }
}
else version( X86_64)
{
enum _JBLEN 16
struct {
long[2] part; // c_long ?
} float128;
struct _jmp_buf { float128[_JBLEN] _sjb;
}
else version (AArch64)
{
enum _JBLEN 28
struct _jmp_buf { int[_JBLEN] _sjb; }
}
/*
else version (IA64)
{
enum _JBLEN 33
struct {
long _high;
long _low;
} float128;
struct _jmp_buf { float128[_JBLEN] _sjb;
}
*/
else
static assert(0, "Not implemented for platforms other than
X86, yet");
alias _jmp_buf[_JBLEN] jmp_buf;
int setjmp(ref jmp_buf);
void longjmp(ref jmp_buf, int);
Only the exact size of the jmp_buf is important (not the details
about the content). We only call a function with it, we never
look inside.
Re: Access to structures defined in C
On Wednesday, 19 September 2018 at 00:46:54 UTC, Joe wrote:
On Tuesday, 18 September 2018 at 13:47:50 UTC, Atila Neves
wrote:
Sorry, Atila, I got confused looking at my two cases. I should
have said "an array of ints", e.g.,
int yp[] = {2, 4, 0};
int yq[] = {10, 12, 0};
That makes more sense.
int *ys[] = {yp, yq, 0};
This isn't even valid C code.
It is, because C treats 'yp' as a pointer.
It wasn't with the definition of `yp` and `yq` you posted.
In D, I first declared these as
int[] yp = [2, 4];
int[] yq = [10, 12];
__gshared int*[] ys = [ , ];
D dynamic arrays are not equivalent to C arrays.
It's hard to see what you're trying to do with the code you
posted. Have you tried instead to use a tool to translate the
C headers?
At this point, I've translated everything, even the code above.
I had to use 'immutable(int [])' in the second and higher level
arrays like 'ys' so that they could refer to 'yp' and 'yq'
(without the address operators).
This would be the literal translation:
int[3] yp = [2, 4, 0];
int[3] yq = [10, 12, 0];
int*[3] ys;
shared static this() {
ys = [yp.ptr, yq.ptr, null];
}
However, I still would like to have a deeper understanding of
the "static variable yp cannot be read at compile time" error
messages which went away when I declared yp immutable.
I guess immutable makes everything known at compile-time? I
didn't even know that was a thing. In any case, the reason why
you got those error messages is because initialisation of global
variables in D happens at compile-time. If you want runtime
initialisation like in C++, you have to use static constructors
like in my code above.
