On Sat, 04 Oct 2014 16:52:08 +
John Colvin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
It is a little noisy, but really very little. The only extra
noise is the call to Afoo.
it's very little turns to alot with alot of classes with alot of
methods. and code readability
Am 05.10.2014 02:11, schrieb David Nadlinger:
On Friday, 3 October 2014 at 23:00:53 UTC, Brian Hechinger wrote:
With my old set of packages I had no problems. I just now deleted
~/.dub and now I too get this error. Some issue with the openssl
module, yes, but what? This is a bit of an issue. :)
I have struct StringStream that I use to go through and parse
input string. String could be of string, wstring or dstring type.
I implement function popChar that reads codeUnit from Stream. I
want to have *debug* mode of parser (via CT switch), where I
could get information about lineIndex,
On Saturday, 4 October 2014 at 21:59:43 UTC, notna wrote:
Cool,thanks.
Btw., there could be more special chars to encode...replace
beside :... like / @ and so on... see also
http://www.cyberciti.biz/faq/unix-linux-export-variable-http_proxy-with-special-characters/
for the background
Does
I know this keeps getting asked every year or so, but I couldn't find
recent info.
Are line numbers in linux stack traces supposed to be working at this
point? Because I'm not getting any with 2.066.0 with either -g or -gc
even when running under gdb. Kind of a pain, esp. compared to D dev on
On Sunday, 5 October 2014 at 08:27:58 UTC, Uranuz wrote:
I have struct StringStream that I use to go through and parse
input string. String could be of string, wstring or dstring
type. I implement function popChar that reads codeUnit from
Stream. I want to have *debug* mode of parser (via CT
You can use std.uni.byGrapheme to iterate by graphemes:
http://dlang.org/phobos/std_uni.html#.byGrapheme
AFAIK, graphemes are not self synchronizing, but codepoints
are. You can pop code units until you reach the beginning of a
new codepoint. From there, you can iterate by graphemes, though
On Sunday, 5 October 2014 at 06:39:00 UTC, Sönke Ludwig wrote:
At first glance, this seems like a forward reference issue.
deimos.openssl.ossl_typ imports deimos.openssl.ssl, but also
the other
way round.
The only explanation I can think of is that
version = OPENSSL_NO_SSL_INTERN;
for some
On Sunday, 5 October 2014 at 06:39:00 UTC, Sönke Ludwig wrote:
Judging by the log output it should be fixed (on vibe.d's
side) with [1] by using a version based dependency to the
OpenSSL bindings with an old version*. I've tagged a new RC-2
version now (although it's not really an RC with more
Hello,
I am summing up the first 1 billion integers in parallel and in a
single thread and I'm observing some curious results;
parallel sum : 45, elapsed 102833 ms
single thread sum : 45, elapsed 1667 ms
The parallel version is 60+ times slower on my i7-3770K
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/10/14 15:27, flamencofantasy via Digitalmars-d-learn wrote:
Hello,
I am summing up the first 1 billion integers in parallel and in a
single thread and I'm observing some curious results;
I am fairly certain that your use of parallel for
Welcome to the world of multithreading.
You have just discovered that atomic operations are performance
killers, congratulations on this.
On Sunday, 5 October 2014 at 09:10:06 UTC, Nick Sabalausky wrote:
I know this keeps getting asked every year or so, but I
couldn't find recent info.
Are line numbers in linux stack traces supposed to be working
at this point?
Not the ones that the program itself prints on an unhandled
Two problems, one, you should create your threads outside the
stop watch, it is not generally a fair comparison in the real
world. It throws of the results for short tasks.
Second, you are creating one thread per integer, this is bad. Do
you really want to create 1B threads when you only have
On 2014-10-05 14:09, Uranuz wrote:
Maybe there is some idea how to just detect first code unit of grapheme
without overhead for using Grapheme struct? I just tried to check if ch
128 (for UTF-8). But this dont work. How to check if byte is
continuation of code for single code point or if new
On 10/05/2014 07:27 AM, flamencofantasy wrote:
I am summing up the first 1 billion integers in parallel and in a single
thread and I'm observing some curious results;
parallel sum : 45, elapsed 102833 ms
single thread sum : 45, elapsed 1667 ms
The parallel
On Sunday, 5 October 2014 at 21:25:39 UTC, Ali Çehreli wrote:
import std.stdio, std.cstream, std.parallelism, std.datetime,
std.range, core.atomic;
void main()
{
StopWatch sw;
shared ulong sum1 = 0; ulong sum2 = 0, sum3 = 0, time1, time2,
time3;
enum numThreads = 4; // If
On 10/05/2014 02:40 PM, Sativa wrote:
foreach(i; thds) { ulong s = 0; for(ulong k = 0; k
iter/numThreads; k++)
The for loop condition is executed at every iteration and division is an
expensive operation. Apparently, the compiled does some optimization
when the divisor is known at
On Sunday, 5 October 2014 at 21:53:23 UTC, Ali Çehreli wrote:
On 10/05/2014 02:40 PM, Sativa wrote:
foreach(i; thds) { ulong s = 0; for(ulong k = 0; k
iter/numThreads; k++)
The for loop condition is executed at every iteration and
division is an expensive operation. Apparently, the
Thanks everyone for the replies.
I wasn't sure how std.parallel operated but I thought it would
launch at most a number of threads equal to the number of cores
on the machine, just as Ali confirmed and similar to what
Windows' thread pool does.
20 matches
Mail list logo
