Type conversion and inplaceness ?

[LAVA 1.0 Content]

[cross posted to NI forums]

Hi all,

I've been wondering for a long time if type conversion was inplace

In the example below, is there any case were inplaceness will happen ?

http://forums.lavag.org/index.php?act=attach&type=post&id=6668

My feeling is that :

- no inplaceness when there is a conversion dot,

- when converting to a representation with a larger bit depth, I believe inplaceness is not possible,

- when converting to a representation with the same bit depth, I believe inplaceness is possible,

- when converting to a representation with a smaller bit depth, I believe inplaceness is not possible.

Is that correct (speaking in LV 7.1.1) ?

What if put the same code in a LV 8.5 inplace structure ?

[Tomi Maila]

My educated guess is that LabVIEW will not reuse buffer in type conversions in any situation. This is confirmed by 'Show buffer allocation' tool at least for I32 -> U32 conversion (assuming the tool works properly). LV 8.5 in-place structure doesn't help as the input and output type must be same when using the structure. You can fairly easiy test if

[Grampa_of_Oliva_n_Eden]

QUOTE(Tomi Maila @ Aug 17 2007, 08:36 AM)

My educated guess is that LabVIEW will not reuse buffer in type conversions in any situation. This is confirmed by 'Show buffer allocation' tool at least for I32 -> U32 conversion (assuming the tool works properly). LV 8.5 in-place structure doesn't help as the input and output type must be same when using the structure. You can fairly easiy test if

I'm leaning the same way.

even an I32 > I32 feed from shift registers and stored in SR's still copies the data at its input.

Similarly for string to U8's.

Ben

Note: This has changed with newer version of LV. See NI link for Christian example.

[Aristos Queue]

I don't know the general answer. Use the memory allocation tool (Tools>>Profile>>Show Buffer Allocations) to see whether a given cast is inplace or not.

[LAVA 1.0 Content]

QUOTE(Aristos Queue @ Aug 17 2007, 03:43 PM)

Use the memory allocation tool (Tools>>Profile>>Show Buffer Allocations) to see whether a given cast is inplace or not.

Thanks for the the tip, I believe this was introduced in LV 8, is there a way to activate this in LV 7.1 ?

[Yair]

QUOTE(TiT @ Aug 17 2007, 05:11 PM)

Thanks for the the tip, I believe this was introduced in LV 8, is there a way to activate this in LV 7.1 ?

Actually, I think it was introduced in 7.1, but even if not, NI has a version on their site which I use with 7.0, so it should work with 7.1.

[crelf]

QUOTE(yen @ Aug 18 2007, 12:33 AM)

Actually, I think it was introduced in 7.1, but even if not, NI has a version on their site which I use with 7.0, so it should work with 7.1.

There was a LabVIEW.ini file key to enable it in older version(s) - I think it was something like "showbuffeallocations=true". If you do find out what it is, please add it to the http://wiki.lavag.org/LabVIEW_configuration_file' target="_blank">LabVIEW wiki.

[Grampa_of_Oliva_n_Eden]

QUOTE(crelf @ Aug 17 2007, 10:51 AM)

There was a LabVIEW.ini file key to enable it in older version(s) - I think it was something like "showbuffeallocations=true". If you do find out what it is, please add it to the http://wiki.lavag.org/LabVIEW_configuration_file' target="_blank">LabVIEW wiki.

showInplaceMenuItem=True

For LV 7.0 and prior. It those versions you had to look at the buffer for each wire one at a time.

Ben

[Yair]

The Show Inplace Set right click option is available for a specific wire with the INI key.

The buffer allocation tool is available for LV 7.0 here. It's built-in in 7.1.

[crelf]

QUOTE(Ben @ Aug 18 2007, 12:58 AM)

showbuffeallocations=true

showInplaceMenuItem=True

At least I got "show" right

[Kevin P]

Good question. I'm particularly interested in the I32<-->U32 kind of case.

I've been carrying around a factoid in my head for several years that such a conversion involves merely a reinterpretation of the bits and does not have to make a data copy. Probably back somewhere around LV RT 6.1, I did some execution time testing for converting a large array of U32's into I32's. At the time, I thought my observation was that the execution was too fast to include any memory allocation (didn't have the "Show Buffer Allocations" tool available). So I took that to mean that conversion between signed and unsigned ints did nothing to change or copy the bits in memory, it just reinterpreted them.

I've been relying on that factoid for a long time now, and will now have to see if I've been fooling myself.

P.S. Were there any weird behaviors of the "Show Buffer Allocation" tool, especially when it first came out? Somewhere along the line, I developed a degree of skepticism about that tool though I don't recall exactly why. It seems like everyone else finds it to be extremely reliable.

Same on the skepticism for the Profiler tool, only much more so. I have only rarely found it to be even a little bit helpful at tracking down memory or CPU hogs. I had an app running 24/7 for weeks. Windows' task manager would show me losing ~2MB available memory per day. But the Profiler couldn't find any vi with growing memory consumption. The max usage of any vi kept showing up at about 350 K, even after Task Manager had dropped by 100 MB.

-Kevin P.

[Grampa_of_Oliva_n_Eden]

QUOTE(Kevin P @ Aug 17 2007, 12:04 PM)

Good question. I'm particularly interested in the I32<-->U32 kind of case.

I've been carrying around a factoid in my head for several years that such a conversion involves merely a reinterpretation of the bits and does not have to make a data copy. Probably back somewhere around LV RT 6.1, I did some execution time testing for converting a large array of U32's into I32's. At the time, I thought my observation was that the execution was too fast to include any memory allocation (didn't have the "Show Buffer Allocations" tool available). So I took that to mean that conversion between signed and unsigned ints did nothing to change or copy the bits in memory, it just reinterpreted them.

I've been relying on that factoid for a long time now, and will now have to see if I've been fooling myself.

P.S. Were there any weird behaviors of the "Show Buffer Allocation" tool, especially when it first came out? Somewhere along the line, I developed a degree of skepticism about that tool though I don't recall exactly why. It seems like everyone else finds it to be extremely reliable.

Same on the skepticism for the Profiler tool, only much more so. I have only rarely found it to be even a little bit helpful at tracking down memory or CPU hogs. I had an app running 24/7 for weeks. Windows' task manager would show me losing ~2MB available memory per day. But the Profiler couldn't find any vi with growing memory consumption. The max usage of any vi kept showing up at about 350 K, even after Task Manager had dropped by 100 MB.

-Kevin P.

The buffer re-use only is valid after a save 9actually a recompile) and if you had not done that, you may have questioned the lack of a buffer.

The profile tool had a problem where it was not updating mem useage, but I do not remeber when that was fixed and what broke it.

Sorry!

Ben

[Yair]

By the way, just to make it clear, the Show Inplace Set right click option does something different than the Show Buffer Allocations tool - it allows seeing all the points in which a specific buffer would be reused and as such should be more helpful in this case.

It is, however, undocumented and as such might not work entirely as expected.

[Aristos Queue]

QUOTE(yen @ Aug 18 2007, 01:33 PM)

By the way, just to make it clear, the Show Inplace Set right click option does something different than the Show Buffer Allocations tool - it allows seeing all the points in which a specific buffer would be reused and as such should be more helpful in this case.

It is, however, undocumented and as such might not work entirely as expected.

I've never even heard of this option. When you say "undocumented", that would include the internal docs. Where did you find such a thing?

[Yair]

QUOTE(Aristos Queue @ Aug 19 2007, 09:15 AM)

I've never even heard of this option. When you say "undocumented", that would include the internal docs. Where did you find such a thing?

It's the showInplaceMenuItem=True key mentioned earlier. It adds a right click option on nodes and wires to show the inplaceness of a certain wire. It seems not to work in 8.5 beta (you don't get the right click option), so I assume it was removed because the Show Buffer Allocations tool was added and that probably works better. I know it works in 7.0.

As for finding it, I'm not one of those who hack LabVIEW.exe or sweet talk NI personnel to get secret INI keys. I guess I first saw it in one of the relevant sites (e.g. Brian Renken's site).

[David Boyd]

QUOTE(Aristos Queue @ Aug 19 2007, 02:15 AM)

I've never even heard of this option. When you say "undocumented", that would include the internal docs. Where did you find such a thing?

I can't speak to how reliable the use of the old ShowInplaceMenuItem token was, but I do recall one of its quirks - in fact I think I wrote this text that was up on Brian Renken's page:

QUOTE

Set to True to add "Show Inplace Set" to the popup menu you get when you right-click on a diagram terminal. Selecting this menu item makes the terminal, and all other terminals sharing the same data inplace, blink together.

Pop up again and select "Hide Inplace Set" before moving to another set of terminals, since it won't automatically stop blinking the first set before showing a new one.

Otherwise you got a wonderful bunch of little blinky things all over your BD..

[Kevin P]

Veering back to address the original topic of in-placeness during type conversion. I tried (inexhaustively) to probe this a bit for arrays of U32's being converted to I32's. I either auto-indexed a U32 array on a loop output or I started with a front panel array control. I compared the buffer allocations against cases that started with I32's and did no conversions. I saw no differences, making me think once again that U32-->I32 conversion occurs in-place.

And I'm still inclined think that no memory copying is done, though I didn't retest recently. I think all bits stay put, but the conversion to I32 will cause them to be interpreted differently.

Anyone have more definitive info?

-Kevin P.

[Tomi Maila]

QUOTE(Kevin P @ Aug 20 2007, 07:21 PM)

Anyone have more definitive info?

I tested converting an array of I32 to an array of U32 and then writing it to an indicator. I wrote another VI that was identical but lacked the convertion. The convertionless VI took less memory according to LV profiler in LV 8.5.