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

Wed Feb 10 11:14:29 EST 2016

No problem. I don't think that we could think this more carefully :-) This
work started in 2013. We were contemplating it for a while before then.
Since then, we have discussed this in multiple venues, had discussion in
the ARB, published multiple papers & reports, had a Google Summer of Code
project, used it to improve existing filters and write new ones.
Furthermore, VTK-m has been pushing things forward more aggressively so we
have a very good idea the extreme end of what needs to be done for good
performance.

If we want VTK to be relevant 5-10 years from now, we can't be chained to
legacy ways of doing things for much longer. So I plan to push aggressively
for change including C++ 11 adoption at the end of this year and some sort
of path to C++ 17 after that. Adoption of VTK-m. Adoption of frameworks
like DIY (https://github.com/diatomic/diy2). Modern OpenGL implementation
(check) etc etc.

In terms of licensing, I  read a lot of stuff on the runtime exception as
it applies to libstdc++ etc. I have no concerns about this path. By the
way, libstdc++ is not as different as you think. It has a full STL
implementation, which is almost entirely embedded in one's code through
template instantiation. So without the exception, all binaries compiled
with the GNU C++ compiler would be under GPL. And it is possible to link
against libstdc++ statically and hence distribute the whole thing as part
of the binary. Something we have done. We have also included libstdc++ in
binary distributions in the past.

Best,
-berk

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

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