On Tuesday, 12 February 2013 at 07:07:21 UTC, Jonathan M Davis
wrote:
Which I don't think was ever really intended. That doesn't mean
that it's
unreasonable, but I think that it was always the idea that a
particular thread
had a particular job, in which case, you wouldn't generally be
trying to
On 2013-02-12 07:58, monarch_dodra wrote:
I think I didn't explain myself very well. I have my single "master" thread
which has a "thread-global" mailbox, but I have 3 different objects that are
sharing that mailbox.
OK, I finally get what you are saying.
You need to create a mailbox and a uniq
On Tuesday, 12 February 2013 at 10:08:14 UTC, FG wrote:
On 2013-02-12 07:58, monarch_dodra wrote:
I think I didn't explain myself very well. I have my single
"master" thread
which has a "thread-global" mailbox, but I have 3 different
objects that are
sharing that mailbox.
OK, I finally get w
On Tuesday, 12 February 2013 at 12:02:59 UTC, bioinfornatics
wrote:
instead to use memcpy I try with slicing ~ lines 136 :
_hardBuffer[ 0 .. moveSize] = _hardBuffer[_bufPosition ..
moveSize + _bufPosition];
I get same perf
I think I figured out why I'm getting different results than you
gu
On 2013-02-12 12:14, monarch_dodra wrote:
For one thing, "MessageBox" is private.
Unnecessarily hidden, because, from what I can see from a fast look at the
sources, there is no implicit requirement for there to be only one MessageBox
per thread. Maybe we're getting somewhere and this will be
On Tuesday, 12 February 2013 at 12:45:26 UTC, monarch_dodra wrote:
On Tuesday, 12 February 2013 at 12:02:59 UTC, bioinfornatics
wrote:
instead to use memcpy I try with slicing ~ lines 136 :
_hardBuffer[ 0 .. moveSize] = _hardBuffer[_bufPosition ..
moveSize + _bufPosition];
I get same perf
On Tuesday, 12 February 2013 at 16:28:09 UTC, bioinfornatics
wrote:
On Tuesday, 12 February 2013 at 12:45:26 UTC, monarch_dodra
wrote:
On Tuesday, 12 February 2013 at 12:02:59 UTC, bioinfornatics
wrote:
instead to use memcpy I try with slicing ~ lines 136 :
_hardBuffer[ 0 .. moveSize] = _hardB
On 2013-02-12 17:45, monarch_dodra wrote:
A better approach would be to have 1 file reader that passes data to two
simultaneous parsers. This, however, would make things scary complicated, and
I'd doubt we'd even get much better results: I was not able to measure the
actual amount of time spent w
On 2013-02-12 17:28, bioinfornatics wrote:
about threaded version is possible to use get file size function to split it in
several thread.
Use fseek read end of section return it to detect end of split to used
Yes, but like already mentioned before, it only works well for SSD.
For normal hard d
On Monday, 4 February 2013 at 23:55:25 UTC, bearophile wrote:
Is the Fwend user of Rosettacode (or some other interested
person) around here? I have written partial D implementations
for three tasks, maybe a little of coordination will speedup
the work:
http://rosettacode.org/wiki/Permutation
ixid:
If you're posting code on Rosetta code you are presenting that
code as idiomatic.
The D code on Rosettacode has some stylistic uniformity, and I
think in most cases it follows the dstyle
(http://dlang.org/dstyle.html ), but that code is not meant to be
"production code" (lot of people
What other things do you want to discuss about?
I mean some level of D community discussion of the language as a
whole as to what is an idiomatic style, perhaps after the current
issues are settled, not anything specific about your code. There
are areas like complex UFCS statements where it w
ixid:
I mean some level of D community discussion of the language as
a whole as to what is an idiomatic style, perhaps after the
current issues are settled, not anything specific about your
code.
Such discussion seems better in the main D newsgroup. But it also
seems a good way to waste tim
I am writing Julia sets program in C++ and D; exactly same way as
much as possible. On executing I find large difference in their
execution time. Can you comment what wrong am I doing or is it
expected?
//===C++ code, compiled with -O3 ==
#include
#include
using name
I am finding C++ code is much faster than D code.
On Tuesday, 12 February 2013 at 20:39:36 UTC, Sparsh Mittal wrote:
I am finding C++ code is much faster than D code.
dmd (AFAIK) is known to be slower. try LDC or GDC if speed is
your major concern.
13-Feb-2013 00:39, Sparsh Mittal пишет:
I am finding C++ code is much faster than D code.
Seems like DMD's floating point issue. The issue being that it always
works with floats as full-width reals + rounding. Basically if nothing
changed (and I doubt it changed) then DMD with floating point
Pardon me, can you please point me to suitable reference or tell
just command here. Searching on google, I could not find anything
yet. Performance is my main concern.
On Wed, Feb 13, 2013 at 12:56:01AM +0400, Dmitry Olshansky wrote:
> 13-Feb-2013 00:39, Sparsh Mittal пишет:
> >I am finding C++ code is much faster than D code.
>
> Seems like DMD's floating point issue. The issue being that it
> always works with floats as full-width reals + rounding. Basically
>
OK. I found it.
13-Feb-2013 01:09, Sparsh Mittal пишет:
Pardon me, can you please point me to suitable reference or tell just
command here. Searching on google, I could not find anything yet.
Performance is my main concern.
GDC, seems like its mostly "build from source" kind of thing.
Moved to gitbub:
https:
Thanks for your insights. It was very helpful.
On Tuesday, 12 February 2013 at 21:41:14 UTC, bioinfornatics
wrote:
Some time fastq are comressed to gz bz2 or xz as that is often a
huge file.
Maybe we need keep in mind this early in developement and use
std.zlib
While working on making the parser multi-threaded compatible, I
was able to se
On 2013-02-12 21:39, Sparsh Mittal wrote:
I am finding C++ code is much faster than D code.
I had a look, but first had to make juliaValue global, because g++ had optimized
all the calculations away. :) Also changed DIM to 32 * 1024.
13.2s -- g++ -O3
16.0s -- g++ -O2
15.9s -- gdc -O3
15.9s
I had a look, but first had to make juliaValue global, because
g++ had optimized all the calculations away.
Brilliant! Yes, that is why the time was coming out to be zero,
regardless of what value of DIM I put. Thank you very very much.
On 2013-02-13 00:06, Sparsh Mittal wrote:
I had a look, but first had to make juliaValue global, because g++ had
optimized all the calculations away.
Brilliant! Yes, that is why the time was coming out to be zero, regardless of
what value of DIM I put. Thank you very very much.
LOL. For a w
LOL. For a while you thought that C++ could be that much faster
than D? :D
I was stunned and shared it with others who could not find. It
was like a scientist discovering a phenomenon which is against
established laws. Good that I was wrong and a right person
pointed it.
Well technically it was that much faster because it did optimize
away the useless calcOn Tuesday, 12 February 2013 at 23:31:17
UTC, FG wrote:
On 2013-02-13 00:06, Sparsh Mittal wrote:
I had a look, but first had to make juliaValue global,
because g++ had
optimized all the calculations away.
28 matches
Mail list logo
