Re: [Firebird-devel] Atomics

[Vlad Khorsun]

23.03.2016 16:59, Jim Starkey wrote:
> On 3/23/2016 5:04 AM, Vlad Khorsun wrote:
>>  All,
>>
>> in new codebase (v4) we going to use atomic operations more intensively than
>> before. The question is: could we use standard features of C++11 or should
>> choose some 3rd party library (such as libatomic_ops) for it ?
>>
>>  The main concern about C++11 atomics is - if all platforms where 
>> Firebird
>> can be built have support for it (by software and hardware) ? We have no
>> problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11 
>> atomics)
>> but i have no idea about MAC\HP\AIX\ARM and other...
>>
>>
>
> What's the rush?  You may find important compilers that don't support it
> or have garbage implementations.

   There is not rush. But such changes better to do now, then at release 
candidate
stage.

> The reasonable way to handle atomics is for project defined macros on
> whatever facilities the various platforms expose.  When I originally
> wrote SyncObject, I had to use in-line assemble everywhere.  The
> Microsoft implemented satisfactory compiler intrinsics (OK, not strictly
> portable between 32 and 64 bits, but workable).  Later, gcc got around
> to implementing compiler intrinsics and I was able to ditch the last
> remaining inline assembler.  Lately, I was pleased to discovered that
> gcc on ARM supports the same intrinsic COMPARE_AND_SWAP even though the
> underlying hardware didn't.

   Life is more complex than plain CAS. There is different memory ordering
supported by hardware and one single CAS is not effective (at least).

> Defining your own macro layer gives you cheap portability and a zero
> overhead implementation.  With C++11, you may be stuck with a high
> overhead library runtime call written by somebody who didn't really
> understand the hardware instructions, just like the rancid STL garbage
> for its first half dozen years.
>
> Personally, I haven't a clue what the original macros got replaced with
> template that called platform specific implementations.  A macro would
> have compile as one or two machine instructions rather than a number of
> nested called.  Strikes me as a way to introduce unnecessary complexity
> at a significant cost in performance.
>
> Personally, I'm quite happy with macros that hide platform differences.
> If I ever decide that I care about C++11 and its implementation is
> decent on the platform I care about, I'd redefine the macros to the new
> feature.  But I wouldn't see any reason to change the existing code.
>
> Firebird 3 took (will take?) way too long to ship.  One way to help
> streamline releases is to minimize unnecessary dependencies. Building a
> completely unnecessary dependency on C++11 may be one of the solutions
> to non-problems that will turn around and bite you.

   I prefer to have dependancy on standard feature than on 3rd party library
or self-made macros...

Regards,
Vlad



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Jim Starkey]

On 3/23/2016 1:18 PM, Michal Kubecek wrote:
> On Wed, Mar 23, 2016 at 10:59:20AM -0400, Jim Starkey wrote:
>> Defining your own macro layer gives you cheap portability and a zero
>> overhead implementation.
> That's one side of it. The other is that for occasional contributors or
> distribution support guys, it brings a lot of confusion. Like when you
> find out that ULONG is in fact not unsigned long as one would expect
> from the name but rather what standard calls uint32_t). Or when you
> learn that instead of a standard library function you are supposed to
> use this compatibility wrapper. Regular contributors have learned these
> and got used to it; for newcomers, it can be tough at times.

Frankly, the idea of an occasional contributed messing around with 
non-interlocked data structures is remarkably scary.  Anyone who is 
troubled by COMPARE_AND_SWAP or COMPARE_EXCHANGE should be anywhere near 
them.

Now that Microsoft accepts the standard artificial integer types, it's 
probably time to do a couple of global replaces and replace things like 
ULONG with standard artificial types.  I created ULONG a couple of 
decades before stdint.h existed and even longer before Visual Studio 
could handle both stdint.h and Microsoft includes. This is just normal 
project maintenance.

>
> The portability you mention is nice but it's paid for by readability and
> maintainability of the code. Most of the stuff is historical and it
> would be unwise to rush into weeding it out. But we should think twice
> before adding more.
>
> 

With a code base so rife with casts as Firebird, it's hard to make a 
legitimate argument for readability.  If anyone cared about readability, 
the code would reworked to be type safe.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Michal Kubecek]

On Wed, Mar 23, 2016 at 10:59:20AM -0400, Jim Starkey wrote:
> 
> Defining your own macro layer gives you cheap portability and a zero 
> overhead implementation.

That's one side of it. The other is that for occasional contributors or
distribution support guys, it brings a lot of confusion. Like when you
find out that ULONG is in fact not unsigned long as one would expect
from the name but rather what standard calls uint32_t). Or when you
learn that instead of a standard library function you are supposed to
use this compatibility wrapper. Regular contributors have learned these
and got used to it; for newcomers, it can be tough at times.

The portability you mention is nice but it's paid for by readability and
maintainability of the code. Most of the stuff is historical and it
would be unwise to rush into weeding it out. But we should think twice
before adding more.

  Michal Kubecek

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Dimitry Sibiryakov]

23.03.2016 14:05, Alex Peshkoff wrote:
> Telling true I suppose both will add atomic support to the moment of FB4
> release.
> But as long as they did not...
> I suppose we keep our AtomicPointer and AtomicCounter, just implement
> them internally using C++11. For existing 2 exceptions we keep #ifdef's
> for a while, when they are fixed we may cleanup them.

   May be contrary would be better: use std::atomic everywhere and for these 
two 
exceptions emulate it with an  header somewhere in 
include/firebird/impl used as a 
last include dir in list?
   It would keep main codebase cleaner and better readable for outsiders.

-- 
   WBR, SD.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Jim Starkey]

On 3/23/2016 5:04 AM, Vlad Khorsun wrote:
> All,
>
> in new codebase (v4) we going to use atomic operations more intensively than
> before. The question is: could we use standard features of C++11 or should
> choose some 3rd party library (such as libatomic_ops) for it ?
>
> The main concern about C++11 atomics is - if all platforms where Firebird
> can be built have support for it (by software and hardware) ? We have no
> problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11 atomics)
> but i have no idea about MAC\HP\AIX\ARM and other...
>
>

What's the rush?  You may find important compilers that don't support it 
or have garbage implementations.

The reasonable way to handle atomics is for project defined macros on 
whatever facilities the various platforms expose.  When I originally 
wrote SyncObject, I had to use in-line assemble everywhere.  The 
Microsoft implemented satisfactory compiler intrinsics (OK, not strictly 
portable between 32 and 64 bits, but workable).  Later, gcc got around 
to implementing compiler intrinsics and I was able to ditch the last 
remaining inline assembler.  Lately, I was pleased to discovered that 
gcc on ARM supports the same intrinsic COMPARE_AND_SWAP even though the 
underlying hardware didn't.

Defining your own macro layer gives you cheap portability and a zero 
overhead implementation.  With C++11, you may be stuck with a high 
overhead library runtime call written by somebody who didn't really 
understand the hardware instructions, just like the rancid STL garbage 
for its first half dozen years.

Personally, I haven't a clue what the original macros got replaced with 
template that called platform specific implementations.  A macro would 
have compile as one or two machine instructions rather than a number of 
nested called.  Strikes me as a way to introduce unnecessary complexity 
at a significant cost in performance.

Personally, I'm quite happy with macros that hide platform differences.  
If I ever decide that I care about C++11 and its implementation is 
decent on the platform I care about, I'd redefine the macros to the new 
feature.  But I wouldn't see any reason to change the existing code.

Firebird 3 took (will take?) way too long to ship.  One way to help 
streamline releases is to minimize unnecessary dependencies. Building a 
completely unnecessary dependency on C++11 may be one of the solutions 
to non-problems that will turn around and bite you.





--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Alex Peshkoff]

On 03/23/2016 01:55 PM, Vlad Khorsun wrote:
> 23.03.2016 11:19, Alex Peshkoff wrote:
>> On 03/23/2016 12:04 PM, Vlad Khorsun wrote:
>>>   All,
>>>
>>> in new codebase (v4) we going to use atomic operations more intensively than
>>> before. The question is: could we use standard features of C++11 or should
>>> choose some 3rd party library (such as libatomic_ops) for it ?
>>>
>>>   The main concern about C++11 atomics is - if all platforms where 
>>> Firebird
>>> can be built have support for it (by software and hardware) ? We have no
>>> problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11 
>>> atomics)
>>> but i have no idea about MAC\HP\AIX\ARM and other...
>>>
>>>   Opinions ?
>> Looking at this table:
>> http://en.cppreference.com/w/cpp/compiler_support
>> looks like we may safely switch to use of c++11 atomics support.
>
> It shows no support for c++11 atomics by HP aCC and IBM XLC++ (except of 
> Linux).

Damned  - I did not notice '*' near IBM XLC and read HP aCC as something 
like hppa (which we d not support any more, it's obvious that on hppa 
it's hard to have good atomic support).

> Is it a problem for us ?

Telling true I suppose both will add atomic support to the moment of FB4 
release.
But as long as they did not...
I suppose we keep our AtomicPointer and AtomicCounter, just implement 
them internally using C++11. For existing 2 exceptions we keep #ifdef's 
for a while, when they are fixed we may cleanup them.



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Paul Beach]

> < Linux).
> Is it a problem for us ?>>
>
> An interesting question, I do know of a few users who continue to use AIX and 
> HPUX and
> who actively build on 2.5... Will we still have AIX and HPUX users by the 
> time we release
> Firebird 4.0 - I don't know.

   <>

Just an observation.

Currently GCC on AIX produces awful debug versions of Firebird, that in effect 
are useless
for analysing crash dumps etc, only XLC seems to work properly for this.

Paul

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Dimitry Sibiryakov]

23.03.2016 12:18, Paul Beach wrote:
> < Linux).
> Is it a problem for us ?>>
>
> An interesting question, I do know of a few users who continue to use AIX and 
> HPUX and
> who actively build on 2.5... Will we still have AIX and HPUX users by the 
> time we release
> Firebird 4.0 - I don't know.

   Google says that AIX and HPUX are supported by GCC. It means that FB4 may be 
cannot 
build with HP aCC and IBM XLC++, but GCC still could be still used for 
compilation on 
these OSes.

-- 
   WBR, SD.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Paul Beach]

>> in new codebase (v4) we going to use atomic operations more intensively than
>> before. The question is: could we use standard features of C++11 or should
>> choose some 3rd party library (such as libatomic_ops) for it ?
>>
>>  The main concern about C++11 atomics is - if all platforms where 
>> Firebird
>> can be built have support for it (by software and hardware) ? We have no
>> problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11 
>> atomics)
>> but i have no idea about MAC\HP\AIX\ARM and other...
>>
>>  Opinions ?
>
> Looking at this table:
> http://en.cppreference.com/w/cpp/compiler_support
> looks like we may safely switch to use of c++11 atomics support.

<>

An interesting question, I do know of a few users who continue to use AIX and 
HPUX and
who actively build on 2.5... Will we still have AIX and HPUX users by the time 
we release
Firebird 4.0 - I don't know.

Paul

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Vlad Khorsun]

23.03.2016 11:19, Alex Peshkoff wrote:
> On 03/23/2016 12:04 PM, Vlad Khorsun wrote:
>>  All,
>>
>> in new codebase (v4) we going to use atomic operations more intensively than
>> before. The question is: could we use standard features of C++11 or should
>> choose some 3rd party library (such as libatomic_ops) for it ?
>>
>>  The main concern about C++11 atomics is - if all platforms where 
>> Firebird
>> can be built have support for it (by software and hardware) ? We have no
>> problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11 
>> atomics)
>> but i have no idea about MAC\HP\AIX\ARM and other...
>>
>>  Opinions ?
>
> Looking at this table:
> http://en.cppreference.com/w/cpp/compiler_support
> looks like we may safely switch to use of c++11 atomics support.


   It shows no support for c++11 atomics by HP aCC and IBM XLC++ (except of 
Linux).
Is it a problem for us ?

Regards,
Vlad

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Paul Beach]

>

Having just checked - Clang (LLVM) 3.5 is installed via XCode on my Mac.
So thats OK.

Paul

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Alex Peshkoff]

On 03/23/2016 12:04 PM, Vlad Khorsun wrote:
> All,
>
> in new codebase (v4) we going to use atomic operations more intensively than
> before. The question is: could we use standard features of C++11 or should
> choose some 3rd party library (such as libatomic_ops) for it ?
>
> The main concern about C++11 atomics is - if all platforms where Firebird
> can be built have support for it (by software and hardware) ? We have no
> problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11 atomics)
> but i have no idea about MAC\HP\AIX\ARM and other...
>
> Opinions ?

Looking at this table:
http://en.cppreference.com/w/cpp/compiler_support
looks like we may safely switch to use of c++11 atomics support.



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Dimitry Sibiryakov]

23.03.2016 10:13, Alex Peshkoff wrote:
> The question was to people who aware - do compilers on MAC\HP\AIX\ARM
> support C++11 atomics? If yes - absolutely no need in additional library.

   If these platforms don't support atomic ops, they have to emulate standard 
somehow. Or 
to be dropped from list of supported.
   AFAIK, GCC provide standard library on all supported platform.

-- 
   WBR, SD.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Alex Peshkoff]

On 03/23/2016 12:06 PM, Dimitry Sibiryakov wrote:
> 23.03.2016 10:04, Vlad Khorsun wrote:
>>  Opinions ?
> I vote for C++11 standard.
>

That's not parliament to vote:)
The question was to people who aware - do compilers on MAC\HP\AIX\ARM 
support C++11 atomics? If yes - absolutely no need in additional library.


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Atri Sharma]

+1 for a cross platform library

On Wed, Mar 23, 2016 at 2:34 PM, Vlad Khorsun 
wrote:

>All,
>
> in new codebase (v4) we going to use atomic operations more intensively
> than
> before. The question is: could we use standard features of C++11 or should
> choose some 3rd party library (such as libatomic_ops) for it ?
>
>The main concern about C++11 atomics is - if all platforms where
> Firebird
> can be built have support for it (by software and hardware) ? We have no
> problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11
> atomics)
> but i have no idea about MAC\HP\AIX\ARM and other...
>
>Opinions ?
>
> Thanks,
> Vlad
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>



-- 
Regards,

Atri
*l'apprenant*
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Atomics

[Dimitry Sibiryakov]

23.03.2016 10:04, Vlad Khorsun wrote:
> Opinions ?

   I vote for C++11 standard.

-- 
   WBR, SD.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] Atomics

[Vlad Khorsun]

   All,

in new codebase (v4) we going to use atomic operations more intensively than
before. The question is: could we use standard features of C++11 or should
choose some 3rd party library (such as libatomic_ops) for it ?

   The main concern about C++11 atomics is - if all platforms where Firebird
can be built have support for it (by software and hardware) ? We have no
problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11 atomics)
but i have no idea about MAC\HP\AIX\ARM and other...

   Opinions ?

Thanks,
Vlad

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel