On 2013-05-16 21:54, Walter Bright wrote:
We should also be aware that while Python code itself is slow, its
library functions are heavily optimized C code. So, if the benchmark
consists of calling a Python library function, it'll run as fast as any
optimized C code.
But someone using Python
On Thursday, 16 May 2013 at 11:37:14 UTC, bearophile wrote:
Dicebot:
In the first of his posts I don't see -noboundscheck used, and
it compares different algorithms from C++ (a switch) and D (two
nested ifs, that are not optimal).
From my experience if you have some care you are able to
On Thursday, 16 May 2013 at 13:48:45 UTC, Juan Manuel Cabo wrote:
On Thursday, 16 May 2013 at 10:35:12 UTC, Dicebot wrote:
Want to bring into discussion people that are not on Google+.
Samuel recently has posted there some simple experiments with
bioinformatics and bad performance of
On Thursday, 16 May 2013 at 13:52:01 UTC, Juan Manuel Cabo wrote:
...
Thanks for the tool, it is a good one. But I was not doing
benchmarks this time, only cared about 2x difference at least, so
time was enough :)
On Thursday, 16 May 2013 at 14:23:22 UTC, nazriel wrote:
Very nice blog post.
Something similar should go into D wiki database so it won't
get lost in In 80s we had... topics.
For sure there is a space for improvements in Phobos but such
articles are good start to prevent wave of D is slow
On Thursday, 16 May 2013 at 19:15:57 UTC, Jonathan M Davis wrote:
1. In general, if you want to operate on ASCII, and you want
your code to be
fast, use immutable(ubyte)[], not immutable(char)[]. Obviously,
that's not
gonig to work in this case, because the function is in
std.string, but maybe
On Friday, May 17, 2013 11:15:24 Dicebot wrote:
On Thursday, 16 May 2013 at 19:15:57 UTC, Jonathan M Davis wrote:
1. In general, if you want to operate on ASCII, and you want
your code to be
fast, use immutable(ubyte)[], not immutable(char)[]. Obviously,
that's not
gonig to work in this
On Thursday, May 16, 2013 12:54:35 Walter Bright wrote:
On 5/16/2013 12:15 PM, Jonathan M Davis wrote:
And if python is faster than
D at something, odds are that either the code in question is poorly
written or that whatever Phobos functions it's using haven't been
properly optimized yet.
On Friday, 17 May 2013 at 08:28:38 UTC, Jacob Carlborg wrote:
On 2013-05-16 21:54, Walter Bright wrote:
We should also be aware that while Python code itself is slow,
its
library functions are heavily optimized C code. So, if the
benchmark
consists of calling a Python library function, it'll
On Friday, 17 May 2013 at 10:09:11 UTC, John Colvin wrote:
If naive D code has to be significantly faster than optimised C
for people to not go D sucks, it's only as fast as python
then we're pretty much doomed by peoples stupidity.
No. The whole benefit of D is lost if you have to tweak
On Friday, 17 May 2013 at 11:26:27 UTC, deadalnix wrote:
On Friday, 17 May 2013 at 10:09:11 UTC, John Colvin wrote:
If naive D code has to be significantly faster than optimised
C for people to not go D sucks, it's only as fast as python
then we're pretty much doomed by peoples stupidity.
On 05/17/2013 11:41 AM, Jonathan M Davis wrote:
We need to do more to optimize Phobos, but given our stance of correctness by
default, we're kind of stuck with string functions taking a performance hit in
a number of common cases simply due to the necessary decoding of code points.
We can do
Want to bring into discussion people that are not on Google+.
Samuel recently has posted there some simple experiments with
bioinformatics and bad performance of Phobos-based snippet has
surprised me.
I did explore issue a bit and reported results in a blog post
(snippets are really small
On Thursday, 16 May 2013 at 10:35:12 UTC, Dicebot wrote:
One open question remains though - can D/Phobos do better here?
Can some changes be done to Phobos functions in question to
improve performance or creating bioinformatics-specialized
library is only practical solution?
Of course things
Dicebot:
I did explore issue a bit and reported results in a blog post
(snippets are really small and simple) :
http://dicebot.blogspot.com/2013/05/short-performance-tuning-story.html
In the first of his posts I don't see -noboundscheck used, and it
compares different algorithms from C++ (a
On Thursday, 16 May 2013 at 10:35:12 UTC, Dicebot wrote:
Want to bring into discussion people that are not on Google+.
Samuel recently has posted there some simple experiments with
bioinformatics and bad performance of Phobos-based snippet has
surprised me.
I did explore issue a bit and
On Thursday, 16 May 2013 at 10:35:12 UTC, Dicebot wrote:
Want to bring into discussion people that are not on Google+.
Samuel recently has posted there some simple experiments with
bioinformatics and bad performance of Phobos-based snippet has
surprised me.
I did explore issue a bit and
May I also recommend my tool avgtime to make simple benchmarks,
instead of time (you can see an ascii histogram as the output):
https://github.com/jmcabo/avgtime/tree/
For example:
$ avgtime -r10 -h -q ls
Total time (ms): 27.413
Repetitions: 10
On Thursday, 16 May 2013 at 10:35:12 UTC, Dicebot wrote:
Want to bring into discussion people that are not on Google+.
Samuel recently has posted there some simple experiments with
bioinformatics and bad performance of Phobos-based snippet has
surprised me.
I did explore issue a bit and
On Thu, 16 May 2013 12:35:11 +0200
Dicebot m.stras...@gmail.com wrote:
I did explore issue a bit and reported results in a blog post
(snippets are really small and simple) :
http://dicebot.blogspot.com/2013/05/short-performance-tuning-story.html
For anyone else who has trouble viewing
On Thu, 16 May 2013 09:03:36 -0500
1100110 0b1100...@gmail.com wrote:
May I also recommend my tool avgtime to make simple benchmarks,
instead of time (you can see an ascii histogram as the output):
https://github.com/jmcabo/avgtime/tree/
For example:
$ avgtime -r10 -h -q
On 5/16/13 9:48 AM, Juan Manuel Cabo wrote:
I bet the problem is in readln. Currently, File.byLine() and readln()
are extremely slow, because they call fgetc() one char at a time.
Depends on the OS.
Andrei
On Thursday, May 16, 2013 12:35:11 Dicebot wrote:
Want to bring into discussion people that are not on Google+.
Samuel recently has posted there some simple experiments with
bioinformatics and bad performance of Phobos-based snippet has
surprised me.
I did explore issue a bit and reported
On 5/16/2013 12:15 PM, Jonathan M Davis wrote:
And if python is faster than
D at something, odds are that either the code in question is poorly written or
that whatever Phobos functions it's using haven't been properly optimized yet.
We should also be aware that while Python code itself is
On 05/16/2013 01:46 PM, Nick Sabalausky wrote:
On Thu, 16 May 2013 09:03:36 -0500
1100110 0b1100...@gmail.com wrote:
May I also recommend my tool avgtime to make simple benchmarks,
instead of time (you can see an ascii histogram as the output):
https://github.com/jmcabo/avgtime/tree/
On Thursday, 16 May 2013 at 22:58:42 UTC, 1100110 wrote:
On 05/16/2013 01:46 PM, Nick Sabalausky wrote:
On Thu, 16 May 2013 09:03:36 -0500
1100110 0b1100...@gmail.com wrote:
May I also recommend my tool avgtime to make simple
benchmarks,
instead of time (you can see an ascii histogram as the
On Fri, 17 May 2013 03:01:38 +0200
Juan Manuel Cabo juanmanuel.c...@gmail.com wrote:
On Thursday, 16 May 2013 at 22:58:42 UTC, 1100110 wrote:
On 05/16/2013 01:46 PM, Nick Sabalausky wrote:
Indeed. I had totally forgotten about that, and yet it
*should* be the
first thing I think of
27 matches
Mail list logo
