Jump to content

bsvingen

Members
  • Posts

    279
  • Joined

  • Last visited

Everything posted by bsvingen

  1. He he I see the point about the C compiler. It will make labview something it is not supposed to be (although the point is more of a religious one than a practical one ) But then again, whats the point of a matlab clone (mathScript)? I would think that this is an even greater undertaking and is certainly making LV something it is not :laugh:
  2. No, it's not that important. Right now the core floating point extensive stuff is programmed in one large chunk. It's fast (fully optimized c code is only approx 150% faster), but not particularly readable although i have added comments all around. Adding too much comments also tends to confuse more than clear up . The problem is future modifications adding more complex things, since the complexity now is right on the edge of what is practical without dividing it up in more readable chunks, at least if some other persons is to understand the code within a reasonable amount of time. Doing this with sub vis makes no sense performance vise, so the only alternative is a DLL written in C. Using a DLL is of cource a very good alternative. I had that as a default for sime time, but decided not to simply for the reason of having only one platform and one compiler. There are two things that could solve this. One thing is a complete overhaul of the formula node, making it a complete C compiler within labview, as it should be IMO Right now it is to slow (probably only some scripting thing??) and do not have the ability for making functions, but i use them alot since they are very practical and not too slow for small things. The other alternative is inline functionality within the G compiler. The MathScript nodes of LV8.0 are probably a nice thing if you are used to matlab (which i am not ), besides, they are way to slow in both execution and compiling speed to be of any real use for me. Anyway, I would believe that an inline scripting tool should be fairly simple. You would anly use this for sub vis that othervise would be flagged as subroutines, thus no user intaraction, only strictly specified input and output, and only for simple functions like for instance geometric transformation routines and stuff like that.
  3. I have had the opposite experience. It is true that the total amount of overhead in absolute time for 1 mill calls is in the order of 100-500 ms. This therefore does not seem like a problem other than from an academic point of view. However, within such a sub vi you can put an incredible large amount of code doing floating point operation before the total amount of floating point time exceeds the time for one call to that sub vi. What seems like an academic problem is in fact a huge problem when doing floating point math. In fact it is practically impossible in most cases to make a numeric code doing math without loops that takes longer time to execute than it takes to call the code. Below is a snip from a post i did at NI site: For applications doing extensive floating point operations the overhead in making function calls makes no sense at all, simply because it is not neccesary. Getting rid of the function call overhead will speed up the application maybe 200 to several thousand percent depending on the amount of looping and the amount of function calls. C/C++ has this inline flag, while FORTRAN has inline subroutines and function by default, and this is not without reason. I have developed a fearly large simulation program in Labview, and i have compared the labview code using pure labview primitives (add, div, mult, subtract etc on vectors) with an optimized C routine. An optimized C routine is approx 150 % faster for pure floating point, but when trying to build sub vis to make the code more readable and easier to maintain, the added overhead makes it a waste of time, even when using the subroutine flag. The penalty is huge. It will be much easier, faster and more maintainable to make a DLL from C even though (presumably) there is som fair amount of overhead in calling that DLL from labview. The reason is mainly that C has this inline functionality. My point is that inline functionality is a very simple trick, but it does wonders for floating point math.
  4. Hello Would it be possible to write a small app that use scripting and preprocess a vi so that sub vis are inlined like in other programing languages. When execution speed is important as well as readability of the code, then inline functions is essential. Unfortunately function calling in labview is very slow and there is no option to inline the code, thus to make it fast, the code becomes unreadable. But with scripting i guess it will be possible to use inline functionality as a sort of preprocessor option to just copy and paste the diagram of the sub vi into the main program ?? The subroutines could be reckognised for instance with an _inline_ in their names. Would this be possible? It would be extremely usefull for apps that need to run fast. BSvingen
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.