Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

20% more performance for popFront(char[]) #4849

Merged
merged 1 commit into from
Oct 12, 2016

Conversation

UplinkCoder
Copy link
Member

@UplinkCoder UplinkCoder commented Oct 11, 2016

As per title.
On average 15% more performance because of smaller code and avoiding bsr

@UplinkCoder UplinkCoder force-pushed the utf_popFront branch 3 times, most recently from 8975f54 to 6a6ca38 Compare October 11, 2016 10:51
@JackStouffer
Copy link
Member

JackStouffer commented Oct 11, 2016

Can you post some measurements with code?

@UplinkCoder
Copy link
Member Author

okay some measurements

pfold took 122us
pfnew took 116us
pfold took 122us
pfnew took 116us
pfold took 124us

@wilzbach
Copy link
Member

Can you post some measurements with code?

Maybe we can use this incident to start benchmarking directly in Phobos. A fancy way would be to run benchmarks for every PR to prevent performance regression, but a simpler approach is to at least collect them at a common place (e.g. benchmarks), s.t. (1) in the future enabling automated testing is possible and (2) other people can use these benchmarks for improving upon them (or manually checking regressions).

@UplinkCoder UplinkCoder changed the title 15% more performance for popFront(char[]) 5-15% more performance for popFront(char[]) Oct 11, 2016
@UplinkCoder
Copy link
Member Author

closed until I found out how I am diverging from the spec.

@UplinkCoder UplinkCoder reopened this Oct 12, 2016
@UplinkCoder UplinkCoder changed the title 5-15% more performance for popFront(char[]) 20% more performance for popFront(char[]) Oct 12, 2016
@JackStouffer
Copy link
Member

okay some measurements

This doesn't tell me anything. What's the code? What's the data you're using? Are you testing just Unicode strings or are you testing with mixed ascii and Unicode? Etc.

@UplinkCoder
Copy link
Member Author

@JackStouffer I am using ASCII mixed with unicode, 80% Ascii, 20% unicode.
The file is called blns.txt
https://github.com/minimaxir/big-list-of-naughty-strings/blob/master/blns.txt
The code of the benchmark is here
http://paste.ofcode.org/3CpieAhkrTYEcSncbPKbrj

@UplinkCoder UplinkCoder force-pushed the utf_popFront branch 2 times, most recently from a1934c3 to 6676abd Compare October 12, 2016 16:26
@UplinkCoder
Copy link
Member Author

I am wondering about the freebsd failure.
It seems related but I have no idea why it occurs.

Copy link
Member

@andralex andralex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@UplinkCoder how are you diverging from the spec?

];
/*
This implementation of popFront does not special case 0b10xx_xxxx
Nither did the one before.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Nither/Neither/

/*
This implementation of popFront does not special case 0b10xx_xxxx
Nither did the one before.
on illigal strings we may skip too many bytes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/on/On/
s/illigal/illegal/

This implementation of popFront does not special case 0b10xx_xxxx
Nither did the one before.
on illigal strings we may skip too many bytes.
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this comment. So if the first byte has the shape 0x10xx_xxxx (illegal) we skip one byte which is what we need to do.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... you are right
I had a brain-fart :)

@andralex
Copy link
Member

Seems the autotester failure is a timeout.

@UplinkCoder
Copy link
Member Author

@andralex I do not diverge from the spec anymore.

msbs = 1;
}
str = str.ptr[min(msbs, str.length) .. str.length];
str = str.ptr[min(str.length, charWidthTab[c - 192]) .. str.length];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use charWidthTab.ptr here, you've already bounds-checked it.

@andralex
Copy link
Member

OK, I approve this. Regarding the scrutiny: until we have benchmarking for phobos we need to rely on self-reported performance measurements.

@UplinkCoder
Copy link
Member Author

Hmm I cannot merge myself ....

@wilzbach
Copy link
Member

until we have benchmarking for phobos we need to rely on self-reported performance measurements.

Yes, but at least we can put the performance measurements into Phobos (or if wanted another common place), s.t. we can improve upon them & others can run the tests themselves.
I bet this PR will be hard to find for future D enthusiasts and the pastelink might even be gone / expired...

@andralex
Copy link
Member

@wilzbach well, "until we have benchmarking for phobos".equal("put the performance measurements into Phobos")

That's a project in and of itself, with its own build target, reporting, regression checks etc. etc. etc. I might be able to put someone on it, but it's way out of the scope of this PR.

@andralex
Copy link
Member

@UplinkCoder I've invited you

@UplinkCoder UplinkCoder merged commit 406aa8f into dlang:master Oct 12, 2016
@UplinkCoder
Copy link
Member Author

@andralex great merged.

@wilzbach
Copy link
Member

@andralex great merged.

You know - autotester is there for a reason :/

@andralex
Copy link
Member

@UplinkCoder Please create a user id in the autotester and use its "Toggle automerge" feature to pull PRs. Thanks!

@MartinNowak
Copy link
Member

MartinNowak commented Oct 13, 2016

Maybe we can use this incident to start benchmarking directly in Phobos. A fancy way would be to run benchmarks for every PR to prevent performance regression, but a simpler approach is to at least collect them at a common place (e.g. benchmarks), s.t. (1) in the future enabling automated testing is possible and (2) other people can use these benchmarks for improving upon them (or manually checking regressions).

We have something like that setup in druntime. A small benchmarks folder and a runner for microbenchmarks. No new std.benchmark or anything like that needed.

@MartinNowak
Copy link
Member

@UplinkCoder please read and/or enhance https://github.com/dlang/phobos/blob/master/CONTRIBUTING.md and the linked wiki pages.

@schveiguy
Copy link
Member

@UplinkCoder To clarify, in order to use autotester for merging (I'm not sure if this is documented anywhere, it wasn't when I learned how to do it), click on the link to the auto tester in the list of running tests for your PR, e.g.: https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1&repoid=3&pullid=4849

On the upper left corner is a "Login" link. Click on this, and it will link your github account into the auto-tester (not sure if any setup has to happen first time, I don't remember, it just works for me now). Now, the auto tester will provide at the top summary an "Auto-merge" toggle. Click that, and the auto tester will wait for all tests to pass, and merge on your behalf. Please use this when merging any PRs, it (almost) guarantees the master branch will always build.

please read and/or enhance ...

@MartinNowak I couldn't find anything on auto-tester usage there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants