[Python-Dev] User + sys time bigger than real time, in case of no real parallelism

2017-02-04 Thread Marco Buttu
I am really sorry for the OT :-( I asked elsewhere but without any 
answer :-(
I can not figure out why in this short example the user+sys time is 
bigger than real time. The example executes the task() functions twice, 
with each execution in a separate thread. The task() just increment 
10**6 times a global int:


$ cat foo.py
from threading import Thread, Lock

result = 0
lock = Lock()

def task():
global result
for i in range(10**6):
lock.acquire()
result += 1
lock.release()

if __name__ == '__main__':
t1, t2 = Thread(target=task), Thread(target=task)
t1.start()
t2.start()
t1.join()
t2.join()
print('result:', result)

When I execute it (Python 3.6), I get a sys+user time bigger than the 
real time:


$ time python foo.py
result: 200

real   0m7.088s
user   0m6.597s
sys0m5.043s

That is usually what I can expect in case of tasks executed in parallel 
on different CPUs. But my example should not be the case, due to the 
GIL. What am I missing? Thank you very much, and sorry again for the OT :(


--
Marco Buttu

INAF-Osservatorio Astronomico di Cagliari
Via della Scienza n. 5, 09047 Selargius (CA)
Phone: 070 711 80 217
Email: mbu...@oa-cagliari.inaf.it

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Review request: optimizing typing ABC caches

2017-02-04 Thread Ivan Levkivskyi
There is a PR implementing typing ABC cache optimization:
https://github.com/python/typing/pull/383

The main idea is straightforward: subscripted generic ABCs like
Iterable[int], Iterable[str], etc. should not have separate ABC caches
(positive and negative), since they all are equivalent to plain Iterable at
runtime.

It is proposed that they will share their caches with a parent ABC from abc
module for abstract collections, or with original (unsubscripted) class
generic for concrete classes.

Inada-san confirmed that this optimization reduces the memory footprint.
I will be grateful for a code review.

Best regards,
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com