Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
A few more thoughts:
1) Shane has definitely hit on the right idea, but there is another dimension to it. Using complex data structures does add additional memory and performance hits beyond the fact that you have to keep all of the data together. When storing data in memory there is obviously some overhead associated with each level of complexity you add to a data structure (you have to somehow keep track of what is in the structure, and where it resides in memory).
Does this mean that you shouldn't use complex data structures? No, the value in readibility and maintainability that you gain by using well designed data structures will almost always outweigh the modest performance hit they cause. There are almost always optomization issues involved with writing better code (true of any language), if memory and speed are truly all you are concerned about, then you would be writing in assembler. As Shane said, the memory and performance guidelines are generally only applicable in cases of mis-use, or in cases where you have to squeeze just a few microseconds out of a VI.
2) You should never use a local variable to pass data that could be passed by a wire. Local variables cost memory and performance (not much, you shouldn't worry about it in cases where they are neccessary, but it can add up if misused). In addition, they reduce the readability of your VI, since there is data being transfered without any visible link. They also make execution control harder and can lead to race conditions if misused. As Shane said, if you find that you have to string wires a long way across your diagram then you probably aren't making use of SubVIs or organizing your block diagrams well.
3. There are some Object Oriented principles which are difficult to accomplish with LabVIEW. It's generally possible to do most things, but they may be more difficult than in other languages (which in some cases may be for the best, design patterns which apply well in other languages don't always make as much sense in LabVIEW). LabVIEW is a language which is under constant development, and it is likely that Object Oriented programming will become easier with time. In the mean time, I believe that there have been a couple of open source projects aimed at improving LabVIEW's Object Oriented capabilities. I haven't personally used any of them, but if you are interested I would guess that openg.org would probably be a good place to start.
4) NI teaches a number of courses aimed at improving development techniques (LV Intermediate I probably focuses on it the most). Ideally, taking these would be a great idea, however, we understand that this may not be affordable or practical for university students. The ideal solution on an academic level would be to teach university courses on it, or at least include it in current courses. NI is very commited to assisting anyone who wants to expand the LabVIEW instruction which their courses are providing, we provide a large body of resources and contacts which can make it a lot easier to incorporate this material. You should encourage your professors to work with their local NI reps to take advantage of these resources.
For a more short term solution, the LabVIEW Development Guidelines would probably be a good place to start:
http://digital.ni.com/manuals.nsf/webAdvsearch/5FBA64AD223A76A786256D2C00561F2D?OpenDocument&vid=niwc&node=132100_US
5) As with the rest of your questions, no simple yes/no answer to this one. LV 7.0 is faster for some things, as we are always working to optomize our code and slower for others, as new features or better written code sometimes add overhead.
http://zone.ni.com/devzone/conceptd.nsf/webmain/DC9B6DD177D91D6286256C9400733D7F?opendocument provides some examples, but the fact is that it really varies by application. In general they tend to balance out and most applications run at about the same speed.
Finally, a note about using the forum: In general, you'll probably get many more answers to your questions if you post them seperately, most people are more willing to read a paragraph or two and post their thoughts on it than they are to read a page and write a long response to a number of questions (luckily there are some exceptions
).
Hope some of that helps,
Ryan K.
NI
1) Shane has definitely hit on the right idea, but there is another dimension to it. Using complex data structures does add additional memory and performance hits beyond the fact that you have to keep all of the data together. When storing data in memory there is obviously some overhead associated with each level of complexity you add to a data structure (you have to somehow keep track of what is in the structure, and where it resides in memory).
Does this mean that you shouldn't use complex data structures? No, the value in readibility and maintainability that you gain by using well designed data structures will almost always outweigh the modest performance hit they cause. There are almost always optomization issues involved with writing better code (true of any language), if memory and speed are truly all you are concerned about, then you would be writing in assembler. As Shane said, the memory and performance guidelines are generally only applicable in cases of mis-use, or in cases where you have to squeeze just a few microseconds out of a VI.
2) You should never use a local variable to pass data that could be passed by a wire. Local variables cost memory and performance (not much, you shouldn't worry about it in cases where they are neccessary, but it can add up if misused). In addition, they reduce the readability of your VI, since there is data being transfered without any visible link. They also make execution control harder and can lead to race conditions if misused. As Shane said, if you find that you have to string wires a long way across your diagram then you probably aren't making use of SubVIs or organizing your block diagrams well.
3. There are some Object Oriented principles which are difficult to accomplish with LabVIEW. It's generally possible to do most things, but they may be more difficult than in other languages (which in some cases may be for the best, design patterns which apply well in other languages don't always make as much sense in LabVIEW). LabVIEW is a language which is under constant development, and it is likely that Object Oriented programming will become easier with time. In the mean time, I believe that there have been a couple of open source projects aimed at improving LabVIEW's Object Oriented capabilities. I haven't personally used any of them, but if you are interested I would guess that openg.org would probably be a good place to start.
4) NI teaches a number of courses aimed at improving development techniques (LV Intermediate I probably focuses on it the most). Ideally, taking these would be a great idea, however, we understand that this may not be affordable or practical for university students. The ideal solution on an academic level would be to teach university courses on it, or at least include it in current courses. NI is very commited to assisting anyone who wants to expand the LabVIEW instruction which their courses are providing, we provide a large body of resources and contacts which can make it a lot easier to incorporate this material. You should encourage your professors to work with their local NI reps to take advantage of these resources.
For a more short term solution, the LabVIEW Development Guidelines would probably be a good place to start:
http://digital.ni.com/manuals.nsf/webAdvsearch/5FBA64AD223A76A786256D2C00561F2D?OpenDocument&vid=niwc&node=132100_US
5) As with the rest of your questions, no simple yes/no answer to this one. LV 7.0 is faster for some things, as we are always working to optomize our code and slower for others, as new features or better written code sometimes add overhead.
http://zone.ni.com/devzone/conceptd.nsf/webmain/DC9B6DD177D91D6286256C9400733D7F?opendocument provides some examples, but the fact is that it really varies by application. In general they tend to balance out and most applications run at about the same speed.
Finally, a note about using the forum: In general, you'll probably get many more answers to your questions if you post them seperately, most people are more willing to read a paragraph or two and post their thoughts on it than they are to read a page and write a long response to a number of questions (luckily there are some exceptions
).Hope some of that helps,
Ryan K.
NI
thanks for the comments, ryan. It's always nice to hear from the people who develop the software.
1) It seems to me that allowing people to pass pointers to complex data structures would allow for more efficient memory management. I know about refnums, but Shane and others seem to imply that refnums/property nodes come with unnecessary GUI overhead. I hate pointers as much as anyone else, but being able to pass by reference without overhead would be HUGE. Is there a way to do this?
2) The "avoid local variables when possible" bit is news to me. But I get the point
3) as far as I know, the GOOP projects use refnums, which are subject to the same overhead constraints as mentioned in (1).
4) I think the problem with college courses i
s that most professors who design course curricula know about LabView, but they don't use it themselves -- their graduate students do. I've seen certain TA's make LabView instruction a pet project, but the novelty of G means that most students are happy to get to the point where they don't have broken wires everywhere (believe me, there's lots of swearing on LabView lab days). And most students are more worried about running their experiments than programming.
1) It seems to me that allowing people to pass pointers to complex data structures would allow for more efficient memory management. I know about refnums, but Shane and others seem to imply that refnums/property nodes come with unnecessary GUI overhead. I hate pointers as much as anyone else, but being able to pass by reference without overhead would be HUGE. Is there a way to do this?
2) The "avoid local variables when possible" bit is news to me. But I get the point
3) as far as I know, the GOOP projects use refnums, which are subject to the same overhead constraints as mentioned in (1).
4) I think the problem with college courses i
s that most professors who design course curricula know about LabView, but they don't use it themselves -- their graduate students do. I've seen certain TA's make LabView instruction a pet project, but the novelty of G means that most students are happy to get to the point where they don't have broken wires everywhere (believe me, there's lots of swearing on LabView lab days). And most students are more worried about running their experiments than programming.
> 1) It seems to me that allowing people to pass pointers to complex
> data structures would allow for more efficient memory management. I
> know about refnums, but Shane and others seem to imply that
> refnums/property nodes come with unnecessary GUI overhead. I hate
> pointers as much as anyone else, but being able to pass by reference
> without overhead would be HUGE. Is there a way to do this?
Actually, many of LV's datatypes are implemented with references, but
the diagram behavior is as if they were done by value. You mention that
you hate pointers, presumably this is in a serial language with a single
thread doing one thing at a time. Putting pointers in a parallel
language is ten times as bad. If instead of an array, you had a
reference to the array and the wire splits, the split pieces of code
will interact. The top branch will do a filter, then a power spectrum,
then plot. The middle one will subtract off a baseline and get an rms
value. The bottom one will simply plot. Since there is no longer any
sequencing between them, they interleave and you get jibberish. To
clean things up you either serialize them by putting them back into a
wire, make explicit copies, or use mutexes and semaphores to control the
order of execution. Ick.
So LV and most other dataflow languages have by-value semantics, meaning
that a wire represents the value, not a reference. On the otherhand,
all arrays and strings, are implemented by reference. The LV compiler
then determines how few copies are needed in order to maintain the same
behavior as if all were copies. The performance and memory usage
chapter gives examples of how this works.
Is it possible to do pointers? Sure, some have done it. You call a
block that copies or swaps the data into a private storage, and gives
back a pointer/reference/U32. Later in their diagram, they call passing
in the pointer and get back the array, or some portion of it. Of course
LV knows nothing about these pointers, and you can't operate on things
using LV icons until you go get the data. In many cases this uses just
as much memory as the simple code without the pointers.
>
> 2) The "avoid local variables when possible" bit is news to me. But I
> get the point
>
> 3) as far as I know, the GOOP projects use refnums, which are subject
> to the same overhead constraints as mentioned in (1).
>
Current GOOP uses the pointer approach mentioned above, and all objects
are referred to. The reads and writes are also serialized so that if
you ask for the data on an object, you wait for someone else to finish
working on the object, then you get the elements, modify and return
them. Again, parallelism and pointers are something you have to manage
pretty closely.
>
> 4) I think the problem with college courses is that most professors
> who design course curricula know about LabView, but they don't use it
> themselves -- their graduate students do. I've seen certain TA's make
> LabView instruction a pet project, but the novelty of G means that
> most students are happy to get to the point where they don't have
> broken wires everywhere (believe me, there's lots of swearing on
> LabView lab days). And most students are more worried about running
> their experiments than programming.
This is the approach in the basket weaving class, the physics class,
etc. It isn't unique to LV. And really, the point of the class is
rarely to learn LabVIEW or another language, it is to learn some
principles, and to do that you need to use some tools. Some students
embrace the tools and realize they will need to know this later in life
while others hack their way through just enough to get the desired A, B,
or C.
Enjoy,
Greg McKaskle
> data structures would allow for more efficient memory management. I
> know about refnums, but Shane and others seem to imply that
> refnums/property nodes come with unnecessary GUI overhead. I hate
> pointers as much as anyone else, but being able to pass by reference
> without overhead would be HUGE. Is there a way to do this?
Actually, many of LV's datatypes are implemented with references, but
the diagram behavior is as if they were done by value. You mention that
you hate pointers, presumably this is in a serial language with a single
thread doing one thing at a time. Putting pointers in a parallel
language is ten times as bad. If instead of an array, you had a
reference to the array and the wire splits, the split pieces of code
will interact. The top branch will do a filter, then a power spectrum,
then plot. The middle one will subtract off a baseline and get an rms
value. The bottom one will simply plot. Since there is no longer any
sequencing between them, they interleave and you get jibberish. To
clean things up you either serialize them by putting them back into a
wire, make explicit copies, or use mutexes and semaphores to control the
order of execution. Ick.
So LV and most other dataflow languages have by-value semantics, meaning
that a wire represents the value, not a reference. On the otherhand,
all arrays and strings, are implemented by reference. The LV compiler
then determines how few copies are needed in order to maintain the same
behavior as if all were copies. The performance and memory usage
chapter gives examples of how this works.
Is it possible to do pointers? Sure, some have done it. You call a
block that copies or swaps the data into a private storage, and gives
back a pointer/reference/U32. Later in their diagram, they call passing
in the pointer and get back the array, or some portion of it. Of course
LV knows nothing about these pointers, and you can't operate on things
using LV icons until you go get the data. In many cases this uses just
as much memory as the simple code without the pointers.
>
> 2) The "avoid local variables when possible" bit is news to me. But I
> get the point
>
> 3) as far as I know, the GOOP projects use refnums, which are subject
> to the same overhead constraints as mentioned in (1).
>
Current GOOP uses the pointer approach mentioned above, and all objects
are referred to. The reads and writes are also serialized so that if
you ask for the data on an object, you wait for someone else to finish
working on the object, then you get the elements, modify and return
them. Again, parallelism and pointers are something you have to manage
pretty closely.
>
> 4) I think the problem with college courses is that most professors
> who design course curricula know about LabView, but they don't use it
> themselves -- their graduate students do. I've seen certain TA's make
> LabView instruction a pet project, but the novelty of G means that
> most students are happy to get to the point where they don't have
> broken wires everywhere (believe me, there's lots of swearing on
> LabView lab days). And most students are more worried about running
> their experiments than programming.
This is the approach in the basket weaving class, the physics class,
etc. It isn't unique to LV. And really, the point of the class is
rarely to learn LabVIEW or another language, it is to learn some
principles, and to do that you need to use some tools. Some students
embrace the tools and realize they will need to know this later in life
while others hack their way through just enough to get the desired A, B,
or C.
Enjoy,
Greg McKaskle
