On Tuesday, 20 July 2021 at 02:58:50 UTC, H. S. Teoh wrote:
On Tue, Jul 20, 2021 at 02:39:58AM +, seany via
Digitalmars-d-learn wrote:
> [...]
[...]
[...]
Logically speaking, the size of the work unit should not change
the semantics of the loop. That's just an implementation detail
On Tue, Jul 20, 2021 at 02:39:58AM +, seany via Digitalmars-d-learn wrote:
> On Tuesday, 20 July 2021 at 02:31:14 UTC, H. S. Teoh wrote:
> > On Tue, Jul 20, 2021 at 01:07:22AM +, seany via Digitalmars-d-learn
> > wrote:
> > > On Tuesday, 20 July 2021 at 00:37:56 UTC, H. S. Teoh wrote:
> >
On Tuesday, 20 July 2021 at 02:31:14 UTC, H. S. Teoh wrote:
On Tue, Jul 20, 2021 at 01:07:22AM +, seany via
Digitalmars-d-learn wrote:
On Tuesday, 20 July 2021 at 00:37:56 UTC, H. S. Teoh wrote:
> [...]
Ok, therefore it means that, if at `j = 13 `i use a continue,
then the thread where I
On Tue, Jul 20, 2021 at 01:07:22AM +, seany via Digitalmars-d-learn wrote:
> On Tuesday, 20 July 2021 at 00:37:56 UTC, H. S. Teoh wrote:
> > On Tue, Jul 20, 2021 at 12:07:10AM +, seany via Digitalmars-d-learn
> > wrote:
> > > [...]
> > [...]
> >
> > I didn't test this, but I'm pretty sure
On Tuesday, 20 July 2021 at 00:37:56 UTC, H. S. Teoh wrote:
On Tue, Jul 20, 2021 at 12:07:10AM +, seany via
Digitalmars-d-learn wrote:
[...]
[...]
I didn't test this, but I'm pretty sure `continue` inside a
parallel foreach loop simply terminates that iteration early; I
don't think it
On Tue, Jul 20, 2021 at 12:07:10AM +, seany via Digitalmars-d-learn wrote:
> Consider :
>
> for (int i = 0; i < max_value_of_i; i++) {
> foreach ( j, dummyVar; myTaskPool.parallel(array_to_get_j_from,
> my_workunitSize) {
>
> if ( boolean_function(i,j) ) continue;
>
Consider :
for (int i = 0; i < max_value_of_i; i++) {
foreach ( j, dummyVar;
myTaskPool.parallel(array_to_get_j_from, my_workunitSize) {
if ( boolean_function(i,j) ) continue;
double d = expensiveFunction(i,j);
// ... stuff ...
}
}
The real structure is different from the documented one. The
problem was the difference in the size of the structures. The
issue has been resolved.
```
extern(C)
struct statx_t {
// 0x00
uint stx_mask;
uint stx_blksize;
ulong stx_attributes;
// 0x10
uint stx_nlink;
uint
On Monday, 19 July 2021 at 17:20:21 UTC, kinke wrote:
You know that asm is to be avoided whenever possible, but
unfortunately, AFAIK intel-intrinsics doesn't fit the usual
'don't worry, simply compile all your code with an appropriate
-mattr/-mcpu option' recommendation, as it employs
I wrote statx (Linux system call) wrapper and program to check.
```
import std.string, std.stdio;
import core.sys.posix.fcntl;
extern(C)
struct timestamp_t {
long tv_sec;
uint tv_nsec;
}
extern(C)
struct statx_t {
uint stx_mask;
uint stx_blksize;
ulong stx_attributes;
uint
On Monday, 19 July 2021 at 14:37:01 UTC, jmh530 wrote:
glpk can handle mixed integer programming problems. Since it is
a C library, it would be pretty easy to call from D but I don't
see a binding or anything available. I would try to call it
with dpp and if that doesn't work then something
On Monday, 19 July 2021 at 17:20:21 UTC, kinke wrote:
Compiling with `-O -mtriple=i686-linux-gnu -mcpu=i686` (=> no
SSE2 by default) shows that the inlined version inside
`wrapper()` is the mega slow one, so the extra instructions
aren't applied transitively unfortunately.
Erm sorry should
On Monday, 19 July 2021 at 16:44:35 UTC, Guillaume Piolat wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
This workaround is actually missing the clobber constraint for
`%2`, which might be problematic after inlining.
An unrelated other issue with asm/__asm is that it doesn't
On Monday, 19 July 2021 at 16:05:57 UTC, kinke wrote:
On Monday, 19 July 2021 at 11:16:49 UTC, Tejas wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
This workaround is actually missing the clobber constraint for
`%2`, which might be problematic after inlining.
An unrelated other issue with asm/__asm is that it doesn't follow
consistent VEX encoding compared to normal compiler output.
On Monday, 19 July 2021 at 16:05:57 UTC, kinke wrote:
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near future...
I'm not aware of any of that; who'd be 'they'? GCC breaking
their syntax is IMO unimaginable. LDC supporting it
On Monday, 19 July 2021 at 11:39:02 UTC, Basile B. wrote:
And what about the `extern(C)` issue ? Does it make sense to be
used when the parameters are int4 ?
The original inline asm was buggy and only 'worked' by accident
(not using the 2nd input operand at all...) with extern(D)
reversed
On Monday, 19 July 2021 at 11:16:49 UTC, Tejas wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near future...
I'm not aware of any of that; who'd be 'they'?
On Monday, 19 July 2021 at 12:39:41 UTC, Arredondo wrote:
Is there an integer linear programming/discrete optimization
library for D? an equivalent to the JuMP library for Julia for
instance. Doesn't have to be too big, I really only need to
solve a few smallish binary linear systems, but
On Monday, 19 July 2021 at 03:52:51 UTC, SealabJaster wrote:
On Monday, 19 July 2021 at 03:51:02 UTC, SealabJaster wrote:
...
There's also Ali Cehreli's book, which is excellent.
I stepped into D alongside Andrei and Ali's books. Ali's one I
was aware it existed but I didn't start to read
Is there an integer linear programming/discrete optimization
library for D? an equivalent to the JuMP library for Julia for
instance. Doesn't have to be too big, I really only need to solve
a few smallish binary linear systems, but taking a quick look at
code.dlang I did not immediately find
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote:
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
- **=x** says "returns in whatever is has to"
- **x** (1) is the constraint for input `a`, which is passed
as operand **$0**
- **x** (2) is the constraint for input `b`, which is
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember Johan
saying they will break compatibilty in the near future...
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote:
What works reliably is a manual mov:
```
int4 _mm_add_int4(int4 a, int4 b)
{
int4 r;
asm { "paddd %1, %2; movdqa %2, %0" : "=x" (r) : "x" (a),
"x" (b); }
return r;
}
```
This workaround is actually missing the clobber
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote:
What works reliably is a manual mov:
OK that's what I feared. It's very easy to get that wrong.
Thankfully I haven't used __asm a lot.
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
- **=x** says "returns in whatever is has to"
- **x** (1) is the constraint for input `a`, which is passed as
operand **$0**
- **x** (2) is the constraint for input `b`, which is passed as
operand **$1**
$0 is actually the output
On Saturday, 17 July 2021 at 04:13:53 UTC, btiffin wrote:
On Friday, 16 July 2021 at 20:04:21 UTC, jfondren wrote:
On Friday, 16 July 2021 at 19:25:32 UTC, btiffin wrote:
Using gdc-11 and Seamonkey.
https://rosettacode.org/wiki/Hello_world/Web_server#D does
not compile.
The `while` as you
27 matches
Mail list logo
