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 = &Foo.bar; 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&MSPPError=-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 = [ &yp, &yq ]; 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.