TBB forever?

[Nav]

This is with reference to a paragraph from the TBB FAQ:
"How will TBB help my software run on future processors?
The great part about TBB is that it will detect the number of cores on the hardware platform and make the necessary adjustments to allow your software to adapt. All you have to do is ensure that you use the latest versions of the TBB libraries, and you will have to do no new work as new platforms with more cores are introduced "

See the text above marked in bold. As processor technology grows through the decades, will I have to keep updating my TBB libraries? What if the new libraries use different commands...? will I then have to sit and modify my code (which by then would have grown to a monstrous size)?
Or what if the Intel company closes down (god forbid)? Who will then keep the libraries up to date with the hardware?

TBB gives me excellent performance at this point of time, but keeping the above questions in consideration, is TBB really meant to be forever or is it just a marketing strategy?
I need to know this right now, as I have to choose whether or not to go ahead with TBB. No diplomatic answers please.

[Dmitry_Vyukov]

Quoting - Nav

This is with reference to a paragraph from the TBB FAQ:
"How will TBB help my software run on future processors?
The great part about TBB is that it will detect the number of cores on the hardware platform and make the necessary adjustments to allow your software to adapt. All you have to do is ensure that you use the latest versions of the TBB libraries, and you will have to do no new work as new platforms with more cores are introduced "

See the text above marked in bold. As processor technology grows through the decades, will I have to keep updating my TBB libraries? What if the new libraries use different commands...? will I then have to sit and modify my code (which by then would have grown to a monstrous size)?
Or what if the Intel company closes down (god forbid)? Who will then keep the libraries up to date with the hardware?

TBB gives me excellent performance at this point of time, but keeping the above questions in consideration, is TBB really meant to be forever or is it just a marketing strategy?
I need to know this right now, as I have to choose whether or not to go ahead with TBB. No diplomatic answers please.

Hi Nav,

I do not relate to TBB in any way, so I can't provide 'official' meaning. But as far as I understand it, it is meant to be something along the lines of:

---
The great part about TBB is that it will detect the number of cores on the hardware platform and make the necessary adjustments to allow your software to adapt, and you will have to do no new work as new platforms with more cores are introduced. Period.
Additionally you may consider periodic upgrades to the latest versions of the TBB libraries, this way you will transparently benefit from any improvements in scheduling/runtime/memory management/whatever implemented in TBB.
---

p.s. AFAIK currently TBB is binary compatible with at least some (probably all, do not know exactly) previous versions.

[ARCH_R_Intel]

As Benjamin Franklin remaked, nothing is certain in life except death and taxes. That said, we do try to maintain backwards compatibility in TBB, and do test for this. If you look at the open source version, you will see the old code and tests in src/old/.

We got serious about supporting backwards compatibility starting with TBB 2.1.Starting then, we tag each entry point into the TBB library. When we revise support for a feature in a way that could break compatibility, we keep the semantics of the old identifier, and introduce new identifiers with a new tag. E.g., the tag for TBB 2.1 features is"v2" and the tag for TBB 2.2 features is "v3". The old untagged identifiers remain a legacy that we maintain (but nonetheless wish we had tagged!) For example, TBB 2.2 revised the implementation of concurrent_vector, so the current tbb::concurrent_vector calls entry points that have the "v3" tag. But the library also contains the untagged entry points that support the old TBB 1.0 concurrent_vector.

In one unusual case, we do the version check at run-time. The case is the task scheduler, and the reason is that we did not want to have two copies of the scheduler. TBB 2.2 added a virtual method task::note_affinity(), which of course changes the virtual function table layout. To maintain backwards compatibility, the task scheduler checks whether the task was constructed by a TBB <=2.1 header, and if so, knows the vtable slot is missing and avoids calling the missing virtual method.

There may come a time when we decide thatthe benefit of maintaining very old entry points is not worth the cost. But so far every old entry point has been maintained. We do deprecate some features. See Appendix A of the TBB Reference manual for a list of such features. "Deprecated" does not mean that a feature has been removed. "Deprecated" is a "warning shot across the bow" (as a standards committee member once colorfully explained it) that a feature is on the way out. It might be years or decades before it really disappears. (E.g., C++ implementations still support features that were deprecated by the 1998 standard.) So far in TBB, we have deprecated features, but never actually removed them.

If Intel goes under, computers may have changed so radically that TBB is the least of the problem. For example, the dominant form of computing may be quantum computing based on self-replicating organic slime :-)

[Nav]

Thanks Dmitriy, I agree with you, that the old libraries might recognize and automatically take into account new platforms and cores. But I'm asking to be sure.

@Arch:
Thank you very much for taking the time to reply.
Yes, I had seen the 'src/old' folder but didn't know that it was actually being taken into consideration. I'm still trying to figure out a lot...any pointers to tutorials would help (already been thru the official Intel tutorial pdf's).
Do you agree with what Dmitriy says or will there be chances of us having to update the TBB libraries when there are new hardware platforms and cores?

P.S: Death is certain, but not taxes (the natives of the Amazon don't pay any) ;) I guess Franklin was as harried with taxes as any one of us :)

[RafSchietekat]

"Will there be chances of us having to update the TBB libraries when there are new hardware platforms and cores?"
Do you mean beyond how it discovers the number of cores at task scheduler initialisation time and uses a matching number of worker threads? I've always liked that I don't have to care how many cores there are: make sure the program doesn't actually need parallelism (test with number of threads explicitly set to 1), have a reasonable amount of parallel slack (use TBB's algorithms, perhaps do something directly with tasks where it makes sense), then watch the result, and optimise as needed/wanted (ultiimate performance requires more effort).

(Added) Dmitriy and Arch have already said this and more, of course. I'm just asking you to further clarify your concerns and horizon, which seems unrealistic. Now you're asking for sweeping promises without making your own position clear.

[Nav]

Quoting - Raf Schietekat

Now you're asking for sweeping promises without making your own position clear.

My question has always been the same - Please refer my original post where I've marked a sentence in bold.
I'd like to know the reason Intel recommends us to keep the libraries up to date. Is it because the current libraries won't be able to detect any future changes in hardware? Or are the new libraries recommended only for updates made to the TBB commands?

For now, I just want to know what that paragraph in the FAQ implies/means.

[RafSchietekat]

Quoting - Nav

My question has always been the same - Please refer my original post where I've marked a sentence in bold.
I'd like to know the reason Intel recommends us to keep the libraries up to date. Is it because the current libraries won't be able to detect any future changes in hardware? Or are the new libraries recommended only for updates made to the TBB commands?

For now, I just want to know what that paragraph in the FAQ implies/means.

If it's just that, see Dmitriy's answer above. There's nothing special in there relating to number of cores, although it may have to be a power of two for best performance (?), so if you buy that 256-core PC, your program will use all of them.

[ARCH_R_Intel · Accepted solution]

There's two compatibility issues: correctness and performance. On the correctness front, processor vendors are generally good about making existing instructions work, no matter how obsolete they are. E.g., AAD (ASCII Adjust AX Before Division)still works on IA-32. If there is a correctness stability issue, it's more likely to come from the OS. I've run across DOS binaries that ran on Windows95 but not on Windows XP. So I expect existing TBB binaries to run on new versions of Intel processors. Running old binaries on the latest hardware is a key value proposition for Intel processors. Intel puts a lot of effort into ensuring that proposition holds.

To get best performance out of new platforms, you will likely have to update the TBB library. The rules for what is the best way to code keep changing with the architectures. E.g., the rules on whether it is good to use one instruction or two instructions to perform a load and an arithmetic operation has flip-flopped over the years on IA-32. Radical increases in the number of cores can also reveal scaling bottlenecks that need to be fixed. But on the whole, the basic task-stealing framework in the scheduler should scale well, so I expect even old versions of the scheduler to do okay. But's it's quite possible that in the future we might find ways to do better byexploiting the latest hardware features, which would require updating the library to get the benefit.

[Nav]

Quoting - Arch Robison (Intel)

There's two compatibility issues: correctness and performance. On the correctness front, processor vendors are generally good about making existing instructions work, no matter how obsolete they are. E.g., AAD (ASCII Adjust AX Before Division)still works on IA-32. If there is a correctness stability issue, it's more likely to come from the OS. I've run across DOS binaries that ran on Windows95 but not on Windows XP. So I expect existing TBB binaries to run on new versions of Intel processors. Running old binaries on the latest hardware is a key value proposition for Intel processors. Intel puts a lot of effort into ensuring that proposition holds.

To get best performance out of new platforms, you will likely have to update the TBB library. The rules for what is the best way to code keep changing with the architectures. E.g., the rules on whether it is good to use one instruction or two instructions to perform a load and an arithmetic operation has flip-flopped over the years on IA-32. Radical increases in the number of cores can also reveal scaling bottlenecks that need to be fixed. But on the whole, the basic task-stealing framework in the scheduler should scale well, so I expect even old versions of the scheduler to do okay. But's it's quite possible that in the future we might find ways to do better byexploiting the latest hardware features, which would require updating the library to get the benefit.

Thank you. Will reply soon.

[Nav]

I have nothing more to ask as of now. Thank you very much for a detailed answer.