Re: [Development] Proposal for "container-oriented deterministic memory manager"
On 01/05/2017 07:26 AM, Phil Bouchard wrote: Simon was mentioning that it would be preferable having root_ptr with an underlying mechanism to select memory pools based on the type allocated or the frequency of the allocation made. I don't see how it could be further optimized. After reading the following optimized memory pool documentation: https://github.com/cacay/MemoryPool I just realized how obvious it is. You just add some timer to determine the frequency, you measure the speed of the allocation requests and you "adapt" the memory chunks you allocate that will be later subdivided into the sizeof the type of the object. All of this type-oriented. So if you allocate 1,000,000 integers a second then larger memory blocks of sizeof(int) * 100 * CONSTANT will be allocated at once. I am cross-posting this message with the Boost mailing list because it is so evident. -Phil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for "container-oriented deterministic memory manager"
On 01/05/2017 03:09 PM, André Pönitz wrote: On Thu, Jan 05, 2017 at 07:57:54AM -0600, Thiago Macieira wrote: Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard escreveu: AFAIU QtQuickCompiler has nothing to do with memory management, its main purpose is reduction of start up time and obfuscation of sources. Ok I assumed that execution time would be affected because the code is compiled. The code is compiled anyway. The difference is only *when* it is compiled: at release time of your application or when your user launches it (JIT). It's not the only difference. A JIT compiler has typically not the same scope/abilities/optimization opportunities as a real compiler, not to mention deficiencies in a language that has 'double' as only numeric type. So "compiler" and "compiler" are apples and oranges in this case. Right, g++ is much more portable than JIT. JIT = Just Too Late (because it will start compiling the moment you need it) Correct. And done on each and every (often under-powered) device out there, if not even done on each and every application start, instand once when preparing binary packages. In Brave New World we would have the QtQuickCompiler running on the fly, followed by g++ and the browser could "dlopen" the generated library. I don't see any better solution than this. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for "container-oriented deterministic memory manager"
On Thu, Jan 05, 2017 at 07:57:54AM -0600, Thiago Macieira wrote: > Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard > escreveu: > > > AFAIU QtQuickCompiler has nothing to do with memory management, its main > > > purpose is reduction of start up time and obfuscation of sources. > > > > Ok I assumed that execution time would be affected because the code is > > compiled. > > The code is compiled anyway. The difference is only *when* it is compiled: at > release time of your application or when your user launches it (JIT). It's not the only difference. A JIT compiler has typically not the same scope/abilities/optimization opportunities as a real compiler, not to mention deficiencies in a language that has 'double' as only numeric type. So "compiler" and "compiler" are apples and oranges in this case. > JIT = Just Too Late (because it will start compiling the moment you need it) Correct. And done on each and every (often under-powered) device out there, if not even done on each and every application start, instand once when preparing binary packages. *sigh* Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] State of dev branch in CI
Hi, I wanted to give a quick update on the state of the dev branch in the CI: Currently any changes to any module outside of qtbase targeting the dev branch will fail to pass the build stage in the CI. Recently RHEL 7.2 was added to dev. When that was tested - back in fall last year - all was fine. Then some configure options of qtbase were changed (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer story but basically because of our binary packages). Earlier this week the change in the CI to add RHEL 7.2 to dev was taken into production and immediately broke the build of all modules in dev because -qt-pcre was not a valid configure parameter anymore and without qtbase nothing else builds. As a consequence the CI changes were reverted. Meanwhile the qtbase configure parameters were fixed and support for -qt-pcre was restored. Today the CI changes were taken in again and qtbase in the dev branch compiles on RHEL 7.2. Unfortunately all other modules are built against qtbase from qt5.git, which doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other than qtbase are broken in dev. An update of qt5.git with a newer qtbase is scheduled, but unfortunately it won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 . There are different options for solving this. One would be to revert the CI change. Another would be to fix the above bug and get the qt5 change through. The right solution to prevent these types of situations in the future is to have these platform configs inside qt5.git, not in the CI. Unfortunately that is not a priority yet. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On 05.01.2017 17:12, Edward Welbourne wrote: Sérgio Martins very helpfully linked to KCalendarSystem - thank you. One of the things we should clearly aim for is to make it easy for KCalendarSystem to (when its developers care to and can find the time, with no pressure to do so) adapt to use QCalendarSystem and the adapted QDate. TODO: I also need to find and talk to its maintainers. Maintainer for KCalenderSystem was John Layt. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Well, I've missed a long and lively discussion while I was away. I've
now caught up with e-mail, digested the thread and done some (but by no
means enough) background reading; that's left me with some jumbled
notes. This shall be long - let's start with the thread (and fit some
of those notes into answering it):
Soroush Rabiei:
>>> Please tell me more about your idea when you're back.
Take KCalendarSystem [0], replace its uses of QDate with a Julian day
number (as int [1]), tidy up a bit and have relevant Q(Date|Time)+
methods take one of these as an optional parameter (default: Gregorian)
that configures what they mean by things like year, month, week and day
within any of these.
[0]
https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKCalendarSystem.html
[1] I notice that QDate uses a qint64 for Julian day, which is overkill;
a 32-bit integral type lets us have 5,879,610 years each side of our
epoch, which is ample, IMO. KCalendarSystem seems to agree. QDate
can't change that for its data member, nor do I propose to change its
method signatures, but I see no reason for the calendar system to use
anything bigger than int for Julian dates.
Of course, BC/SC reasons mean "optional parameter" won't (until maybe Qt
6) be an added parameter (with a default) at the ends of existing
methods but a (probably first and non-optional) parameter of overloads
of the existing methods. Or something like that.
>>> I suppose adding new calendars by users, requires
>>> subclassing QDate?
A user calendar would be implemented by sub-classing the calendar system
virtual base class. Instances of that would be passed to methods of
(stock) QDate to over-ride its default use of Gregorian.
>>> Or maybe somehow extend the enum that contains calendar
>>> systems[?].
An enum can only support the calendar systems for which Qt contains
code. There shall always be calendars we don't support: it would be
best to ensure users can get support for that, one way or another. An
app-developer with enough users who want a particular calendar system
should be able to add support for it without waiting for us to care
about that calendar system.
>>> I think adding the information on which calendar system is
>>> current date is on, can be added as a member (handlre/enum)
>>> to QDate.
{Backwards,Source} Compatibility (BC/SC, above) issues preclude that.
Sune Vuorela:
>> I think you need to touch quite some of the 'inner bits' of
>> date / time
That's fine - messing with internals is OK, it's public A[BP]Is that
can't be changed - except by adding methods. Most of what I envisage us
changing for this would be turning some existing static functions in the
code into methods of a QGregorianCalendarSystem class, that implements
a generic QCalendarSystem API.
>> my two missing pet features:
>> - Partial dates
I'm quite sure these don't belong in Q(Date|Time)+, for all that I can
see their value in calendar (and similar) apps. There might be a case
for a recurrent event class, that supports all the funky things for
repeating calendar entries - e.g. the first Sunday following a full Moon
which falls on or after the Spring equinox, optionally with "full moon"
and/or "equinox" defined by some arbitrary set of rules rather than by
actual astronomical reality [2] - which would surely include partial
dates. I encourage you to think about designing that and would be happy
to review any contribution that results ;^>
[2] https://en.wikipedia.org/wiki/Computus
I did not just make that up.
>> - Date/time intervals/delta's.
Those I can see a better case for: they could be handled by operator-()
methods (with returns measured in the given units) of QDate (days),
QTime (milliseconds), QDateTime (milliseconds, 64-bit). No operator+;
use addDays(), addSeconds(), &c.
>> (by date/time deltas, I e.g. I started working somewhere on
>> november 1st 2014. and stopped january 3rd 2015. How long did
>> I work there)
Quite. Note, however, that KCalendarSystem::dateDifference() raises a
valid point for broken-down difference in days, months, years - which
need not equate to a simple number of days. [2016-03-01] - [2016-02-01]
is 29 days but the dateDifference is 1 month; while the same in 2017 is
28 days but still 1 month; and [2017-02-01] - [2016-02-01] is one year,
the same as [2017-05-01] - [2016-05-01], but the former is 366 days and
the latter is 365 days. Other calendar systems shall doubtless give
more such subtleties.
André Somers
> If memory serves me right: When, years ago, I tried to get the
> latter in, the work was a bit blocked because somebody else
> what working on... calendar support. :-)
If you can find either your patches for diff or their patches for
calendar support, I'm sure they'd be useful input to the present effort.
Ch'Gans (a.k.a. Chris):
Boost have
Re: [Development] Proposal to adjust release candidate process
On 04/01/2017 16:25, Frederik Gladhorn wrote: On tirsdag 3. januar 2017 08.02.21 CET Tuukka Turunen wrote: Hi, Perhaps it is best to talk with marketing about the name of the "release done immediately after branching to the .0 release branch". Reading the discussion, it seems that other than the name we are well aligned. I'd try to follow standards, this is supposed to be primarily understood by developers. semver is the most sensible thing I know of when it comes to versions. #11 is pretty sensible: http://semver.org/#spec-item-11 Yes a thousand times yes. tor arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for "container-oriented deterministic memory manager"
Em quinta-feira, 5 de janeiro de 2017, às 07:26:52 CST, Phil Bouchard escreveu: > > AFAIU QtQuickCompiler has nothing to do with memory management, its main > > purpose is reduction of start up time and obfuscation of sources. > > Ok I assumed that execution time would be affected because the code is > compiled. The code is compiled anyway. The difference is only *when* it is compiled: at release time of your application or when your user launches it (JIT). JIT = Just Too Late (because it will start compiling the moment you need it) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for "container-oriented deterministic memory manager"
On 01/05/2017 06:02 AM, Konstantin Tokarev wrote: 05.01.2017, 03:46, "Phil Bouchard" : On 01/02/2017 04:50 PM, Phil Bouchard wrote: On 12/29/2016 04:14 AM, Simon Hausmann wrote: Hi, Sorry for the delay... First I would like to point out this popular Javascript test runs 1.5 faster using Qt over WebKit: - ~100 FPS on my laptop (x86 @ 2.40GHz) using Chrome (WebKit): http://www.themaninblue.com/experiment/AnimationBenchmark/html/ - ~150 FPS on my laptop (x86 @ 2.40GHz) using Qt (without QtQuickCompiler): http://finitetheory.com/personal/phil/JSBenchmark.tar.gz - I am still waiting for the QtQuickCompiler request to be fulfilled but anybody who has it already is welcome to try it out and please let us know the results. For the record I was able to benchmark the QtQuickCompiler on a x86 @ 3.4 GHz and I get: ~250 FPS and without the QtQuickCompiler I get something similar; which means this is pretty much the maximum speed that test can get. AFAIU QtQuickCompiler has nothing to do with memory management, its main purpose is reduction of start up time and obfuscation of sources. Ok I assumed that execution time would be affected because the code is compiled. Note that measuring FPS above screen refresh rate (usually 60) does not make a lot of sense, as underlying graphics systems may not preserve it (and if vsync is enabled, screen refresh rate is a hard upper bound). You're right but I just wanted to have numbers. Simon was mentioning that it would be preferable having root_ptr with an underlying mechanism to select memory pools based on the type allocated or the frequency of the allocation made. I don't see how it could be further optimized. Does anybody have better memory management benchmarks I could focus on? Thanks a lot, -Phil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for "container-oriented deterministic memory manager"
05.01.2017, 03:46, "Phil Bouchard" : > On 01/02/2017 04:50 PM, Phil Bouchard wrote: >> On 12/29/2016 04:14 AM, Simon Hausmann wrote: >>> Hi, >> >> Sorry for the delay... >> >> First I would like to point out this popular Javascript test runs 1.5 >> faster using Qt over WebKit: >> >> - ~100 FPS on my laptop (x86 @ 2.40GHz) using Chrome (WebKit): >> http://www.themaninblue.com/experiment/AnimationBenchmark/html/ >> >> - ~150 FPS on my laptop (x86 @ 2.40GHz) using Qt (without QtQuickCompiler): >> http://finitetheory.com/personal/phil/JSBenchmark.tar.gz >> >> - I am still waiting for the QtQuickCompiler request to be fulfilled but >> anybody who has it already is welcome to try it out and please let us >> know the results. > > For the record I was able to benchmark the QtQuickCompiler on a x86 @ > 3.4 GHz and I get: ~250 FPS and without the QtQuickCompiler I get > something similar; which means this is pretty much the maximum speed > that test can get. AFAIU QtQuickCompiler has nothing to do with memory management, its main purpose is reduction of start up time and obfuscation of sources. Note that measuring FPS above screen refresh rate (usually 60) does not make a lot of sense, as underlying graphics systems may not preserve it (and if vsync is enabled, screen refresh rate is a hard upper bound). > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
