better documentation / support of external compilers and linkers

[Wolfgang]

In principle CVI supports external compilers for an optimized release version such as Intel's ICL and I managed to successfully compile release versions using ICL 11.1.

However, documentation on this issue is sparse.

It is even worse if one attempts to use an external linker which might be appropriate if one attempts to use e.g. Intel's MKL. Here I would love to see the support of external linkers in combination with an improved documentation.

Similarly, CUDA is becoming more attractive for more demanding floating point applications - I would consider it very useful if NI could provide e.g. an application note of how to do this in an easy to follow tutorial.

[LuisG]

Documenting the intricacies of third-party compilers is a pretty difficult task, since things are always liable to change without NI necessarily being aware of it, and the complexity of some of the compilers could easily overwhelm NI's ability to document them properly. As far as linkers are concerned, there is way too much CVI-specific work that the built-in linker must do. Therefore, it is very unlikely that CVI could ever support third-party linkers.

[Wolfgang]

Hi Luis,

of course I understand that NI is not going to promote other companies' compilers or document their proper use. On the other hand, what is the purpose of supporting external compilers without sufficient documentation?

One of the new features of CVI2010 is the support of Clang as an external optimizing compiler. At first glance this sounds quite nice - but the lack of any documentation does not motivate me to spend days (or nights...) to get this combination running. Introducing such a feature without any supporting documentation seems quite useless to me...

[menchar]

I would offer that NI should look into this anyway - the code the native NI compiler generates is actually very slow - anyone expecting to see performance from the newer micros (multi-core, new instruction sets) is going to get cheated with the NI native compiler.  Maybe clang is a bit better.  NI knows this, that's why they offer the release compilers. I do have some sympathy with the issue of tracking a third party compiler.

If you compare compiler performance when data crunching (as I have) the difference is remarkable, even when you can't use the 16 byte aligned vector instructions that all the new micros have (CVI liker won't do 16 byte alignement  well, you have a 50/50 chance it will work - every other 8 byte alignment is a 16 byte alignment ;-).  The MS VCPP compilers are actually quite good now - MS in spite of themselves apear to have access to some good compiler writers MSVCPP 10.0 is supposed to do quite a bit of auto-parallelization to get performance out of mutliple cores.  The Intel CPP compiler is better when you can get 16 byte alignment, their compiler is, of course, all matched up to the latest new instruction sets.

[nickb]

I just thought I would point out that the vertorization instructions should now work in CVI 2010.

[menchar]

That's good news.  I don't have access to CVI 2010 yet, but it sounds like NI has put several good things into it.

[saratoga]

While I agree providing documentation isn't easy, the Mathworks seems to manage it for a variety of Fotran and C compilers on several operating systems.  

Is there some reason National Instruments is unable to do the same?

[LuisG]

It's not a question of impossibility, of course. It's a question of prioritization. At any given time, NI, and the CVI team in particular, is faced with a far greater amount of possible improvements to CVI, than our resources allow for. This isn't unique to CVI. Every group and every company is resource-limited. So, we have to make choices.

An idea exchange forum, such as this one, provides us with a very valuable input in how we make those choices, and we do take all submissions into consideration. So, for example, should this idea receive a lot more support from users in the future, we're certainly open to reconsidering its status. But right now, we still don't feel that this specific suggestion is the best use of our resources. (And by "specific suggestion" I'm referring to providing our own documentation for third-party compilers, I'm not referring to improving our own compiler).

By the way, here's the documentation for the clang compiler options: http://clang.llvm.org/docs/UsersManual.html