CLA-R Sample Exam Question 22

[herrlin]

Just looking for confirmation that the given answer of B for question 22 of the sample exam is wrong and should be A.  Thoughts?

http://download.ni.com/evaluation/certification/cla-r/cla-r_sample_exam_english.pdf

[crossrulz]

I would go with B simply because it is the one that needs the most processing, therefore being the one that could use the parallelism the most.

[JÞB]

Well,

a) Can't be right.  Its a candidate for the RG thread! a single IR&C would replace the loop completely

c) Can't be right: the loop has a conditional terminal

d) Can't be right: there is a dependance between loop iterations

That leaves b)

[herrlin]

My thoughts are this:

A – The best answer because it doesn’t have a dependency on a previous iteration and it doesn’t not have conditional terminal.

B – The shift registers make this a bad candidate because they create a dependency on a previous iteration and therefore have to be performed sequentially.

C – The conditional terminal will cause an error in LabVIEW if the loop is set up to run in parallel, iteration need to be performed sequentially.

D – Same logic as B

[herrlin]

---

@JÞB wrote:

Well,

a) Can't be right.  Its a candidate for the RG thread! a single IR&C would replace the loop completely

c) Can't be right: the loop has a conditional terminal

d) Can't be right: there is a dependance between loop iterations

That leaves b)

---

Isn't in B ther also a depandancy between loop iterations?

Also not following your acronyms for A -  RG & IR&C

[JÞB]

in B) only one row is updated per iteration (The SR doesn't necessarilly create a dependance between iterations)

in D) iterations must execute in order since row 0 is updated based on current row 0 data in each itteration 

RG- is the Rube-Goldberg Thread

Why run all cores?  Its a bad Idea to try to improve the performance of sub-optimal code constructs Benchmark the two methods (Parrallel For loop and no loop) see witch is more optomized.

IR&C is In-Range and Coerce of course,

[Darin.K]

---

@herrlin wrote:

---

---

Isn't in B ther also a depandancy between loop iterations?

---

Nope.  You are indexing and replacing the same row.  This happens to be a very esoteric question which is probably why it is on the sample exam.  This particular cosntruct, index + something + replace with same wiring as index is recognized as inplace my the compiler and therefore safe to parallelize.  If memory serves, in LV9 which is what I use, to get away with that SR, the shared wire between the index and replace must originate in the iteration terminal or the VI is broken.

As drawn, B is correct, although outside of those at NI who implemented this feature, I'll wager the number of people who would get this correct for the correct reason is quite small.

[Intaris]

Canyou even parallelise loops which don't have autoindexed inputs?  I thought you could only properly paralellise a for this reason (As the loop is currently written).

Shane

[JÞB]

---

@Intaris wrote:

Canyou even parallelise loops which don't have autoindexed inputs?  I thought you could only properly paralellise a for this reason (As the loop is currently written).

Shane

---

Yes, you can. In all cases # of iterations must be determistic (No conditional terminal) but that is true for any for loop without a conditional terminal that does not break the compiler.

[Darin.K]

---

@Intaris wrote:

Canyou even parallelise loops which don't have autoindexed inputs?  I thought you could only properly paralellise a for this reason (As the loop is currently written).

Shane

---

Indexing with the iteration terminal is recognized as similar to autoindexing.  That is why I mentioned the importance of the wire originating in the iteration terminal.  You could replace the Index Array with an autoindexed input and it should still parallelize just fine.

(This is from memory, if you have doubts please try it and correct me).