This crashes LabVIEW on my computer

[MikaelH]

If I enable the Loop Parallelism on the this for loop I get this error:

Do you get the same?

compile_error.vi

I'm going to report this to NI Australia.

//Mike

[Jordan Kuehn]

I can reproduce in LV2012.

[MikaelH]

I can reproduce in LV2012.

Thanks, I'm using 2012f3, I guess I have to wait for SP1 get see this fixed.

//MIke

[Jordan Kuehn]

after double checking looks like I can reproduce in 2012F3.

[Mr Mike]

It's still broken in a yet-unannounced version after LV 2012, whose version number remains entirely unguessable.

I filed CAR 382426. I have no workaround, since I don't know much about the compile process. I've noted in the CAR to post the workaround here if there is one.

[MikaelH]

I filed CAR 382426.

Thanks, then I just let my local NI office know that the CAR if filed

[JamesMc86]

The last error referring to boolean data gives away that this is related to the conditional terminals on the outputs. Remove these and it works fine, going back to the old ways on these may solve the issue in this case (and give you better performance, the current performance is equivalent to build array in a case structure).

[MikaelH]

Remove these and it works fine,

Our real code is not exactly like this, but we'll try this and see it it fixes the issue.

[Rolf Kalbermatter]

The last error referring to boolean data gives away that this is related to the conditional terminals on the outputs. Remove these and it works fine, going back to the old ways on these may solve the issue in this case (and give you better performance, the current performance is equivalent to build array in a case structure).

Wow James! How should we know that csrc=0x21 means a boolean?

Of course now you have said it, I remember the typecodes of the typedef data, but would never have come on my own to this conclusion. Also is it just a problem with booleans on the conditional terminal or the conditional terminal in general? With booleans I could live easily as I usually would use bitflags anyhow for such applications.

[JamesMc86]

Its actually not that one but you get three or four errors the last of which mentions bool.

I have seen similar errors before, there is a bug in 2010 where if you have FPGA nodes and remote debug an RTEXE these get thrown and from that I know from experimenting from that each message will correspond to one node causing the issue (in that case it corresponded to the number of read/write nodes).

[MikaelH]

FYI it's easy to reproduce:

Using the Conditional Indexing output in a for loop with the TimeStamp type.

Then activate the parallelism on the loop.

[Darin]

The fix is simple, conditional tunnels should not be allowed in a parallel for loop, build the code in the conventional manner to see why. The compiler figures it out the hard way, but the IDE should not allow this.

[MFletcher]

Darin, do you say that conditional tunnels should not be allowed on Parallel For Loops because the conventional way of writing the code with a case structure and build array is not parallelizable, or is there another reason why you don't think it should be allowed?

The LabVIEW compiler actually transforms conditional tunnels into a representation that we can safely parallelize, but there are a few bugs that users have reported.

[Darin]

For some strange reason I was getting compile errors yesterday for all of my attempts to parallelize loops with conditional indexing. Perhaps playing with timestamps was a problem. A few reboots later and today I can actually get it to work in my benchmarking code.

Good news: On my dual-core machine I can get about 6% improvement by enabling parallelism.

Bad news: That still leaves it 4x slower than the standard replace+trim method.

It seems a bit finicky, but if the bugs are fixed then I will retract my comment and say let them stay. No Panacea, and it is yet to be determined if the modest boost is maintained if the code is optimized.

Virtual beer (real if I ever make to NI week) when the concurrent filter reduction significantly beats the optimized single thread version.

[Mr Mike]

It's still broken in a yet-unannounced version after LV 2012, whose version number remains entirely unguessable.

I filed CAR 382426. I have no workaround, since I don't know much about the compile process. I've noted in the CAR to post the workaround here if there is one.

 

This CAR has been fixed in LV 2013.  The fix should be in LV 2013 Beta 2.

 

MikhaelH: If you're part of the beta program, you can download the LV 2013 Beta 2 and test it out.  If not, PM me and I'll send you a link to sign up and my email address to get you into the beta program.

[MikaelH]

This CAR has been fixed in LV 2013.  The fix should be in LV 2013 Beta 2.

 

MikhaelH: If you're part of the beta program, you can download the LV 2013 Beta 2 and test it out.  If not, PM me and I'll send you a link to sign up and my email address to get you into the beta program.

Thanks,

I have both 32 and 64 bit versions for 2013b2 and I can test it this week.