Hello, in fb_get_master_interface.pas I see:
===begin file
function fb_get_master_interface : IMaster; cdecl; external
'fbclient';
const
===end file
This "const" seems spurious. Didn't try to search where it comes from.
C.
---
Claudio Valderrama C.
Consultant, SW developer.
24.12.2015 17:58, Alex Peshkoff wrote:
> For me (AMD CPU) it behaves much better for length in 11,15,19,etc.
I have AMD too, so we need someone with Intel to see if these conditions
won't defeat
its jump prediction algorithms there.
--
WBR, SD.
24.12.2015 20:07, Dimitry Sibiryakov wrote:
>
> Yes. But in this case the hash is only used internally and not stored
> anywhere. Because
> of this, different platforms can use different algorithms for it.
Of course, but then it should be encapsulated and moved to /common to
avoid the same
24.12.2015 18:19, Alex Peshkoff wrote:
> This should be checked. At first one should show that current hash
> provides bad distribution.
In fb_lock_print output I often see something like this:
> Hash lengths (min/avg/max):0/ 2/ 12
Isn't it bad?
--
WBR, SD.
>On the other hand, CS is going down, so lock manager performance may be
> not a critical part anymore?
It will take groups like mine a while before they embrace the new SMP
functionality of v3 -- there is application/deployment testing to be
performed...
So, CS will be around for a
On 12/24/2015 08:24 PM, Dimitry Sibiryakov wrote:
> 24.12.2015 18:19, Alex Peshkoff wrote:
>> This should be checked. At first one should show that current hash
>> provides bad distribution.
> In fb_lock_print output I often see something like this:
>
>> Hash lengths (min/avg/max):0/ 2/
On 12/24/2015 04:19 PM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> I played a little with hash calculation code from lock manager and
> found that there is a room for improvement.
> Attached test program compiled by GCC 4.7.1 with switches "-O3
> -msse4.2" shown that simple unroll of the
On 12/24/2015 07:48 PM, Alex Peshkoff wrote:
> On 12/24/2015 04:19 PM, Dimitry Sibiryakov wrote:
>> Hello, All.
>>
>>I played a little with hash calculation code from lock manager and
>> found that there is a room for improvement.
>>Attached test program compiled by GCC 4.7.1 with switches
On 12/24/2015 08:07 PM, Dimitry Sibiryakov wrote:
> 24.12.2015 17:48, Alex Peshkoff wrote:
>> Use of CPU-accelerated code appears suspicious from non-intel ports POV.
> Yes. But in this case the hash is only used internally and not stored
> anywhere. Because
> of this, different platforms can
changeServerMode.sh can mess with configuration
---
Key: CORE-5053
URL: http://tracker.firebirdsql.org/browse/CORE-5053
Project: Firebird Core
Issue Type: Bug
Components: Installation
Hello, All.
I played a little with hash calculation code from lock manager and found that there is
a room for improvement.
Attached test program compiled by GCC 4.7.1 with switches "-O3 -msse4.2" shown that
simple unroll of the loop makes it 2-3 times faster. Current code is even slower
Trace 2.5.x: allow database / alias patterns be case insensitive
-
Key: CORE-5055
URL: http://tracker.firebirdsql.org/browse/CORE-5055
Project: Firebird Core
Issue Type:
24.12.2015 14:19, Dimitry Sibiryakov wrote:
> simple unroll of the loop makes it 2-3 times faster.
Actually, even replace of USHORT with ULONG in the loop wins about 15%.
--
WBR, SD.
--
Firebird-Devel mailing
Increase length of trace patterns: include_filter, exclude_filter (currently
they are only 256 characters on 2.5.x)
---
Key: CORE-5054
URL:
14 matches
Mail list logo
