> On Sun, 28 Mar 2004, "Samofatov, Nickolay"
> <Nickolay@...> wrote:
> > Bad design of old allocator caused engine to spend several days or=20
> > weeks in a foolish "best fit" loop instead of a few couple=20
> seconds for=20
> > some common workloads. Both Mike and I did performance=20
> measurements at=20
> > appropriate point of time.
> > This is how it works in Firebird now. It has some costs,=20
> but unrolled=20
> > loops allow to have acceptable performance due to low=20
> levels of branch=20
> > mispredition, Arno profiled it.
> > This is the place of the engine where each couple assembler=20
> > instructions accounts for ~1% time overall performance for=20
> indexed queries.
> Performance measurement is notoriously tricky, subject to=20
> arcane compiler settings, idiosyncrasies in hardware=20
> architecture, and data domain. When you made these=20
> determinations, did you publish your methods and findings in=20
> any way, so that they could be independently evaluated and=20
For first case measurement is simple. Just try to update 10000000 rows
in one procedure 2 times.
This should take approx. 24 hours in FB 1.0.3 and a few minutes on FB
1.5 or 2.0 depending on your machine speed and record length of course.
There were 2 silly loops causing this behavior (one in VIO and one in
memory manager) so you may enable/disable each fix and see which gives
better effect and play with different/mixed record lengths.
I have better things to do now, sorry. :)
> I'm particularly skeptical of unrolled loops. Against branch=20
> misprediction there is the benefit of fitting the processor=20
> cache. I would expect different trade-offs for RISC and CISC=20
> machines. It's my understanding that nowadays, for that=20
> reason, i386 optimization is always optimize-for-size. I=20
> have read that's one thing Microsoft and the Linux kernel agree on. =20
Arno profiled it on x86, but branch predition logic is simular on all
platforms. Unrolling the loops in code decoding numbers made
considerable performance improvements.
BTW, some of that findings were published in fb-devel, you may search.
Contact Arno if you have practical interest in this topic.