[vtk-developers] Checking SMP backend at runtime/compiletime?

Wed Feb 10 10:46:32 EST 2016

Hi Steve,

* The default path will be OpenMP.
* If your compiler does not support OpenMP, you will need TBB.
* If you don't like the performance of OpenMP, you will need TBB.

Hopefully, in 1-2 years all compilers will support OpenMP 3.1 or greater so
this will be a moot point. We don't plan on removing the multi-threader
path tomorrow. Currently, VS supports OpenMP 2, which is totally lame. So
that's fishy. I am confident that Clang/LLVM will have the necessary OpenMP
support before we remove the vtkMultiThreader implementation. So VS users
may need an Intel compiler or use TBB unless MS improves its OpenMP support
in a couple years.

Given the direction multi/many core is going, low-level thread management
in VTK is a thing of the past. On an Intel KNL processor, soon to be
available commercially, good performance will require > 200 threads + 16x2
wide vector processing. We can't sit on legacy parallel implementation to
properly utilize these processors.

Also, please stop the lawyer talk and the nitpicking about the runtime
exception. People have been shipping commercial products that utilize
libraries with this license for decades without any issues. Furthermore,
Intel's intent is clear - they want to enable the sale of their processors
- and this is the way they decided to enable it. It is entirely illogical
to think that they will then pursue legal action and scare everyone off
TBB. If you don't like the TBB license, use OpenMP. Or you are free to
implement your own backend outside VTK (the design makes it very easy).

PS: We will likely ship all of our binaries with TBB as it gives the best
performance currently.

Best,
-berk

On Wed, Feb 10, 2016 at 10:02 AM, Steve Pieper <pieper at isomics.com> wrote:

> Hi Ken -
>
> I agree with Andras that this needs to be carefully considered.  We rely
> on the robustness and consistency of the multithreader and it maxes out our
> processors for important use cases.  Having other options is good, but not
> if it takes away what already works.
>
> The no-GPL rule has been very important to the success of VTK and ITK.
> I'm not a lawyer either, but libstc++ and the linux kernel are very
> different because you typically don't ship them with the software because
> the user has their own copy.  Also the TBB "runtime exception specifically"
> says it only applies to a "free software library" which it doesn't define
> [1].  A very common interpretation of "free software library" would be that
> it means other GPL libraries (at least that's what the FSF and RMS would
> likely say it means).
>
> I don't mind the option of linking to TBB, but I wouldn't want to see that
> be the default path.
>
> -Steve
>
> [1] https://www.threadingbuildingblocks.org/licensing#runtime-exception
>
> On Wed, Feb 10, 2016 at 9:50 AM, Moreland, Kenneth <kmorel at sandia.gov>
> wrote:
>
>> Andreas,
>>
>> I am not a lawyer, so I make no claims to my expertise in this, but I'm
>> pretty sure you should be ok. Looking at that same FAQ link you sent is
>> this:
>>
>> Intel® TBB is available under the common open-source software license,
>> GPLv2 with the (libstdc++) runtime exception. Specifically, the Intel® TBB
>> open-source license is exactly the same as that used by the libstdc++ in
>> gcc 4.2.1 (and earlier). GPLv2 is the same license used for a variety of
>> well-known OSS applications including MySQL, NetBeans, and the Linux
>> kernel. - See more at:
>> https://www.threadingbuildingblocks.org/faq/10#sthash.IQJJn2NB.dpuf
>>
>> So, you if you feel comfortable compiling your code with gcc, you shod be
>> fine.
>>
>> -Ken
>>
>> Sent from my iPad so blame autocorrect.
>>
>> On Feb 9, 2016, at 5:14 PM, Andras Lasso <lasso at queensu.ca> wrote:
>>
>> Intel TBB price: https://software.intel.com/en-us/intel-tbb/try-buy
>>
>>
>>
>> Although the https://www.threadingbuildingblocks.org/faq/10 page tries
>> to clarify dual licensing, it’s still not fully clear for me if there is
>> any catch in the open-source license.
>>
>>
>>
>> Can you confirm that TBB in VTK can be used in a commercial software
>> without any restrictions (paying licensing fees, disclosing source code,
>> etc)?
>>
>>
>>
>> Andras
>>
>>
>>
>> *From:* Moreland, Kenneth [mailto:kmorel at sandia.gov <kmorel at sandia.gov>]
>> *Sent:* February 9, 2016 6:32 PM
>> *To:* Andras Lasso <lasso at queensu.ca>; Geveci, Berk (External Contact) <
>> berk.geveci at kitware.com>; Ken Martin <ken.martin at kitware.com>
>> *Cc:* VTK Developers <vtk-developers at vtk.org>; David Gobbi <
>> david.gobbi at gmail.com>
>> *Subject:* Re: [vtk-developers] Checking SMP backend at
>> runtime/compiletime?
>>
>>
>>
>> $700? TBB is open-source, GPLv2 with runtime exception:
>> https://www.threadingbuildingblocks.org/licensing
>>
>>
>>
>> -Ken
>>
>>
>>
>> *From: *vtk-developers <vtk-developers-bounces at vtk.org> on behalf of
>> Andras Lasso <lasso at queensu.ca>
>> *Date: *Tuesday, February 9, 2016 at 3:56 PM
>> *To: *"Geveci, Berk (External Contact)" <berk.geveci at kitware.com>, Ken
>> Martin <ken.martin at kitware.com>
>> *Cc: *VTK Developers <vtk-developers at vtk.org>, David Gobbi <
>> david.gobbi at gmail.com>
>> *Subject: *[EXTERNAL] Re: [vtk-developers] Checking SMP backend at
>> runtime/compiletime?
>>
>>
>>
>> >we'll have to require that people use TBB.
>>
>> Are you talking about Intel TBB – single license starting from $700? Or
>> there are some free replacements?
>>
>>
>>
>> For most of our projects current performance of VTK is already good
>> enough and it is very important to not have any licensing cost or
>> restrictions. So, I would prefer free vtkMultiThreader over expensive Intel
>> TBB, regardless of speed improvements.
>>
>>
>>
>> Andras
>>
>>
>>
>>
>> *From: *Berk Geveci <berk.geveci at kitware.com>
>> *Sent: *February 9, 2016 14:56
>> *To: *Ken Martin <ken.martin at kitware.com>
>> *Cc: *VTK Developers <vtk-developers at vtk.org>; David Gobbi
>> <david.gobbi at gmail.com>
>> *Subject: *Re: [vtk-developers] Checking SMP backend at
>> runtime/compiletime?
>>
>>
>>
>> A few comments:
>>
>>
>>
>> * I support the path David wants to take. We flushed this out over
>> several months in collaboration with a Google Summer of Code student. It is
>> the best transition strategy given that we have several moving components
>> (see below).
>>
>>
>>
>> * The Simple backend of vtkSMPTools is only there for debugging. Helgrind
>> produces lots of false positives when using TBB so I developed the Simple
>> backend for use with Helgrind. It is not a production backend and pretty
>> much sucks. Now that we haven an OpenMP backend that can be used with
>> Helgrind, Simple must die. I don't see a reason to deprecate it first since
>> it is there only for debugging. This is clearly documented in the PDF will
>> pointed to.
>>
>>
>>
>> * For compilers that do not support OpenMP 3.1, one can (and should) use
>> TBB. TBB is the better backend anyway so I recommend it over OpenMP.
>>
>>
>>
>> * We will not include TBB in VTK. It is an external dependency similarly
>> to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if
>> they want any thread-level parallelism out of VTK. We need to discuss what
>> "in the future" means.
>>
>>
>>
>> * Posix threads, C++11 threads etc. are not the way to go. They are way
>> too low level and require management of thread pools and such to get good
>> scalability. Things that OpenMP and TBB already to well. In general, for
>> the kind of parallel computing we want in VTK, the best tools are high
>> level ones such as parallel for loops etc. Furthermore, OpenMP will be
>> important where we want to get SIMD (vector) parallelism.
>> Auto-vectorization is very imperfect. And there are no C++ primitives that
>> help with SIMD in C++11.
>>
>>
>>
>> * At one point, we will have to get rid of vtkMultiThreader (at least of
>> its use in algorithms, it may still be useful for GUI threads and whatnot).
>> Hopefully, by then OpenMP 3.1 or above will be universally supported so we
>> can make it the default backend. If not though, we'll have to require that
>> people use TBB.
>>
>>
>>
>> Best,
>>
>> -berk
>>
>>
>>
>> On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin <ken.martin at kitware.com>
>> wrote:
>>
>> Echoing David's earlier comments it would seem like we would want a nice
>> path to convert existing multithreaded algorithms to use vtkSMPTools
>> knowing that vtkSMPTools would not slow down the existing algorithm. Doing
>>
>>
>>
>> #if VTK_SMP_BACKEND == SLOW
>>
>>  use vtkMultithreader
>>
>> #else
>>
>>   use vtkSMPTools
>>
>> #endif
>>
>>
>>
>> sounds odd. I did not read the pdf so if that is covered in there
>> apologies.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>>
>> Hi Sujin,
>>
>>
>>
>> That sounds good.  Even if the choice of backend is transparent as far as
>> using vtkSMPTools is concerned, it's very nice to be able to report which
>> backend was configured.
>>
>>
>>
>>  - David
>>
>>
>>
>> On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip <sujin.philip at kitware.com>
>> wrote:
>>
>> Hi Sean,
>>
>> vtkSMPTools is a framework for implementing multi-threaded algorithms in
>> VTK. It support several backends. The main ones are TBB and OpenMP. There
>> are Kaapi and Simple backends which are no longer supported and will be
>> removed soon. Finally, the default backend is Sequential which is just a
>> single threaded implementation of the framework. After removal of the Kaapi
>> and Simple backend, if you need multithreading support on Clang you would
>> have to use TBB. The Sequential backend will be supported on all platforms.
>>
>> David,
>>
>> I have talked with Berk about this and I will soon make a change to have
>> a compile time macro to check for SMP backend type. I will also finally
>> remove Kaapi and Simple backend as part of this change.
>>
>> Thanks
>>
>> Sujin
>>
>>
>>
>> On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride <sean at rogue-research.com>
>> wrote:
>>
>> On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said:
>>
>> >Why would you want to continue using vtkMultiThreader when Sequential or
>> >Simple is used? In fact, now that there is an openmp backend, we should
>> be
>> >removing simple. It was only there to ease debugging since tbb had very
>> >complex back-traces. Openmp back-traces are much more readable. Do you
>> want
>> >the algorithm to be multithreaded even when Sequential is used?
>>
>> I don't know the APIs you're discussing, so this comment is coming mostly
>> from ignorance, but: are you talking about requiring OpenMP to build VTK?
>> Clang has only very recently added OpenMP support, and IIRC it's not
>> complete.  Also, last I checked, Apple's fork of clang doesn't support it
>> at all.
>>
>> Cheers,
>>
>> --
>> ____________________________________________________________
>> Sean McBride, B. Eng                 sean at rogue-research.com
>> Rogue Research                        www.rogue-research.com
>> Mac Software Developer              Montréal, Québec, Canada
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>>
>>
>>
>> --
>>
>> Ken Martin PhD
>>
>> Chairman & CFO
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>> 518 371 3971
>>
>>
>>
>> This communication, including all attachments, contains confidential and
>> legally privileged information, and it is intended only for the use of the
>> addressee.  Access to this email by anyone else is unauthorized. If you are
>> not the intended recipient, any disclosure, copying, distribution or any
>> action taken in reliance on it is prohibited and may be unlawful. If you
>> received this communication in error please notify us immediately and
>> destroy the original message.  Thank you.
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160210/f9cb31f7/attachment-0001.html>