On Saturday, 26 June 2021 at 02:19:18 UTC, someone wrote:
What I like most of it is that it scales well for big and
complex apps while being really flexible ... and neat :)
If you pass each file to the compiler like in your script then
every naming convention becomes irrelevant because the co
On Monday, 21 June 2021 at 13:29:59 UTC, Steven Schveighoffer
wrote:
That being said, I strongly recommend just to name the file the
same as the module name.
Although you made it clear that you do not favor this use-case I
am really satisfied with your solution because, at least to me,
has
On Friday, 25 June 2021 at 17:05:41 UTC, Ola Fosheim Grøstad
wrote:
Yes, if you don't want to support weak pointers. I think you
need two counters if you want to enable the usage of weak
pointers.
I cannot imagine how weak pointers would work without an ugly
extra indirection layer. If we're
On Friday, 25 June 2021 at 20:22:24 UTC, Ola Fosheim Grøstad
wrote:
Hm. Not sure if I follow, I think we are talking about stuffing
bits into the counter and not the address?
Then I misunderstood. If it's a counter it should be fine.
But fat pointers are 16 bytes, so quite expensive.
Yes
On Friday, 25 June 2021 at 17:37:13 UTC, IGotD- wrote:
You cannot use the most significant bit as it will not work
with some 32-bit systems. Linux with a 3G kernel position for
example. Better to use the least significant bit as all
allocated memory is guaranteed to be aligned. Regardless this
On Friday, 25 June 2021 at 19:52:23 UTC, seany wrote:
On Friday, 25 June 2021 at 19:30:16 UTC, jfondren wrote:
On Friday, 25 June 2021 at 19:17:38 UTC, seany wrote:
If i use `parallel(...)`it runs.
If i use `prTaskPool.parallel(...`, then in the line : `auto
prTaskPool = new TaskPool(threadCo
On Friday, 25 June 2021 at 19:30:16 UTC, jfondren wrote:
On Friday, 25 June 2021 at 19:17:38 UTC, seany wrote:
If i use `parallel(...)`it runs.
If i use `prTaskPool.parallel(...`, then in the line : `auto
prTaskPool = new TaskPool(threadCount);` it hits the error.
Please help.
parallel() re
On Friday, 25 June 2021 at 19:17:38 UTC, seany wrote:
If i use `parallel(...)`it runs.
If i use `prTaskPool.parallel(...`, then in the line : `auto
prTaskPool = new TaskPool(threadCount);` it hits the error.
Please help.
parallel() reuses a single taskPool that's only established once.
Your
On Friday, 25 June 2021 at 16:37:44 UTC, seany wrote:
On Friday, 25 June 2021 at 16:37:06 UTC, seany wrote:
On Friday, 25 June 2021 at 15:50:37 UTC, seany wrote:
On Friday, 25 June 2021 at 15:16:30 UTC, jfondren wrote:
[...]
Try : (this
version)[https://github.com/naturalmechanics/mwp/tree/
On Friday, 25 June 2021 at 17:37:13 UTC, IGotD- wrote:
You cannot use the most significant bit as it will not work
with some 32-bit systems. Linux with a 3G kernel position for
example. Better to use the least significant bit as all
allocated memory is guaranteed to be aligned. Regardless thi
On Friday, 25 June 2021 at 07:17:20 UTC, kinke wrote:
Wrt. manual non-heap allocations (stack/data segment/emplace
etc.), you could e.g. reserve the most significant bit of the
counter to denote such instances and prevent them from being
free'd (and possibly finalization/destruction too; this w
On Friday, 25 June 2021 at 07:17:20 UTC, kinke wrote:
Wrt. manual non-heap allocations (stack/data segment/emplace
etc.), you could e.g. reserve the most significant bit of the
counter to denote such instances and prevent them from being
free'd (and possibly finalization/destruction too; this w
On Friday, 25 June 2021 at 07:01:31 UTC, kinke wrote:
Well AFAIK it's mandated by the language, so an RC scheme
replacing such allocations by heap ones seems like a definite
step backwards - it's a useful pattern, and as Stefan pointed
out, definitely in use. You could still stack-allocate but
On Friday, 25 June 2021 at 15:50:37 UTC, seany wrote:
On Friday, 25 June 2021 at 15:16:30 UTC, jfondren wrote:
On Friday, 25 June 2021 at 14:44:13 UTC, seany wrote:
This particular location does not cause segfault.
It is segfaulting down the line in a completely unrelated
location... Wait I w
On Friday, 25 June 2021 at 16:37:06 UTC, seany wrote:
On Friday, 25 June 2021 at 15:50:37 UTC, seany wrote:
On Friday, 25 June 2021 at 15:16:30 UTC, jfondren wrote:
[...]
Try : (this
version)[https://github.com/naturalmechanics/mwp/tree/nested-loops]
The goal is to parallelize : `calculate
On Friday, 25 June 2021 at 15:16:30 UTC, jfondren wrote:
On Friday, 25 June 2021 at 14:44:13 UTC, seany wrote:
This particular location does not cause segfault.
It is segfaulting down the line in a completely unrelated
location... Wait I will try to make a MWP.
[Here is MWP](https://github.c
On Friday, 25 June 2021 at 15:16:30 UTC, jfondren wrote:
I reckon that there's some other memory error and that the
parallelism is unrelated.
@safe:
```
source/AI.d(83,23): Error: cannot take address of local `rData`
in `@safe` function `main`
source/analysisEngine.d(560,20): Error: cannot ta
On Friday, 25 June 2021 at 14:44:13 UTC, seany wrote:
This particular location does not cause segfault.
It is segfaulting down the line in a completely unrelated
location... Wait I will try to make a MWP.
[Here is MWP](https://github.com/naturalmechanics/mwp).
Please compile with `dub build
On Friday, 25 June 2021 at 15:08:38 UTC, Ali Çehreli wrote:
On 6/25/21 7:21 AM, seany wrote:
> The code without the parallel foreach works fine. No segfault.
That's very common.
What I meant is, is the code written in a way to work safely in
a parallel foreach loop? (i.e. Is the code "indepen
On 6/25/21 7:21 AM, seany wrote:
> The code without the parallel foreach works fine. No segfault.
That's very common.
What I meant is, is the code written in a way to work safely in a
parallel foreach loop? (i.e. Is the code "independent"?) (But I assume
it is because it's been the common the
On Friday, 25 June 2021 at 14:22:25 UTC, seany wrote:
On Friday, 25 June 2021 at 14:13:14 UTC, jfondren wrote:
On Friday, 25 June 2021 at 13:53:17 UTC, seany wrote:
[...]
A self-contained and complete example would help a lot, but
the likely
problem with this code is that you're accessing pn
On Friday, 25 June 2021 at 14:13:14 UTC, jfondren wrote:
On Friday, 25 June 2021 at 13:53:17 UTC, seany wrote:
[...]
A self-contained and complete example would help a lot, but the
likely
problem with this code is that you're accessing pnts[y][x] in
the
loop, which makes the loop bodies no l
On Friday, 25 June 2021 at 14:10:52 UTC, Ali Çehreli wrote:
On 6/25/21 6:53 AM, seany wrote:
> [...]
workUnitSize)) {
> [...]
Performance is not guaranteed depending on many factors. For
example, inserting a writeln() call in the loop would make all
threads compete with each other fo
On Friday, 25 June 2021 at 13:53:17 UTC, seany wrote:
I tried this .
int[][] pnts ;
pnts.length = fld.length;
enum threadCount = 2;
auto prTaskPool = new TaskPool(threadCount);
scope (exit) {
On 6/25/21 6:53 AM, seany wrote:
> I tried this .
>
> int[][] pnts ;
> pnts.length = fld.length;
>
> enum threadCount = 2;
> auto prTaskPool = new TaskPool(threadCount);
>
> scope (exit) {
> prTaskPool.finish();
> }
>
>
On Friday, 25 June 2021 at 13:53:17 UTC, seany wrote:
On Thursday, 24 June 2021 at 21:19:19 UTC, Ali Çehreli wrote:
[...]
I tried this .
int[][] pnts ;
pnts.length = fld.length;
enum threadCount = 2;
auto prTaskPool = new TaskPo
On Thursday, 24 June 2021 at 21:19:19 UTC, Ali Çehreli wrote:
On 6/24/21 1:41 PM, seany wrote:
> Is there any way to control the number of CPU cores used in
> parallelization ?
Yes. You have to create a task pool explicitly:
import std.parallelism;
void main() {
enum threadCount = 2;
auto
On Friday, 25 June 2021 at 05:46:54 UTC, Utk wrote:
On Friday, 25 June 2021 at 03:27:24 UTC, jfondren wrote:
On Friday, 25 June 2021 at 02:55:50 UTC, Utk wrote:
Please help me to resolve this issue.
Try stracing your program to see exactly what it's doing
with the socket, and try std.socket's
Wrt. manual non-heap allocations (stack/data segment/emplace
etc.), you could e.g. reserve the most significant bit of the
counter to denote such instances and prevent them from being
free'd (and possibly finalization/destruction too; this would
need some more thought I suppose).
On Friday, 25 June 2021 at 06:09:17 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
Yes, class *refs* are always pointers. *scope* classes are
deprecated (I don't think I've ever seen one); with `scope c =
new Object`, you can have the compiler allocate a
30 matches
Mail list logo
