It would be nice to see the benchmark that support the 1/3 faster claim. I don't doubt it, but there are always a lot of hidden assumptions and details that are missing, that I'd like to see the exact benchmark. Is it a small vector? Is it a large vector? What happens for different vectors sizes? What about int vs a complex struct? Too many questions ...
I'd would be better to change the license to an standard license. In the spirit of the current license I recommend looking at the BSD license without atribution. Try to search the different variants and pick the one that is closer to your wishes.
It's funny to make up a license, but does your license protect you of liabilities if a moron uses your software badly? What about if your library has a bug? Also, someone inside a company may prefer a usual license because the company lawyers had review the usual license, but an unusual license needs too many talk with the lawyers to get approved.
Edit:
To expand on that: I use someone else's benchmark since they have put effort into it, and already received feedback
For std::vector and binary search I performed multiple runs on several architectures, and did things like randomizing the benchmark order (which can have a big impact)
Thankyou for your questions. They made me go back and re-test
Saving vectors between runs and comparing their contents, changes things -- to the much more believable result of aArray being slower
Only comparing the array lengths, but not their contents probably let gcc optimize out assignmemnts for aArray, but not std::vector -- leading to an unfair test
Interestingly yes, std::vector now wins by a larger margin for int8_t arrays, and int64_t becomes a tighter match
-----
Note: I've updated the website to remove the 1/3 claim! But I can no-longer edit the title of this thread
The remaining stool legs of aArray are safety, simplicity, and being generic -- hopefully they don't get kicked out from under it quite so quickly ;^)
I didn't want press any downstream user with adding another BSD/MIT/CC-0/license or copyright notice to their code base
So the idea is that aArray is public domain and cc-0 and BSD and MIT and gpl and whatever you want -- simply delete the current license text and replace it with your own
-----
In general I'm not sure where I stand. For instance python's source contains several:
* Redistributions of source code/binary must retain the above copyright notice, this list of conditions and the following disclaimer...
So if an app uses python then must it reproduce what is quite a long list of licenses??
Nobody does, but code from those licenses are still present
7 comments
[ 2.8 ms ] story [ 24.2 ms ] threadUnder 'how/detail/THANKS': explains internals; graphs optimizations; chat about my life
Any feedback would be awesome ;)
I'd would be better to change the license to an standard license. In the spirit of the current license I recommend looking at the BSD license without atribution. Try to search the different variants and pick the one that is closer to your wishes.
It's funny to make up a license, but does your license protect you of liabilities if a moron uses your software badly? What about if your library has a bug? Also, someone inside a company may prefer a usual license because the company lawyers had review the usual license, but an unusual license needs too many talk with the lawyers to get approved.
And you're completely right, benchmarking is hard
Edit: To expand on that: I use someone else's benchmark since they have put effort into it, and already received feedback
For std::vector and binary search I performed multiple runs on several architectures, and did things like randomizing the benchmark order (which can have a big impact)
Complex struct is a good question
(Moreover, I'd add the graph in the overview page with a link to the complete discussion. I like graphs :) .)
Saving vectors between runs and comparing their contents, changes things -- to the much more believable result of aArray being slower
Only comparing the array lengths, but not their contents probably let gcc optimize out assignmemnts for aArray, but not std::vector -- leading to an unfair test
Interestingly yes, std::vector now wins by a larger margin for int8_t arrays, and int64_t becomes a tighter match
-----
Note: I've updated the website to remove the 1/3 claim! But I can no-longer edit the title of this thread
The remaining stool legs of aArray are safety, simplicity, and being generic -- hopefully they don't get kicked out from under it quite so quickly ;^)
I didn't want press any downstream user with adding another BSD/MIT/CC-0/license or copyright notice to their code base
So the idea is that aArray is public domain and cc-0 and BSD and MIT and gpl and whatever you want -- simply delete the current license text and replace it with your own
-----
In general I'm not sure where I stand. For instance python's source contains several:
* Redistributions of source code/binary must retain the above copyright notice, this list of conditions and the following disclaimer...
So if an app uses python then must it reproduce what is quite a long list of licenses??
Nobody does, but code from those licenses are still present