Visual Studio Linker Problem
I am working my way up to building NanoVG per my previous post. I am able to compile hello world using dmd2. I am running in cygwin because I understand bash way better than cmd.exe. I am unable to compile hello world using ldc2. I am interested in ldc because I am interested in compiling to different arch-es and I happen to be a FreeBSD guy which uses LLVM by default. I figure that what I learn in LDC under windows will be portable for me. I received this error: $ ldc2 hello.d Using Visual C++: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC LINK : fatal error LNK1104: cannot open file 'libucrt.lib' Error: `C:\Windows\system32\cmd.exe /s /c "C:\Users\jcw\Documents\Projects\Programming\dlang\ldc2-1.1.0-beta3-win64-msvc\bin\amd64.bat link.exe"` failed with status: 1104 The file "libucrt.lib" is found in several VS folders. I am sure that this is some path issue, but I'm not savvy on VisualStudio. I read some scary messages about this error in other parts of the forum from about a year ago. Hopefully the solution is easier than what I read in that thread. I see mention of a "vcvarsall.bat" file that might set my paths correctly, but this file is not found on my system. I see mention of a VCINSTALLDIR variable which is not set on my system. Regards, Jason C. Wells
Re: Speed of synchronized
Dne 17.10.2016 v 23:40 Christian Köstlin via Digitalmars-d-learn napsal(a): Could someone check the numbers on another OS-X machine? Unfortunately I only have one available. Thanks in advance! Can you try it on OSX with ldc compiler: dub run --build=release --compiler=ldc
Re: Speed of synchronized
On 17/10/16 14:44, Christian Köstlin wrote:
> On 17/10/16 14:09, Daniel Kozak via Digitalmars-d-learn wrote:
>> Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
>>> Hi,
>>>
>>> for an exercise I had to implement a thread safe counter.
>>> This is what I came up with:
>>>
>>>
>>> btw. I run the code with dub run --build=release
>>>
>>> Thanks in advance,
>>> Christian
>> So I have done some testing, on my pc:
>> Java result
>> counter.AtomicLongCounter@7ff5e7d8 expected: 200 got: 100 in: 83ms
>> counter.ThreadSafe2Counter@59b44e4b expected: 200 got: 100 in: 77ms
>> counter.ThreadSafe1Counter@2e5f6b4b expected: 200 got: 100 in:
>> 154ms
>> counter.ThreadUnsafeCounter@762b155d expected: 200 got: 730428 in: 13ms
>>
>> and my D results (code: http://dpaste.com/3QFXACY ):
>> snip.AtomicCounter: got: 100 expected: 100 in 77 ms and 783 μs
>> snip.ThreadSafe1Counter: got: 100 expected: 100 in 287 ms, 727
>> μs, and 3 hnsecs
>> snip.ThreadSafe2Counter: got: 100 expected: 100 in 281 ms, 117
>> μs, and 1 hnsec
>> snip.ThreadSafe3Counter: got: 100 expected: 100 in 158 ms, 480
>> μs, and 2 hnsecs
>> snip.ThreadUnsafeCounter: got: 100 expected: 100 in 6 ms, 682
>> μs, and 1 hnsec
>>
>> so atomic is same as in Java pthread_mutex is same speed as java
>> synchronized
>> D mutexes and D synchronized are almost same, I belive that if I could
>> setup same attrs as in pthread version it will be around 160ms too.
>>
>> Unsafe is almost same for D and java. Only java ReentrantLock seems to
>> work better. I believe there is some trick, so it will end up not using
>> mutexes in the end at all. For example consider this change in D code:
>>
>> void doIt(alias counter)() {
>> auto thg = new ThreadGroup();
>> for (int i=0; i> thg.create(!(counter));
>> }
>> thg.joinAll();
>> }
>>
>> change it to
>>
>> void doIt(alias counter)() {
>> auto thg = new ThreadGroup();
>> for (int i=0; i> auto tc = thg.create(!(counter));
>> tc.join();
>> }
>> }
>>
>> and results are:
>>
>> snip.AtomicCounter: got: 100 expected: 100 in 22 ms, 251 μs, and
>> 6 hnsecs
>> snip.ThreadSafe1Counter: got: 100 expected: 100 in 46 ms, 146
>> μs, and 3 hnsecs
>> snip.ThreadSafe2Counter: got: 100 expected: 100 in 44 ms, 961
>> μs, and 5 hnsecs
>> snip.ThreadSafe3Counter: got: 100 expected: 100 in 42 ms, 512
>> μs, and 8 hnsecs
>> snip.ThreadUnsafeCounter: got: 100 expected: 100 in 2 ms, 108
>> μs, and 5 hnsecs
>>
>>
>>
>>
>>
> thank you for looking into it.
> this seems to be quite good.
> I did expect something in those lines, but got the mentioned numbers on
> my os x macbook. perhaps its a os x glitch.
>
Thanks for the hint about the OS. I rerun the tests on a linux machine,
and there everything is fine!
linux dlang code:
app.AtomicCounter: got: 100 expected: 100 in 24 ms, 387 μs, and
3 hnsecs
app.ThreadSafe1Counter: got: 100 expected: 100 in 143 ms, 534
μs, and 9 hnsecs
app.ThreadSafe2Counter: got: 100 expected: 100 in 159 ms, 685
μs, and 1 hnsec
app.ThreadUnsafeCounter: got: 399937 expected: 100 in 9 ms and 556 μs
from example got: 156 ms, 198 μs, and 9 hnsecs
linux java code:
counter.CounterTest > testAtomicIntCounter STANDARD_OUT
counter.AtomicIntCounter@1f2a2347 expected: 100 got: 100 in:
29ms
counter.CounterTest > testAtomicLongCounter STANDARD_OUT
counter.AtomicLongCounter@675ad891 expected: 100 got: 100
in: 24ms
counter.CounterTest > testThreadSafe2Counter STANDARD_OUT
counter.ThreadSafe2Counter@3043c6d2 expected: 100 got: 100
in: 38ms
counter.CounterTest > testThreadSafeCounter STANDARD_OUT
counter.ThreadSafe1Counter@bac4ba3 expected: 100 got: 100
in: 145ms
counter.CounterTest > testThreadUnsafeCounter STANDARD_OUT
counter.ThreadUnsafeCounter@2fe82bf8 expected: 100 got: 433730
in: 9ms
Could someone check the numbers on another OS-X machine? Unfortunately I
only have one available.
Thanks in advance!
Re: Range violation with AAs
On Monday, 17 October 2016 at 19:10:54 UTC, Basile B. wrote:
Just a question, maybe off topic, does this work:
unittest
{
alias Key = string;
alias A = Array!int;
A[Key] x;
x["a"] = [0];
}
?
No, that works.
Thanks for your interest.
Re: About debugging (again)
On Monday, 17 October 2016 at 19:14:49 UTC, ANtlord wrote: On Monday, 17 October 2016 at 17:57:19 UTC, Martin Krejcirik wrote: On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: GDB 7.7.1 Use latest GDB, 7.10 has got much better D support. Tested on GDB 7.11.1. Same case :( redirect to ddemangle, that's its job.
Re: Programming in D by Ali Çehreli
On Monday, 17 October 2016 at 18:20:00 UTC, cym13 wrote: On Monday, 17 October 2016 at 18:10:01 UTC, vino wrote: [...] I don't see what you don't understand, you said it yourself: "neither the slice nor its elements can be modified". So you can't modify the elements of an immutable array. immSlice is an immutable array of which you are trying to modify an element. I would expect him to see the first error on `immSlice ~= 3;`.
Re: About debugging (again)
On Monday, 17 October 2016 at 17:53:30 UTC, Basile B. wrote: On Monday, 17 October 2016 at 17:46:05 UTC, Basile B. wrote: On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote: [...] Oh Sorry, I've forgotten about pointing technical parameters. Ubuntu 14.04 GDB 7.7.1 DMD64 D Compiler v2.071.1 redirect gdb's output to "ddemangle". This is what I do in the alpha version of Coedit's GDB commander, now in console mode I don't know the exact method. seems to be: gdb binary_name | ddemangle This makes gdb useless. I can't type any command. Propably can I use demangle by another way?
Re: About debugging (again)
On Monday, 17 October 2016 at 17:57:19 UTC, Martin Krejcirik wrote: On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: GDB 7.7.1 Use latest GDB, 7.10 has got much better D support. Tested on GDB 7.11.1. Same case :(
Re: Range violation with AAs
On Monday, 17 October 2016 at 17:43:19 UTC, Nordlöw wrote:
At
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d
I have an array container.
Everything works as expected in all unittests except for the
line at
https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649
that fails as
core.exception.RangeError@array_ex.d(1649): Range violation
and I have no clue why.
Is this a know problem with AA's with container-like structs as
value types?
The same unittest with another Array (i.e not the one from
phobos-next) gives the same error, so this confirms the other
answer saying that's may be a builtin AA bug.
Just a question, maybe off topic, does this work:
unittest
{
alias Key = string;
alias A = Array!int;
A[Key] x;
x["a"] = [0];
}
?
Re: Range violation with AAs
On 10/17/16 1:43 PM, Nordlöw wrote: At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. This seems like a bug. If RangeError is happening there, this means it's the AA that's complaining, not the Array!int. If this works properly with normal arrays, it means something is wrong in the way the AA behaves. Just another issue with our AA magic, I guess. -Steve
Re: Range violation with AAs
On 10/17/2016 11:40 AM, Nordlöw wrote: On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote: It still feels like x["a"] could return a proxy that could later add a new element and then apply ~= on it. (I haven't read the rest of your code to see whether you've already done that.) `Array` is in essence a C++-style array container (pointer, length, capacity) with C-style memory management. Nothing else. Have I done something wrong with ~= overloads perhaps? opOpAssign? (I need to stop guessing without coding. :) ) Ali
Re: Range violation with AAs
On Monday, 17 October 2016 at 18:38:30 UTC, Ali Çehreli wrote: As a consolation :) there are two unrelated issues in your code, which a new dmd warns about: Deprecation: Implicit string concatenation is deprecated 1) Probably a missing comma after `mark`: enum nonStateHTMLTags = [`b`, `i`, `strong`, `em`, `sub`, `sup`, `small`, `ins`, `del`, `mark` `code`, `kbd`, `samp`, `samp`, `var`, `pre`]; 2) Missng ~ here: `` ~ zexp ~ `` `` ~ Thanks, anyway! Fixed!
Re: Range violation with AAs
On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote: It still feels like x["a"] could return a proxy that could later add a new element and then apply ~= on it. (I haven't read the rest of your code to see whether you've already done that.) `Array` is in essence a C++-style array container (pointer, length, capacity) with C-style memory management. Nothing else. Have I done something wrong with ~= overloads perhaps?
Re: Range violation with AAs
On 10/17/2016 11:28 AM, Nordlöw wrote: On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote: Unfortunately, as far as I know, that's a privilege reserved for built-in AAs. But I *am* using a built-in AA. The problem happens when the value is an instance of an `Array!T`-container and not a slice `T[]`. Sorry... :/ As a consolation :) there are two unrelated issues in your code, which a new dmd warns about: Deprecation: Implicit string concatenation is deprecated 1) Probably a missing comma after `mark`: enum nonStateHTMLTags = [`b`, `i`, `strong`, `em`, `sub`, `sup`, `small`, `ins`, `del`, `mark` `code`, `kbd`, `samp`, `samp`, `var`, `pre`]; 2) Missng ~ here: `` ~ zexp ~ `` `` ~ Ali
Re: Range violation with AAs
On Monday, 17 October 2016 at 18:22:53 UTC, Ali Çehreli wrote: Unfortunately, as far as I know, that's a privilege reserved for built-in AAs. But I *am* using a built-in AA. The problem happens when the value is an instance of an `Array!T`-container and not a slice `T[]`.
Re: Range violation with AAs
On Monday, 17 October 2016 at 17:43:19 UTC, Nordlöw wrote: At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. Is this a know problem with AA's with container-like structs as value types? In other words alias Key = string; alias A = Array!int; A[Key] x; x["a"] ~= 42; // triggers violation fails. If I initialize the value prior to append as in alias Key = string; alias A = Array!int; A[Key] x; x["a"] = A.init; x["a"] ~= 42; // no violation the violation doesn't happen. And if I replace `Array!int` with `int[]` as in alias Key = string; alias A = int[]; A[Key] x; x["a"] ~= 42; it also doesn't happen.
Re: Range violation with AAs
On 10/17/2016 10:43 AM, Nordlöw wrote: At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. Is this a know problem with AA's with container-like structs as value types? So, x is a user-defined type and the line that fails is x["a"] ~= 42; Unfortunately, as far as I know, that's a privilege reserved for built-in AAs. It still feels like x["a"] could return a proxy that could later add a new element and then apply ~= on it. (I haven't read the rest of your code to see whether you've already done that.) Ali
Re: Programming in D by Ali Çehreli
On Monday, 17 October 2016 at 18:10:01 UTC, vino wrote:
Hi All,
As per the book named in the subject it states as below,so can
some one guide me what is wrong in the below code nor correct
if my understanding is wrong.
Page 154
immutable(int[]) specifies that neither the slice nor its
elements can be modified.
So which means that a element or a slice of any array can be
modified, but the below example code is not working.
import std.stdio;
void main() {
immutable(int[]) immSlice = [ 1, 2 ];
immSlice ~= 3;
immSlice[0] = 3; // Error's out at this point
immSlice.length = 1;
writeln(immSlice);
}
From,
Vino.B
I don't see what you don't understand, you said it yourself:
"neither the slice nor its elements can be modified". So you
can't modify the elements of an immutable array. immSlice is an
immutable array of which you are trying to modify an element.
Re: Programming in D by Ali Çehreli
On 10/17/2016 11:10 AM, vino wrote:
Hi All,
As per the book named in the subject it states as below,so can some one
guide me what is wrong in the below code nor correct if my understanding
is wrong.
Page 154
immutable(int[]) specifies that neither the slice nor its elements can
be modified.
So which means that a element or a slice of any array can be modified,
but the below example code is not working.
import std.stdio;
void main() {
immutable(int[]) immSlice = [ 1, 2 ];
immSlice ~= 3;
immSlice[0] = 3; // Error's out at this point
immSlice.length = 1;
writeln(immSlice);
}
From,
Vino.B
What version is your compiler? My version is DMD64 D Compiler v2.072.0-b2.
Trying the code with a recent compiler produces three compilation errors
for the following three lines
immSlice ~= 3;
immSlice[0] = 3;
immSlice.length = 1;
Error: cannot modify immutable expression immSlice
Error: cannot modify immutable expression immSlice[0]
Error: cannot modify immutable expression immSlice
Ali
Programming in D by Ali Çehreli
Hi All,
As per the book named in the subject it states as below,so can
some one guide me what is wrong in the below code nor correct if
my understanding is wrong.
Page 154
immutable(int[]) specifies that neither the slice nor its
elements can be modified.
So which means that a element or a slice of any array can be
modified, but the below example code is not working.
import std.stdio;
void main() {
immutable(int[]) immSlice = [ 1, 2 ];
immSlice ~= 3;
immSlice[0] = 3; // Error's out at this point
immSlice.length = 1;
writeln(immSlice);
}
From,
Vino.B
Re: About debugging (again)
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: GDB 7.7.1 Use latest GDB, 7.10 has got much better D support.
Re: About debugging (again)
On Monday, 17 October 2016 at 17:46:05 UTC, Basile B. wrote: On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote: [...] Oh Sorry, I've forgotten about pointing technical parameters. Ubuntu 14.04 GDB 7.7.1 DMD64 D Compiler v2.071.1 redirect gdb's output to "ddemangle". This is what I do in the alpha version of Coedit's GDB commander, now in console mode I don't know the exact method. seems to be: gdb binary_name | ddemangle
Re: About debugging (again)
On Monday, 17 October 2016 at 15:45:56 UTC, ANtlord wrote: On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote: Hello! I've met an issue related to debugging by GDB. Directly when I try to show call stack I get like this http://pastebin.com/kRFRqznq. How can I make name of methods more human readable? I see part of printed name matches to name of methods from code and I can suppose what method was called, but it would be great if I can debug application without any supposing. Sorry if my english is not clear. Oh Sorry, I've forgotten about pointing technical parameters. Ubuntu 14.04 GDB 7.7.1 DMD64 D Compiler v2.071.1 redirect gdb's output to "ddemangle". This is what I do in the alpha version of Coedit's GDB commander, now in console mode I don't know the exact method.
Range violation with AAs
At https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d I have an array container. Everything works as expected in all unittests except for the line at https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1649 that fails as core.exception.RangeError@array_ex.d(1649): Range violation and I have no clue why. Is this a know problem with AA's with container-like structs as value types?
Re: About debugging (again)
On Monday, 17 October 2016 at 15:43:32 UTC, ANtlord wrote: Hello! I've met an issue related to debugging by GDB. Directly when I try to show call stack I get like this http://pastebin.com/kRFRqznq. How can I make name of methods more human readable? I see part of printed name matches to name of methods from code and I can suppose what method was called, but it would be great if I can debug application without any supposing. Sorry if my english is not clear. Oh Sorry, I've forgotten about pointing technical parameters. Ubuntu 14.04 GDB 7.7.1 DMD64 D Compiler v2.071.1
About debugging (again)
Hello! I've met an issue related to debugging by GDB. Directly when I try to show call stack I get like this http://pastebin.com/kRFRqznq. How can I make name of methods more human readable? I see part of printed name matches to name of methods from code and I can suppose what method was called, but it would be great if I can debug application without any supposing. Sorry if my english is not clear.
Re: how to understand different attribute styles?
On 10/17/16 10:12 AM, timepp wrote: there is "@disable", using @ as prefix; there is "__gshared", using __ as prefix; there is also "align", not using prefix. I failed to summarize a rule here. Can anyone tell the underlined philosiphy? terms without adornments are keywords. They are used in parsing to anchor the parser, and can only mean what they are intended to mean by the language. This means they are reserved by the language, and can't be used by users of the language. Terms with __ are also keywords, but are marked that way because they are used in unusual circumstances, were intended to be replaced with a more formal keyword, or were chosen as not to interfere with any existing symbols (i.e. added after much D code already existed). The language tries not to add keywords any more because it breaks any code that uses it. There aren't many of these. In general, you should not use symbols with two underscores because those are expected to be reserved by the language or compiler. It's not a hard-fast rule, but I'd expect there to never be any new keywords that don't start with __. The terms with the @ sign are attributes, and can only be used as attributes. They are never storage classes, types, or keywords in general. In this space, the language has many pre-defined attributes, and you can't use them to mean something different (as attributes) once the language has defined it. Think of these as pre-defined symbols. The nice thing about these are that you can use them as regular symbols without the @ sign, and it doesn't change anything. As long as you don't intend to use them as actual attributes, you should be fine. However, I'd recommend not to do this as this can be confusing to anyone reading your code and not knowing the pre-defined attributes. Note that attributes were added much later in the language, and most of the predefined attributes were added before user defined attributes were supported. So I expect not many more language defined attributes will be added unless absolutely necessary. You may ask, why the difference between e.g. @safe and pure? Historical reasons really. It should really be @pure, but pure was a keyword from very early. So there is a bit of that. -Steve
Re: how to understand different attribute styles?
On Monday, October 17, 2016 14:12:33 timepp via Digitalmars-d-learn wrote: > there is "@disable", using @ as prefix; > there is "__gshared", using __ as prefix; > there is also "align", not using prefix. > > I failed to summarize a rule here. Can anyone tell the underlined > philosiphy? There really isn't one. __gshared is probably the way that it is, because it's not something much of anything but C bindings should be using (it exists solely for compatibility with C global variables). So, it's treated as a compiler thing (like __traits) rather than a normal attribute. But as for @, what that pretty much comes down to is that Walter didn't want to add more keywords. So, new ones got @ put on them (and all of this was well before user defined attributes came along). In general, folks don't like the fact that there is no consistency between what has @ and what doesn't, but no one can come up with a scheme that's actually fully consistent (at least, not without slapping @ on all attributes or having it on none), and it would break a ton of code if any of them were changed now, so it's highly unlikely that any of them will ever change. So, you just learn which ones have @ and which don't, and then it mostly doesn't matter anymore, as annoying as it may be from an aesthetic point of view. - Jonathan M Davis
Re: Escaping ref to stack mem sometimes allowed in @safe?
On Friday, October 14, 2016 16:49:44 Nick Sabalausky via Digitalmars-d-learn
wrote:
> This compiles. Is it supposed to?
>
> @safe ubyte[] foo()
> {
> ubyte[512] buf;
> auto slice = buf[0..$];
> // Escaping reference to stack memory, right?
> return slice;
> }
>
> Or is the escaping reference detection not intended to be 100%? Or
> something else I'm missing?
>
> Should I file @ bugzilla?
It's a long-standing bug:
https://issues.dlang.org/show_bug.cgi?id=8838
But Walter has been working on @safety issues recently (particularly with
regards to stuff like parameters escaping, because of DIP1000), so a fix
should finally be coming.
- Jonathan M Davis
Re: how to understand different attribute styles?
On Monday, 17 October 2016 at 14:12:33 UTC, timepp wrote: there is "@disable", using @ as prefix; there is "__gshared", using __ as prefix; there is also "align", not using prefix. I failed to summarize a rule here. Can anyone tell the underlined philosophy? It's an inconsistency of the language. see http://forum.dlang.org/post/hfmulninvghjntqkp...@forum.dlang.org
how to understand different attribute styles?
there is "@disable", using @ as prefix; there is "__gshared", using __ as prefix; there is also "align", not using prefix. I failed to summarize a rule here. Can anyone tell the underlined philosiphy?
Re: Bug or case of hijacking protection ?
On Monday, 17 October 2016 at 14:01:26 UTC, Basile B. wrote:
Is this a bug or a case of hijacking protection ?
struct S
{
void test(void*, size_t){}
}
void test(ref S,void[]){}
void main()
{
ubyte[] a;
(*new S).test(a);
}
In the meantime I've found this BR:
https://issues.dlang.org/show_bug.cgi?id=11836
It could be closed if it's an authentic anti-hijacking
case...waitaing for your expertise.
Bug or case of hijacking protection ?
Is this a bug or a case of hijacking protection ?
struct S
{
void test(void*, size_t){}
}
void test(ref S,void[]){}
void main()
{
ubyte[] a;
(*new S).test(a);
}
Re: Speed of synchronized
On 17/10/16 14:09, Daniel Kozak via Digitalmars-d-learn wrote:
> Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
>> Hi,
>>
>> for an exercise I had to implement a thread safe counter.
>> This is what I came up with:
>>
>>
>> btw. I run the code with dub run --build=release
>>
>> Thanks in advance,
>> Christian
> So I have done some testing, on my pc:
> Java result
> counter.AtomicLongCounter@7ff5e7d8 expected: 200 got: 100 in: 83ms
> counter.ThreadSafe2Counter@59b44e4b expected: 200 got: 100 in: 77ms
> counter.ThreadSafe1Counter@2e5f6b4b expected: 200 got: 100 in:
> 154ms
> counter.ThreadUnsafeCounter@762b155d expected: 200 got: 730428 in: 13ms
>
> and my D results (code: http://dpaste.com/3QFXACY ):
> snip.AtomicCounter: got: 100 expected: 100 in 77 ms and 783 μs
> snip.ThreadSafe1Counter: got: 100 expected: 100 in 287 ms, 727
> μs, and 3 hnsecs
> snip.ThreadSafe2Counter: got: 100 expected: 100 in 281 ms, 117
> μs, and 1 hnsec
> snip.ThreadSafe3Counter: got: 100 expected: 100 in 158 ms, 480
> μs, and 2 hnsecs
> snip.ThreadUnsafeCounter: got: 100 expected: 100 in 6 ms, 682
> μs, and 1 hnsec
>
> so atomic is same as in Java pthread_mutex is same speed as java
> synchronized
> D mutexes and D synchronized are almost same, I belive that if I could
> setup same attrs as in pthread version it will be around 160ms too.
>
> Unsafe is almost same for D and java. Only java ReentrantLock seems to
> work better. I believe there is some trick, so it will end up not using
> mutexes in the end at all. For example consider this change in D code:
>
> void doIt(alias counter)() {
> auto thg = new ThreadGroup();
> for (int i=0; i thg.create(!(counter));
> }
> thg.joinAll();
> }
>
> change it to
>
> void doIt(alias counter)() {
> auto thg = new ThreadGroup();
> for (int i=0; i auto tc = thg.create(!(counter));
> tc.join();
> }
> }
>
> and results are:
>
> snip.AtomicCounter: got: 100 expected: 100 in 22 ms, 251 μs, and
> 6 hnsecs
> snip.ThreadSafe1Counter: got: 100 expected: 100 in 46 ms, 146
> μs, and 3 hnsecs
> snip.ThreadSafe2Counter: got: 100 expected: 100 in 44 ms, 961
> μs, and 5 hnsecs
> snip.ThreadSafe3Counter: got: 100 expected: 100 in 42 ms, 512
> μs, and 8 hnsecs
> snip.ThreadUnsafeCounter: got: 100 expected: 100 in 2 ms, 108
> μs, and 5 hnsecs
>
>
>
>
>
thank you for looking into it.
this seems to be quite good.
I did expect something in those lines, but got the mentioned numbers on
my os x macbook. perhaps its a os x glitch.
Re: Speed of synchronized
Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
Hi,
for an exercise I had to implement a thread safe counter.
This is what I came up with:
btw. I run the code with dub run --build=release
Thanks in advance,
Christian
So I have done some testing, on my pc:
Java result
counter.AtomicLongCounter@7ff5e7d8 expected: 200 got: 100 in: 83ms
counter.ThreadSafe2Counter@59b44e4b expected: 200 got: 100 in: 77ms
counter.ThreadSafe1Counter@2e5f6b4b expected: 200 got: 100 in: 154ms
counter.ThreadUnsafeCounter@762b155d expected: 200 got: 730428 in: 13ms
and my D results (code: http://dpaste.com/3QFXACY ):
snip.AtomicCounter: got: 100 expected: 100 in 77 ms and 783 μs
snip.ThreadSafe1Counter: got: 100 expected: 100 in 287 ms, 727
μs, and 3 hnsecs
snip.ThreadSafe2Counter: got: 100 expected: 100 in 281 ms, 117
μs, and 1 hnsec
snip.ThreadSafe3Counter: got: 100 expected: 100 in 158 ms, 480
μs, and 2 hnsecs
snip.ThreadUnsafeCounter: got: 100 expected: 100 in 6 ms, 682
μs, and 1 hnsec
so atomic is same as in Java pthread_mutex is same speed as java
synchronized
D mutexes and D synchronized are almost same, I belive that if I could
setup same attrs as in pthread version it will be around 160ms too.
Unsafe is almost same for D and java. Only java ReentrantLock seems to
work better. I believe there is some trick, so it will end up not using
mutexes in the end at all. For example consider this change in D code:
void doIt(alias counter)() {
auto thg = new ThreadGroup();
for (int i=0; i
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Thursday, 13 October 2016 at 18:35:43 UTC, Matthias Klumpp wrote: The new toolchains of Ubuntu (and Debian soon too) default to PIE code, so in order to link correctly, the project needs to be compiled with PIE/PIC to work. Please update the bug report. https://issues.dlang.org/show_bug.cgi?id=5278
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On 2016-10-17 10:55, Nordlöw wrote: It's the target `idgen` that fails for me. "idgen" is a separate target [1]. It's a tool that generates some code. [1] https://github.com/dlang/dmd/blob/master/src/posix.mak#L389 -- /Jacob Carlborg
Re: Is this should work?
Dne 17.10.2016 v 11:56 markov via Digitalmars-d-learn napsal(a):
Thanks.
So something like this would be helpful in core.thread?
void startThread(alias fun, P...)(P p){
new Thread({fun(p);}).start();
}
or without delegate
import std.stdio;
import core.thread;
void fun(alias a, alias msg)()
{
writefln("Hello number %d from %s", a, msg);
}
void main()
{
int a = 7;
string msg = "main";
auto thr = new Thread(!(a, msg)).start;
thr.join;
}
Re: Is this should work?
Thanks.
So something like this would be helpful in core.thread?
void startThread(alias fun, P...)(P p){
new Thread({fun(p);}).start();
}
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Monday, 17 October 2016 at 08:39:55 UTC, Nordlöw wrote: I you only tell me what to do I can make a PR to DMD that fixes these things. It's the target `idgen` that fails for me.
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Monday, 17 October 2016 at 05:55:55 UTC, tcak wrote: So, I added -defaultlib=libphobos2.so -fPIC Where did you add it? To the command-line or Makefile? And which Make variable did you change? I've tried make -f posix.mak MODEL_FLAG="-fPIC" but C++ compilations still fail with complaining about libphobos2.a not being compiled with -fPIC flag. -defaultlib is a DMD flag so that has not effect with the C++ compilations. This must be fixed in the DMD Makefiles! I you only tell me what to do I can make a PR to DMD that fixes these things.
Re: Render SVG To Display And Update Periodically
On Monday, 17 October 2016 at 07:05:24 UTC, ketmar wrote: On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole wrote: You're going to need to find an svg rasterizer in some form or another. I don't think we have one in D and certainly not a complete one. 'cmon, you know that i have a working port of NanoSVG! and it works on top of NanoVG, so no toolkit is required. ah... oops, forgot to give some links. ;-) nanovg and nanosvg ports: http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg some demos: http://repo.or.cz/iv.d.git/tree/HEAD:/nanovg_demo to make it actually draw something, i'm using Adam's excellect simpledisplay from here: https://github.com/adamdruppe/arsd fetching color.d and simpledisplay.d is enough, you don't need the whole repository. ;-) it works at least in GNU/Linux and Windows. OSX is not tested.
Re: Render SVG To Display And Update Periodically
On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole wrote: You're going to need to find an svg rasterizer in some form or another. I don't think we have one in D and certainly not a complete one. 'cmon, you know that i have a working port of NanoSVG! and it works on top of NanoVG, so no toolkit is required. ah...
Re: Speed of synchronized
On Monday, 17 October 2016 at 06:38:08 UTC, Daniel Kozak wrote: Dne 17.10.2016 v 07:55 Christian Köstlin via Digitalmars-d-learn napsal(a): [...] I am still unable to get your java code working: [kozak@dajinka threads]$ ./gradlew clean build :clean :compileJava :processResources UP-TO-DATE :classes :jar :assemble :compileTestJava :processTestResources UP-TO-DATE :testClasses :test :check :build BUILD SUCCESSFUL Total time: 3.726 secs How I can run it? I have it, it is in build/test-results/test/TEST-counter.CounterTest.xml
Re: Speed of synchronized
Dne 17.10.2016 v 07:55 Christian Köstlin via Digitalmars-d-learn napsal(a): to run java call ./gradlew clean build -> counter.AtomicIntCounter@25992ae3 expected: 200 got: 100 in: 22ms counter.AtomicLongCounter@2539f946 expected: 200 got: 100 in: 17ms counter.ThreadSafe2Counter@527d56c2 expected: 200 got: 100 in: 33ms counter.ThreadSafe1Counter@6fd8b1a expected: 200 got: 100 in: 173ms counter.ThreadUnsafeCounter@6bb33878 expected: 200 got: 562858 in: 10ms I am still unable to get your java code working: [kozak@dajinka threads]$ ./gradlew clean build :clean :compileJava :processResources UP-TO-DATE :classes :jar :assemble :compileTestJava :processTestResources UP-TO-DATE :testClasses :test :check :build BUILD SUCCESSFUL Total time: 3.726 secs How I can run it?
Re: Speed of synchronized
On 17/10/16 06:55, Daniel Kozak via Digitalmars-d-learn wrote:
> Dne 16.10.2016 v 10:41 Christian Köstlin via Digitalmars-d-learn napsal(a):
>
>> My question now is, why is each mutex based thread safe variant so slow
>> compared to a similar java program? The only hint could be something
>> like:
>> https://blogs.oracle.com/dave/entry/java_util_concurrent_reentrantlock_vs
>> that
>> mentions, that there is some magic going on underneath.
>> For the atomic and the non thread safe variant, the d solution seems to
>> be twice as fast as my java program, for the locked variant, the java
>> program seems to be 40 times faster?
>>
>> btw. I run the code with dub run --build=release
>>
>> Thanks in advance,
>> Christian
> Can you post your timings (both D and Java)? And can you post your java
> code?
Hi,
thanks for asking. I attached my java and d sources.
Both try to do more or less the same thing. They spawn 100 threads, that
call increment on a counter object 1 times. The implementation of
the counter object is exchanged, between a obviously broken thread
unsafe implementation, some with atomic operations, some with
mutex-implementations.
to run java call ./gradlew clean build
->
counter.AtomicIntCounter@25992ae3 expected: 200 got: 100 in: 22ms
counter.AtomicLongCounter@2539f946 expected: 200 got: 100 in: 17ms
counter.ThreadSafe2Counter@527d56c2 expected: 200 got: 100 in: 33ms
counter.ThreadSafe1Counter@6fd8b1a expected: 200 got: 100 in: 173ms
counter.ThreadUnsafeCounter@6bb33878 expected: 200 got: 562858 in: 10ms
obviously the unsafe implementation is fastest, followed by atomics.
the vrsion with reentrant locks performs very well, wheras the
implementation with synchronized is the slowest.
to run d call dub test (please mark, that the dub test build is
configured like this:
buildType "unittest" {
buildOptions "releaseMode" "optimize" "inline" "unittests" "debugInfo"
}
, it should be release code speed and quality).
->
app.AtomicCounter: got: 100 expected: 100 in 23 ms, 852 μs, and
6 hnsecs
app.ThreadSafe1Counter: got: 100 expected: 100 in 3 secs, 673
ms, 232 μs, and 6 hnsecs
app.ThreadSafe2Counter: got: 100 expected: 100 in 3 secs, 684
ms, 416 μs, and 2 hnsecs
app.ThreadUnsafeCounter: got: 690073 expected: 100 in 8 ms and 540 μs
from example got: 3 secs, 806 ms, and 258 μs
here again, the unsafe implemenation is the fastest,
atomic performs in the same ballpark as java
only the thread safe variants are far off.
thanks for looking into this,
best regards,
christian
threads.tar.gz
Description: GNU Zip compressed data
Re: Speed of synchronized
On 16/10/16 19:50, tcak wrote:
> On Sunday, 16 October 2016 at 08:41:26 UTC, Christian Köstlin wrote:
>> Hi,
>>
>> for an exercise I had to implement a thread safe counter. This is what
>> I came up with:
>>
>> [...]
>
> Could you try that:
>
> class ThreadSafe3Counter: Counter{
> private long counter;
> private core.sync.mutex.Mutex mtx;
>
> public this() shared{
> mtx = cast(shared)( new core.sync.mutex.Mutex );
> }
>
> void increment() shared {
> (cast()mtx).lock();
> scope(exit){ (cast()mtx).unlock(); }
>
> core.atomic.atomicOp!"+="(this.counter, 1);
> }
>
> long get() shared {
> return counter;
> }
> }
>
>
> Unfortunately, there are some stupid design decisions in D about
> "shared", and some people does not want to accept them.
>
> Example while you are using mutex, so you shouldn't be forced to use
> atomicOp there. As a programmer, you know that it will be protected
> already. That is a loss of performance in the long run.
thanks for the implementation. i think this is nicer, than using __gshared.
i think using atomic operations and mutexes at the same time, does not
make any sense. one or the other.
thanks,
Christian
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Sunday, 16 October 2016 at 22:36:15 UTC, Nordlöw wrote: On Sunday, 16 October 2016 at 22:00:48 UTC, Nordlöw wrote: Which flag(s) in `src/posix.mak` did you change? Does make -f posix.mak MODEL_FLAG=-fPIC work? I'm sitting on a 16.04 system right now (which I don't dare to upgrade until this is fixed) so I'm just guessing. Well, I haven't made any changes anywhere at all. I always download the deb file and install it. My program was compiling on 16.04, and wasn't compiling on 16.10. So, I added -defaultlib=libphobos2.so -fPIC while compiling. That's it. But as you can guess, now I have to copy the libphobos on other computers as well as the executable. (libphotos2.so.0.71 is 9 MiB)
