I just ran a bm <https://gist.github.com/bhavishyagopesh/ff0d9053bcd827aac4a594fec3d30ce4> that does this number_crunching task(serially), and results are->
py2: number_crunching: Mean +- std dev: 35.9 ms +- 1.0 ms py3: number_crunching: Mean +- std dev: 64.1 ms +- 4.1 ms And after turning *x to Long *in py2: number_crunching: Mean +- std dev: 168 ms +- 11 ms So what're your thoughts? thank you On Sat, Aug 12, 2017 at 5:02 AM, Bhavishya <bhavishyagop...@gmail.com> wrote: > Sorry but I realised that the actual bottleneck is with "range" (and > enumeration is slower in py3.) https://stackoverflow.com/ > questions/23453133/is-there-a-reason-python-3-enumerates- > slower-than-python-2.So it's not fair to say that multiprocessing is > slow... > > > On Sat, Aug 12, 2017 at 4:37 AM, Bhavishya <bhavishyagop...@gmail.com> > wrote: > >> Hello, >> >> WHY-> Presently there are no benchmarks for concurrency, >> >> METHOD USED-> This s >> <https://gist.github.com/bhavishyagopesh/76529e7bf170948b4d3f3a51f6e6bc9a>cript >> tries to benchmark "Concurrency" implemented using threading and >> multiprocessing module.Actually "threads" in cpython are restricted by >> "GIL",so it's not actually concurrent...On the other hand "multiprocessing" >> module creates whole different processes but there is substaintial cost >> involved in spawing a whole new process. >> So the there is a trade-off involved which is evident as we increase >> "CRUNCH_NO" variable. >> >> ToNote-> Interestingly Here py2 looks faster.(actually by a considerable >> margin) >> I'm attaching graphs that compare py2 and py3. >> >> IMPROVEMENTS-> More use cases(apart from number crunching)which could >> verify this and reproduce similar thing. >> >> SO Suggestions required? >> >> thank you. >> >> >> On Fri, Aug 11, 2017 at 4:09 AM, Victor Stinner <victor.stin...@gmail.com >> > wrote: >> >>> I don't understand what you are trying to test. For example, for a >>> lock, it's very different if a single thread uses the lock, or if two >>> threads use the lock. None of your benchmarks seem to measure >>> concurrency. >>> >>> Victor >>> >>> 2017-08-11 0:33 GMT+02:00 Bhavishya <bhavishyagop...@gmail.com>: >>> > Hello, >>> > >>> > I as a part of my gsoc project(and on suggestion from my mentor )tried >>> > writing a bencmark for threading module. >>> > It uses "perf" to measure crearion of objects like >>> Thread,Semaphore,Locks >>> > etc. and few methods on them but It might lack on experience and the >>> > correctness of doing so. >>> > >>> > Here's the bm . >>> > >>> > And here are the results of a run on my local machine [specs]: >>> > >>> > >>> > python3 bm_threading.py >>> > ..................... >>> > basic: Mean +- std dev: 14.4 us +- 0.4 us >>> > ..................... >>> > condition: Mean +- std dev: 18.1 ns +- 1.1 ns >>> > ..................... >>> > lock: Mean +- std dev: 18.1 ns +- 0.9 ns >>> > ..................... >>> > rlock: Mean +- std dev: 19.4 ns +- 1.6 ns >>> > ..................... >>> > semaphore: Mean +- std dev: 298 ns +- 56 ns >>> > ..................... >>> > timer: Mean +- std dev: 6.74 us +- 0.65 us >>> > >>> > >>> > >>> > python2 bm_threading.py >>> > ..................... >>> > basic: Mean +- std dev: 20.5 us +- 1.1 us >>> > ..................... >>> > condition: Mean +- std dev: 148 ns +- 2 ns >>> > ..................... >>> > lock: Mean +- std dev: 21.1 ns +- 0.7 ns >>> > ..................... >>> > rlock: Mean +- std dev: 151 ns +- 3 ns >>> > ..................... >>> > semaphore: Mean +- std dev: 336 ns +- 4 ns >>> > ..................... >>> > timer: Mean +- std dev: 12.5 us +- 0.7 us >>> > >>> > So suggestions? >>> > >>> > Thank You >>> > >>> > _______________________________________________ >>> > Speed mailing list >>> > Speed@python.org >>> > https://mail.python.org/mailman/listinfo/speed >>> > >>> >> >> >
_______________________________________________ Speed mailing list Speed@python.org https://mail.python.org/mailman/listinfo/speed