[Firebird-devel] New generated files
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. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Lock manager's hash calculations
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. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Lock manager's hash calculations
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 #ifdefs used here and there. This algorithm is used twice or thrice in our code, IIRC. > I suspect that "true hash" could make distribution of hash values more equival > and thus improve overall timing for lock table search. A couple of years ago I played a bit with different hash functions that are considered good nowadays. Quite surprisingly, none of them provided consistently better value distribution. > On the other hand, CS is going down, so lock manager performance may be not a > critical > part anymore? Maybe not, but hash tables may still be used in other places and they're quite important from the performance POV. For example, hash joins use the same hash function. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Lock manager's hash calculations
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. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Lock manager's hash calculations
>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 while* and performance does matter! Sean * the notion of support for clustered Firebird deployments is still very attractive to me -- especially with the mainstream availability of low latency RDMA NICs (Infiniband, RoCE, iWarp). Lock manager will be required those deployments. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Lock manager's hash calculations
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/ 12 > Isn't it bad? > If we have one chain with 12 objects, three empty chains and chains with 1, 2 or 3 objects - it's not bad. I.e. existing stat-s is not enough for analysis. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Lock manager's hash calculations
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 loop makes it 2-3 times > faster. Current code is even slower than CPU-accelerated CRC32. > Comments? Use of CPU-accelerated code appears suspicious from non-intel ports POV. What about unrolled loop - I like it. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Lock manager's hash calculations
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 "-O3
>> -msse4.2" shown that simple unroll of the loop makes it 2-3 times
>> faster. Current code is even slower than CPU-accelerated CRC32.
>>Comments?
> Use of CPU-accelerated code appears suspicious from non-intel ports POV.
> What about unrolled loop - I like it.
BTW, please try it in such form:
int hash_value = 0;
{ // scope
char* p;
const char* q = value;
int l = length;
while (l >= 4)
{
p = (char*) _value;
*p++ += *q++;
*p++ += *q++;
*p++ += *q++;
*p++ += *q++;
l -= 4;
}
p = (char*) _value;
if (l >= 2)
{
*p++ += *q++;
*p++ += *q++;
l -= 2;
}
if (l)
{
*p++ += *q++;
}
} // scope
For me (AMD CPU) it behaves much better for length in 11,15,19,etc.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Lock manager's hash calculations
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 use different algorithms for it. I suspect > that "true > hash" could make distribution of hash values more equival and thus improve > overall timing > for lock table search. This should be checked. At first one should show that current hash provides bad distribution. > On the other hand, CS is going down, so lock manager performance may be > not a critical > part anymore? > I suppose that users who need high reliability will continue with classic. I.e. it's usage will get lower but it will remain. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5053) changeServerMode.sh can mess with configuration
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 Affects Versions: 3.0 RC2 Environment: Linux Ubuntu 14.04 and 15.03 Reporter: Carlos H. Cantu Priority: Critical When trying to change a fresh installed Firebird 3.0 RC1 in a Gnome Linux Ubuntu (both 14.04 and 15.03) virtual machine (downloaded from osboxes.org), it fails or just behave incorrectly: With GUbuntu 15.03 - script fails (error: 1560: [: classic: unexpected operator) With GUbuntu 14.04 - script runs with no errors, but incorrectly sets the servermode parameter (ie: I asked for classic, but it set as super)... maybe it mess with other things too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Lock manager's hash calculations
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 than CPU-accelerated CRC32. Comments? -- WBR, SD. HashTest.cpp.7z Description: Binary data -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5055) Trace 2.5.x: allow database / alias patterns be case insensitive
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: Improvement Components: TRACEMGR Affects Versions: 2.5.5 Reporter: Pavel Zotov Priority: Trivial I have database which name was created in UPPERCASE (by ISQL 'create database host/port:dbnm' command): SQL> set list on; select mon$database_name from mon$database; MON$DATABASE_NAME C:\MIX\FIREBIRD\OLTPTEST\OLTP25.FDB When trace config for watching this database activities will begin from this line: -- no data will appear there. Pattern of database/alias seems to be Case Sensitive, it reuires in my case this:
Re: [Firebird-devel] Lock manager's hash calculations
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 list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5054) Increase length of trace patterns: include_filter, exclude_filter (currently they are only 256 characters on 2.5.x)
Increase length of trace patterns: include_filter, exclude_filter (currently
they are only 256 characters on 2.5.x)
---
Key: CORE-5054
URL: http://tracker.firebirdsql.org/browse/CORE-5054
Project: Firebird Core
Issue Type: Improvement
Components: TRACEMGR
Affects Versions: 2.5.5
Reporter: Pavel Zotov
Priority: Trivial
Following sample uses pattern in 'include_filter' which was generated auto, but
its length is limited exactly to 256 characters (from 1st character 's' after
"%(" and up to last character '1' before ")%"):
enabled true
time_threshold 0
include_filter
'%(sp_client_order|sp_cancel_client_order|sp_supplier_order|sp_cancel_supplier_order|sp_supplier_invoice|sp_cancel_supplier_invoice|sp_add_invoice_to_stock|sp_cancel_adding_invoice|sp_customer_reserve|sp_cancel_customer_reserve|sp_reserve_write_off|sp_test1231)%'
log_statement_finish true
print_perf true
max_sql_length = 16384
#connection_id 176
It will be nice if trace in 2.5.x allow to use patterns of arbitrary length
with bound ~32 or 64 K.
PS. No such problem in 3.0 (at least for the pattern with length ~500
characters).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
