Choosing helper C++ libraries for interop.

[Vladimir Ozerov]

Igniters,

In upcoming interop efforts we will need concurrent collections and
primitives in C++ layer. Obvious candidate is Boost, but it appears to be
too heavy. Another library I found is Intel's TBB (
https://www.threadingbuildingblocks.org/) - it is open-source and pretty
light.

Does anyone has other ideas on this?

Vladimir.

[Pavel Tupitsyn-3]

Hi,

I vote for Boost. From my understanding, it is the most comprehensive
extension library, and very widely adopted.

What do you mean by "too heavy"?

   - Did you try to use it and compare dll sizes? How big is the difference?
   - Does dll size really matter for us that much?

Thanks,

On Wed, May 20, 2015 at 9:20 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Igniters,
>
> In upcoming interop efforts we will need concurrent collections and
> primitives in C++ layer. Obvious candidate is Boost, but it appears to be
> too heavy. Another library I found is Intel's TBB (
> https://www.threadingbuildingblocks.org/) - it is open-source and pretty
> light.
>
> Does anyone has other ideas on this?
>
> Vladimir.
>

--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

[Vladimir Ozerov]

This is not about resulting size of our lib. Moreover, we will not
statically link it to Ignite because in this case users will have troubles
when using both Boost and Ignite simultaneously.
The problem is that if we use Boost, we will force users to have it on
their machines during both build-time and runtime. And Boost is known to
have dready dependencies between their modules. So if we use only
concurrency module it might lead to transitive dependencies to lots other
ones.

On Wed, May 20, 2015 at 9:46 AM, Pavel Tupitsyn <[hidden email]>
wrote:

> Hi,
>
> I vote for Boost. From my understanding, it is the most comprehensive
> extension library, and very widely adopted.
>
> What do you mean by "too heavy"?
>
>    - Did you try to use it and compare dll sizes? How big is the
> difference?
>    - Does dll size really matter for us that much?
>
> Thanks,
>
> On Wed, May 20, 2015 at 9:20 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igniters,
> >
> > In upcoming interop efforts we will need concurrent collections and
> > primitives in C++ layer. Obvious candidate is Boost, but it appears to be
> > too heavy. Another library I found is Intel's TBB (
> > https://www.threadingbuildingblocks.org/) - it is open-source and pretty
> > light.
> >
> > Does anyone has other ideas on this?
> >
> > Vladimir.
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>

[Branko Čibej]

On 20.05.2015 09:40, Vladimir Ozerov wrote:
> This is not about resulting size of our lib. Moreover, we will not
> statically link it to Ignite because in this case users will have troubles
> when using both Boost and Ignite simultaneously.
> The problem is that if we use Boost, we will force users to have it on
> their machines during both build-time and runtime. And Boost is known to
> have dready dependencies between their modules. So if we use only
> concurrency module it might lead to transitive dependencies to lots other
> ones.

Using any part of Boost also increases compile times dramatically
because if its inter-module dependencies and its heavy usage of template
programming.


The first step is to design an API, before deciding on a helper library,
which you may not even need. Talking about Boost or TBB or whatnot
before you even know what kind of features you need to implement your
API is, to put it mildly, just crazy.

Real Programmers do not download 11 jars to use one external method ...

-- Brane

[Vladimir Ozerov]

Brane,
I do not know in advance what exactly will be needed there, but it is
_very_ likley that we will need thread-locals, atomics (both CAS and
increments/decrements), java-like volatiles (i.e. membars), cirical
sections, read-write locks and concurrent dictionaries.

On Wed, May 20, 2015 at 12:27 PM, Branko Čibej <[hidden email]> wrote:

> On 20.05.2015 09:40, Vladimir Ozerov wrote:
> > This is not about resulting size of our lib. Moreover, we will not
> > statically link it to Ignite because in this case users will have
> troubles
> > when using both Boost and Ignite simultaneously.
> > The problem is that if we use Boost, we will force users to have it on
> > their machines during both build-time and runtime. And Boost is known to
> > have dready dependencies between their modules. So if we use only
> > concurrency module it might lead to transitive dependencies to lots other
> > ones.
>
> Using any part of Boost also increases compile times dramatically
> because if its inter-module dependencies and its heavy usage of template
> programming.
>
>
> The first step is to design an API, before deciding on a helper library,
> which you may not even need. Talking about Boost or TBB or whatnot
> before you even know what kind of features you need to implement your
> API is, to put it mildly, just crazy.
>
> Real Programmers do not download 11 jars to use one external method ...
>
> -- Brane
>

[yzhdanov]

Brane, the API has already been designed. In the best case all
functionality available in Java should be available in non-Java stuff (if
there are no technology limitations). I would not care about compile time -
Boost increases it, of course, but does not make compilation infinite.
Functionality, stability and developer convenience seem to be more
important.

GridGain had its CPP stuff using Boost with ~4-5 min compilation on rather
weak machine.

However, given that client will be completely reapproached and should be
less complex I would think whether we need any third party library at all.

--Yakov

2015-05-20 12:27 GMT+03:00 Branko Čibej <[hidden email]>:

> On 20.05.2015 09:40, Vladimir Ozerov wrote:
> > This is not about resulting size of our lib. Moreover, we will not
> > statically link it to Ignite because in this case users will have
> troubles
> > when using both Boost and Ignite simultaneously.
> > The problem is that if we use Boost, we will force users to have it on
> > their machines during both build-time and runtime. And Boost is known to
> > have dready dependencies between their modules. So if we use only
> > concurrency module it might lead to transitive dependencies to lots other
> > ones.
>
> Using any part of Boost also increases compile times dramatically
> because if its inter-module dependencies and its heavy usage of template
> programming.
>
>
> The first step is to design an API, before deciding on a helper library,
> which you may not even need. Talking about Boost or TBB or whatnot
> before you even know what kind of features you need to implement your
> API is, to put it mildly, just crazy.
>
> Real Programmers do not download 11 jars to use one external method ...
>
> -- Brane
>

[Branko Čibej]

There is one thing you could do, depending on which parts of Boost you
need. Boost has a tool to extract only the headers you actually need and
puts the extracted declarations into a custom namespace. If your
dependencies are header-only, you can include those bits in the Ignite
sources. That way, users won't have to install Boost, and it avoids
version mismatch and DLL hell.

-- Brane

On 20.05.2015 15:53, Yakov Zhdanov wrote:

> Brane, the API has already been designed. In the best case all
> functionality available in Java should be available in non-Java stuff (if
> there are no technology limitations). I would not care about compile time -
> Boost increases it, of course, but does not make compilation infinite.
> Functionality, stability and developer convenience seem to be more
> important.
>
> GridGain had its CPP stuff using Boost with ~4-5 min compilation on rather
> weak machine.
>
> However, given that client will be completely reapproached and should be
> less complex I would think whether we need any third party library at all.
>
> --Yakov
>
> 2015-05-20 12:27 GMT+03:00 Branko Čibej <[hidden email]>:
>
>> On 20.05.2015 09:40, Vladimir Ozerov wrote:
>>> This is not about resulting size of our lib. Moreover, we will not
>>> statically link it to Ignite because in this case users will have
>> troubles
>>> when using both Boost and Ignite simultaneously.
>>> The problem is that if we use Boost, we will force users to have it on
>>> their machines during both build-time and runtime. And Boost is known to
>>> have dready dependencies between their modules. So if we use only
>>> concurrency module it might lead to transitive dependencies to lots other
>>> ones.
>> Using any part of Boost also increases compile times dramatically
>> because if its inter-module dependencies and its heavy usage of template
>> programming.
>>
>>
>> The first step is to design an API, before deciding on a helper library,
>> which you may not even need. Talking about Boost or TBB or whatnot
>> before you even know what kind of features you need to implement your
>> API is, to put it mildly, just crazy.
>>
>> Real Programmers do not download 11 jars to use one external method ...
>>
>> -- Brane
>>