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

Wed Feb 10 10:55:31 EST 2016

Hi Berk -

All I asked is that you think carefully.  Thanks for the info.

-Steve

On Wed, Feb 10, 2016 at 10:46 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> 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/74c34448/attachment-0001.html>