Re: Performance of map!()
On Friday, 24 April 2015 at 10:22:05 UTC, Chris wrote:
I replaced a range that was similar to map with map and the
performance dropped by ~0.5 msec.
The range I used previously is based on Adam's D Cookbook. It
is consistently faster than map.
private struct Transformer(alias agent, R) if (isInputRange!R) {
private R r;
this (R r) {
this.r = r;
}
static if (isInfinite!R) {
enum bool empty = false;
}
else {
@property bool empty() {
return r.empty;
}
}
void popFront() {
r.popFront();
}
@property ref auto front() {
return agent(r.front);
}
static if (isForwardRange!R) {
@property auto save() {
return Transformer!(agent, R)(r.save);
}
}
static if (isBidirectionalRange!R) {
@property auto back() {
return agent(r.back);
}
void popBack() {
r.popBack();
}
}
static if (isRandomAccessRange!R) {
auto opIndex(size_t i) {
return agent(r[i]);
}
}
static if (hasLength!R) {
@property auto length() {
return r.length;
}
}
}
Compiler? Compiler flags?
Re: Performance of map!()
On Friday, 24 April 2015 at 10:53:04 UTC, John Colvin wrote:
On Friday, 24 April 2015 at 10:22:05 UTC, Chris wrote:
I replaced a range that was similar to map with map and the
performance dropped by ~0.5 msec.
The range I used previously is based on Adam's D Cookbook. It
is consistently faster than map.
private struct Transformer(alias agent, R) if (isInputRange!R)
{
private R r;
this (R r) {
this.r = r;
}
static if (isInfinite!R) {
enum bool empty = false;
}
else {
@property bool empty() {
return r.empty;
}
}
void popFront() {
r.popFront();
}
@property ref auto front() {
return agent(r.front);
}
static if (isForwardRange!R) {
@property auto save() {
return Transformer!(agent, R)(r.save);
}
}
static if (isBidirectionalRange!R) {
@property auto back() {
return agent(r.back);
}
void popBack() {
r.popBack();
}
}
static if (isRandomAccessRange!R) {
auto opIndex(size_t i) {
return agent(r[i]);
}
}
static if (hasLength!R) {
@property auto length() {
return r.length;
}
}
}
Compiler? Compiler flags?
dmd v2.067.0
dub --build=release (-release -inline -O -boundscheck=off)
Re: Performance of map!()
On Friday, 24 April 2015 at 10:22:05 UTC, Chris wrote:
I replaced a range that was similar to map with map and the
performance dropped by ~0.5 msec.
The range I used previously is based on Adam's D Cookbook. It
is consistently faster than map.
private struct Transformer(alias agent, R) if (isInputRange!R) {
private R r;
this (R r) {
this.r = r;
}
static if (isInfinite!R) {
enum bool empty = false;
}
else {
@property bool empty() {
return r.empty;
}
}
void popFront() {
r.popFront();
}
@property ref auto front() {
return agent(r.front);
}
static if (isForwardRange!R) {
@property auto save() {
return Transformer!(agent, R)(r.save);
}
}
static if (isBidirectionalRange!R) {
@property auto back() {
return agent(r.back);
}
void popBack() {
r.popBack();
}
}
static if (isRandomAccessRange!R) {
auto opIndex(size_t i) {
return agent(r[i]);
}
}
static if (hasLength!R) {
@property auto length() {
return r.length;
}
}
}
That is pretty much identical to the implementation of map, see
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L504
The only difference is that you don't implement opSlice. Perhaps
slicing is particularly slow for your source range?
Re: Performance of map!()
dmd v2.067.0 dub --build=release (-release -inline -O -boundscheck=off) Does a benchmark of dmd generated code really matter?
Re: Performance of map!()
On Friday, 24 April 2015 at 11:33:48 UTC, John Colvin wrote:
On Friday, 24 April 2015 at 10:22:05 UTC, Chris wrote:
I replaced a range that was similar to map with map and the
performance dropped by ~0.5 msec.
The range I used previously is based on Adam's D Cookbook. It
is consistently faster than map.
private struct Transformer(alias agent, R) if (isInputRange!R)
{
private R r;
this (R r) {
this.r = r;
}
static if (isInfinite!R) {
enum bool empty = false;
}
else {
@property bool empty() {
return r.empty;
}
}
void popFront() {
r.popFront();
}
@property ref auto front() {
return agent(r.front);
}
static if (isForwardRange!R) {
@property auto save() {
return Transformer!(agent, R)(r.save);
}
}
static if (isBidirectionalRange!R) {
@property auto back() {
return agent(r.back);
}
void popBack() {
r.popBack();
}
}
static if (isRandomAccessRange!R) {
auto opIndex(size_t i) {
return agent(r[i]);
}
}
static if (hasLength!R) {
@property auto length() {
return r.length;
}
}
}
That is pretty much identical to the implementation of map, see
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L504
Yeah, I saw that.
The only difference is that you don't implement opSlice.
Perhaps slicing is particularly slow for your source range?
The source range is a string[][].
Re: Performance of map!()
On Friday, 24 April 2015 at 11:38:46 UTC, Casper Færgemand wrote: dmd v2.067.0 dub --build=release (-release -inline -O -boundscheck=off) Does a benchmark of dmd generated code really matter? At least for dmd.
Re: Performance of map!()
On Friday, 24 April 2015 at 11:49:24 UTC, Chris wrote: On Friday, 24 April 2015 at 11:38:46 UTC, Casper Færgemand wrote: dmd v2.067.0 dub --build=release (-release -inline -O -boundscheck=off) Does a benchmark of dmd generated code really matter? At least for dmd. dmd is good at making machine code fast, not making fast machine code. It's not that I mind effort is put into dmd, it's just that if the code change doesn't improve the output of gdc and ldc, then code compiled with their better optimizers won't ever feel the change. Can you post the full benchmark?
Re: Performance of map!()
On Friday, 24 April 2015 at 11:33:48 UTC, John Colvin wrote: That is pretty much identical to the implementation of map, see https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L504 The only difference is that you don't implement opSlice. Perhaps slicing is particularly slow for your source range? I suspect the cause is the current inability to inline across modules.
