Excel and tbb

[Petros_Mamales]

Hi,
I would like to use tbb from an excel addin (xll) (Excel 2007 and newer).
I have a couple of questions on this - have already done a couple of experiments and got some instability-maybe because of my fault (?).
Is there any reason for which this would have problems from the start?

As far as the memory allocators is concerned, Excel C API documentation states that any mix of malloc or new could be used in the addin. I assume that this is because of both of them reducing to malloc, one way or another.

Does scallable_malloc fall into the same category? If not, are there potential issues? And if there are, any workaround?

Which is your recommendation for the employment of tbb (and its allocators) in plugin libraries (being excel, python etc), where the memory model is not known/changeable?

Thank you very much for your help,
Petros

[RafSchietekat]

With TBB used only in a plugin that is loaded after the program has started (my assumption), it cannot replace standard malloc/new, which will therefore not interoperate with the scalable allocator. If the plugin is somehow configured to be loaded immediately at program startup, the situation might be different, but I'll leave it to somebody who has looked at this before.

Your strategy should be to let TBB continue to make its own choices for (de)allocating its own data (it will typically use the scalable allocator), and to determine which other data needs the extra kick that it should be explicitly configured to both allocate and deallocate using the scalable allocator.

[Anton_M_Intel]

TBB uses scalable allcoator internally only if it founds the tbbmalloc.dll. Just remove it and TBB will use malloc.

The problem can be in TLS setup of the worker threads as well if you call some Excel API from parallel algortithms. Excel may need some thread-initialization.

And another source of instability may come from deinitialization sequence of the worker threads in TBB (only when the plug-in is being unloaded).

When and howoccurs theinstability?

[Petros_Mamales]

Hi Raf,
Thank you for your response.
I do not aim in replacing excel's allocator with tbb's - if this was that was understood, from my writting, apologies.
So, If I understand your reply properly, if I allocate something using tbb's allocators (the appropriate malloc being loaded as well), and make sure that I deallocate it using the same tbb's allocators, I should be safe? (something-please forgive the potential naiveness- like I am working on a separate heap from excel's?)
If this is the case, then, this is all I need.
Can you please confirm?
Thank you very much for your help,
Petros

[Petros_Mamales]

Hi Anton,
Thank you for your response.
Since you asked, the instability, I noticed had to do with a simple random number sample created in one function call (10E6x10)
and the calculation of the correlation matrix(6x6). The first was using mkl and the latter tbb.The calls were (excel/)registered thread-safe. When I was recalculating the sheet (manual mode), while the dependency was clear,
the random numbers showed patches where the cells were empty (rather weird).
Now it was in debug mode, or as I said maybe I did something wrong -which I hope, o/wise this could mean real trouble.
Coming back to my main question, I do not use Excel API calls from my threaded code. The TLS setup and the unloading of the library sound worrisome though.
Thank you for your help,
Petros,
PS: Also replied to Raf.Tried to avoid findings overlapin my answers.

[RafSchietekat]

"I do not aim in replacing excel's allocator with tbb's - if this was that was understood, from my writting, apologies."
Just trying to properly qualify my response...

"So, If I understand your reply properly, if I allocate something using tbb's allocators (the appropriate malloc being loaded as well), and make sure that I deallocate it using the same tbb's allocators, I should be safe? (something-please forgive the potential naiveness- like I am working on a separate heap from excel's?)
If this is the case, then, this is all I need.
Can you please confirm?"
In this setup, I would confirm that (unless perhaps if tbbmalloc.dll is not found, but I'm not sure you should rely on that, especially if you still want the scalability, although it seems useful to know if taking away tbbmalloc.dll solves a particular stability problem). Note that what I described above is necessary to make it work, but I can't tell whether it is guaranteed to be sufficient (I remember issues at startup/shutdown before, and now again in Anton's answer, although I'm not aware of the exact details). Still, you can try with that in mind and report back if it still doesn't work (I'm not sure I fully understand your description of the current status). Oh yes, don't bind the new/delete operators to the scalable allocator in your plugin (normally a good idea), because that would be a sure way to get things all mixed up.

[Petros_Mamales]

Hi Raf,
Thank you very much for your response.
It seems that I need to try and see. What really bothers me is that I will never be sure..-unless disaster happens-;)).
It would seem to me that if another heap is created for tbb's allocation, things would be OK.
The rational being that, at some point or another, tbb will have to rely on the os memory allocation capability.
Now, of course, if initialization/shutdown issues emerge, or tls memory is used by more than one client things are doomed.
Again, thank you very much for all your help (and Anton's). Very much appreciated.
Petros

[Petros_Mamales]

Hi Raf,
Thank you very much for your response.
It seems that I need to try and see. What really bothers me is that I will never be sure..-unless disaster happens-;)).
It would seem to me that if another heap is created for tbb's allocation, things would be OK.
The rational being that, at some point or another, tbb will have to rely on the os memory allocation capability.
Now, of course, if initialization/shutdown issues emerge, or tls memory is used by more than one client things are doomed.
Again, thank you very much for all your help (and Anton's). Very much appreciated.
Petros

[RafSchietekat]

"It would seem to me that if another heap is created for tbb's allocation, things would be OK.
The rational being that, at some point or another, tbb will have to rely on the os memory allocation capability."
I'm afraid I don't see what you mean, but, last time I looked, small objects were allocated from big chunks obtained directly from the operating system, bypassing the malloc heap.

"Now, of course, if initialization/shutdown issues emerge, or tls memory is used by more than one client things are doomed."
Hmm, can multiple plugins share a Singleton (as in the pattern)? Probably one could do interesting things with shared memory even across program boundaries, e.g., to cooperate between schedulers, but my impression is that these kinds of things are still being investigated.

[Petros_Mamales]

Hi Raf,
Thank you for your reply.

What I mean stems from my worrying for memory segmentation problems, in the presence of multiple allocators within the same application. Typically, I create excel/python plug-ins and want to employ mkl and tbb (at well-separate areas of my library). And I need a fast mt allocator but have to worry about things like this. (I am not the only one doing this, btw - the entire financial industry is working along these lines.). To satisfy my memory needs w/tbb I allocate buffers outside the threads area of my program, and point to different areas of them for the threads' function objects. If this is somehow taken care of by the library, under the hood, that would save me a lot of plumbing ( one of your earlier responses gave me the impression that this is something done at a certain level - maybe misunderstood you??).

But there is no sufficient information provided for answering these questions
At the very least, there should be a more thorough documentation on what the limitations of tbb allocators are wrt coexistencewith system provided ones (for much more propriatory apps like excel,things could be much trickier, I realize, but excel guarantees that malloc-based memory calls will work). Also, things like the handling of tls resources and heap memory oneswould allowusers to makemore educated guesses and make design decisions.These are clearly lacking - I mean this in a very friendly way.
Or, they are notand I have failed to locatethem - in this case a pointer would be immensely appreciated.

Thank you for all your help,
Petros

[RafSchietekat]

"If this is somehow taken care of by the library, under the hood, that would save me a lot of plumbing ( one of your earlier responses gave me the impression that this is something done at a certain level - maybe misunderstood you??)."
TBB eats its own cooking as far as the scalable allocator is concerned, for tasks (redefined new/delete), containers (under the hood), ... You can also redefine new/delete per object type of your own, plug the allocator into plugin-local STL containers, etc., but TBB cannot behave invasively unless so instructed.

Normally it should "just work" like any other ad-hoc allocator, if you don't make inappropriate assumptions (don't assume compatibility between new and malloc where not documented, always use the deallocation that goes with the allocation, don't cast away types, ...), but maybe some aspects are just too recent to have allowed much stabilisation in adventurous deployment environments such as plugins. Consider yourself on the bleeding edge, and use the forum for specific questions and broadly useful requests (TBB's development team are monitoring it). Meanwhile we can all dream of the grand unification of allocators to finally put this matter to rest. :-)

[Petros_Mamales]

OK Raf,
;-)) So ypu know/guessed that I was a physicist.
Thank you for all your help. Very much appreciated!
Have a good one,
Petros

[Petros_Mamales]

OK Raf,
;-)) So ypu know/guessed that I was a physicist.
Thank you for all your help. Very much appreciated!
Have a good one,
Petros