On quarta-feira, 23 de maio de 2012 04.54.11, bradley.hug...@nokia.com wrote:
On May 22, 2012, at 11:01 AM, ext Thiago Macieira wrote:
And I don't think they very much liked the idea of spinning while trying
to
acquire a lock (consumes power)... at least we have a call to
Hi Bradley,
And I don't think they very much liked the idea of spinning while trying to
acquire a lock (consumes power)... at least we have a call to
QThread::yieldCurrentThread(), though it would be interesting to see what
happens if we replace it with a PAUSE instruction.
Have you seen
On quarta-feira, 23 de maio de 2012 22.52.55, Carsten Breuer wrote:
Hi Bradley,
And I don't think they very much liked the idea of spinning while trying
to
acquire a lock (consumes power)... at least we have a call to
QThread::yieldCurrentThread(), though it would be interesting to see
Hi Thiago,
thanks for clearing this :-)
I guess it depends a bit on if you want to yield to another thread or
not ;-). Of course: burning cpu time is another way to solve this ;-)
According to the Intel manual, if you *don't* yield and you don't have the
PAUSE instruction, you may make
On quarta-feira, 23 de maio de 2012 23.44.57, Carsten Breuer wrote:
Hi Thiago,
thanks for clearing this :-)
I guess it depends a bit on if you want to yield to another thread or
not ;-). Of course: burning cpu time is another way to solve this ;-)
According to the Intel manual, if you
On May 21, 2012, at 2:58 PM, ext Thiago Macieira wrote:
On segunda-feira, 21 de maio de 2012 08.34.32, bradley.hug...@nokia.com wrote:
On May 18, 2012, at 8:34 PM, ext Thiago Macieira wrote:
Recommendations (priority):
(P0) de-inline QBasicMutex locking functions until we solve some or all
On terça-feira, 22 de maio de 2012 07.12.26, bradley.hug...@nokia.com wrote:
So far, we've got 3 votes for de-inlining: Thiago, Lars, and myself. For the
few cases where inlining matters, we can inline inside Qt at those
locations (QMetaObject::activate() would be the first place to check).
On May 22, 2012, at 11:01 AM, ext Thiago Macieira wrote:
And I don't think they very much liked the idea of spinning while trying to
acquire a lock (consumes power)... at least we have a call to
QThread::yieldCurrentThread(), though it would be interesting to see what
happens if we replace
On May 18, 2012, at 8:34 PM, ext Thiago Macieira wrote:
Recommendations (priority):
(P0) de-inline QBasicMutex locking functions until we solve some or all of
the
below problems
I agree with this, so that it gives a chance to fix the performance regressions
on Mac at a later date
On segunda-feira, 21 de maio de 2012 08.34.32, bradley.hug...@nokia.com wrote:
On May 18, 2012, at 8:34 PM, ext Thiago Macieira wrote:
Recommendations (priority):
(P0) de-inline QBasicMutex locking functions until we solve some or all of
the below problems
I agree with this, so that it
On domingo, 20 de maio de 2012 02.17.53, Olivier Goffart wrote:
On Saturday 19 May 2012 19:05:58 Thiago Macieira wrote:
On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote:
Hi,
Regarding valgrind:
*) On debug build, nothing is inlined.
*) If we keep it inline, then we
A few comments from my side:
* I am not a big fan of inlining the public classes neither. It feels a
bit like over-optimizing at the wrong place. Reason is that this might
make it a impossible later on to refactor our code.
* It's ok to have some low level inline class for internal use if that
On sábado, 19 de maio de 2012 00.36.56, Olivier Goffart wrote:
On Friday 18 May 2012 23:25:47 Thiago Macieira wrote:
Which non-negligible performance penalty are you takling about here?
The need to allocate memory and do the test-and-set loop for setting the
private.
There is no memory
On sábado, 19 de maio de 2012 07.30.56, lars.kn...@nokia.com wrote:
* it would be good to see how much of a real world (ie. not with
artificial benchmarks) difference you get due to inlining the mutex code.
Is it really relevant?
Here's a suggestion for one: the Creator C++ parser. I remember
On sábado, 19 de maio de 2012 10.26.03, Thiago Macieira wrote:
But fast uncontended case is critical because it allows the use of mutex
in
part that might or not be used with threads. Example: QObject. We need to
put mutexes while emiting a signal because maybe it is used in multiple
On Saturday 19 May 2012 07:30:56 lars.kn...@nokia.com wrote:
A few comments from my side:
* I am not a big fan of inlining the public classes neither. It feels a
bit like over-optimizing at the wrong place. Reason is that this might
make it a impossible later on to refactor our code.
In
Hi,
Regarding valgrind:
*) On debug build, nothing is inlined.
*) If we keep it inline, then we would just need a patch like this [1]
Regarding Transactional memory:
*) Very interesting
*) Notice the end of section 8.2.1: Improper use of hints will not cause
functional bugs though it
snip, QMutex future-direction-discussion
I've followed this very technical discussion from the beginning--
impressive array of topics. Thanks to all digging into this, and great
thanks to Thiago for opening the issue.
I have a question on the point of recursive-locks:
I understand
On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote:
Hi,
Regarding valgrind:
*) On debug build, nothing is inlined.
*) If we keep it inline, then we would just need a patch like this [1]
-fno-inline doesn't help because of -fvisibility-inlines-hidden. The call
cannot be rerouted
On sábado, 19 de maio de 2012 10.48.22, Charley Bay wrote:
snip, QMutex future-direction-discussion
I've followed this very technical discussion from the beginning--
impressive array of topics. Thanks to all digging into this, and great
thanks to Thiago for opening the issue.
I have a
On Saturday 19 May 2012 19:05:58 Thiago Macieira wrote:
On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote:
Hi,
Regarding valgrind:
*) On debug build, nothing is inlined.
*) If we keep it inline, then we would just need a patch like this [1]
-fno-inline doesn't help
On Sunday 20 May 2012 02:17:53 Olivier Goffart wrote:
You can see it works by trying the attached wrapper.c
Actually, I realize my implementation of the hook for tryLock was wrong as i
forgot the return value.
Fixed, just in case someone wants to use it.
--
Olivier
Woboq - Qt services and
On sexta-feira, 18 de maio de 2012 20.34.51, Thiago Macieira wrote:
(P1) expand the size of QBasicMutex and QMutex to accommodate more data,
for Mac and Windows. On Windows, the extra data required is one pointer (a
HANDLE), whereas on Mac it's a semaphore_t. Depending on the next task, we
On Friday 18 May 2012 20:34:51 Thiago Macieira wrote:
Hello
I've just completed a review of the QMutex family internals, as well as
the Intel optimisation manuals about threading, data sharing, locking and
the Transactional Memory extensions.
Short story: I recommend de-inlining QMutex
On sexta-feira, 18 de maio de 2012 22.45.22, Olivier Goffart wrote:
On Friday 18 May 2012 20:34:51 Thiago Macieira wrote:
Hello
I've just completed a review of the QMutex family internals, as well as
the Intel optimisation manuals about threading, data sharing, locking and
the
On Friday 18 May 2012 23:25:47 Thiago Macieira wrote:
QBasicMutex is an internal POD class that offers non-recursive locking.
It's incredibly efficient for Linux, where the single pointer-sized
member variable is enough to execute the futex operations, in all cases.
For other
26 matches
Mail list logo
