A New way to GOOP

[Mark Balla]

With Brian's permission I would like to start a discussion on his new implementation of goop called dqGoop.

For those of you that are not on the OpenG mailing list Brian Gangloff has developed an new way of doing goop using Ques

here is his original zip file.

Download File:post-584-1114495400.zip

It contains 3 different implementations of goop. niClass(Endevo version of goop with locked BD ), openClass(OpenG's version of goop ) and dqClass(new version using ques ). Each of the class have vis that can be used to compare performance.

After playing with the dqClass awhile I replied with some ideas and here was his response.

Hi Mark and Jim,

Thanks for looking at dqGOOP. Since Mark and Jim both brought up the same point, I will just reply to the one and copy everyone in.

Brian

Mark Balla wrote:

>

> Brian,

>

> I was playing around with the dqGoop this weekend. Very nice Idea Goop is probably my favorite LabView topic.

> This approach looks much more elegant as well a smaller footprint. I am very interested in any information you have on performance

> improvements with dqGoop vs. OpenGoop.

>

Did you download the zip file that that was mentioned in the email that

you replied to (bottom of this one as well)? It has 3 test classes,

they can be found in the respective ..\Testing directories. OpenGOOP

does very well on get and set, but the create time is very slow. Please

run the tests on your computer and let me know how dqGOOP compares.

> I have a suggestion to help fix an issue I found.

>

> First the issue

> Because the Modify Data vi removes the data from the Que this leaves the que blank. So any program that needs to only read the data can not

> do so until the data is put back. This creates a bottle neck in Goop vis like mine where several loops only read the object data and only 1 or 2

> vis change it. If I have a Modify vi that takes 500 ms to update the data then all the read vis must wait that time before moving on. OpenGoop does

> not have this issue because the semaphore only stops other programs from changing not reading.

>

It has been my opinion (and I could be wrong), that locking the data

should do just that, lock it. Once the Modify VI gets the data, it is

no longer valid data since the Modify VI is changing it. The question

is then, when you want to get data do you want the latest data (wait for

lock) or is old data OK. dqGOOP currently provides the mechanism for

the first, but as you and Jim have pointed out there isn't a way for the

second. The attached new template could provide a solution for some

instances with only a few Modify methods, but could end up with a race

condition if you had many Modify methods.

I will have to think a bit on how to provide access to old (last before

lock) data. I don't have the time to look at your example code, but

from the description it sounds like too much overhead. If you haven't

yet, read the first three topics in the help file. They give a good

description of why I started to develop dqGOOP, but it all boils down to

performance. I have applications that need to be able to create and

access many GOOP objects quickly.

> I think I found a way to avoid this issue with only a few changes to the core code.

> Suggested Changes

>

> Create New Object Vi

> Instead of a Que size of 1 use a size of 2. Most of the time there will

> only be one data set in the que except when updating changed data.

>

> Get Data to Modify Vi

> Acquire a Semaphore

> Preview Que data. This will still allow others to read it also.

>

> Set Modified Data Vi

> Enqueue the New Data

> Dequeue the Old Data. This leaves only the new data remaining while never

> forcing other vis to wait for data

> Release Semaphore.

>

> I have example code that I've attached.

>

I will look at it but it probably won't be until next week since I will

be out of the office this coming week and half of the next.

> dqGoop may be the concept that brings Goop the the masses.

>

I hope so, but credit has to be given to Endevo for bringing it first

and OpenGOOP for providing the first open source version.

> I don't know if you are a LV8 beta tester or not but this approach

> will fit very nicely with the new LVOOP classes.

>

No I'm not, but its good to hear. I like "LVOOP" class, is that NIs

official terminology?

> Can I request that you please create a post on Lava or OpenG or both

> so we can start discussions with the LV community?

>

Yes, but probably not until I return. Or if you want to start one, I

can join when I return.

> Great concept and thanks for sharing it.

>

Thanks for looking

> Mark

Here is the example code that I attached.

Download File:post-584-1114495473.zip

I'll talk about my preformance findings in a later post.

[Mark Balla]

Taking The original dqClass I created a new class calling it DQ2 and modified it as I stated in my email.

Download File:post-584-1114495781.zip

Using the TestClassPerformance.vi I got the following results.

Not exactly what I expected. The DQ2Class was much faster at creating and deleting than the openClass but it took twice as long to run the Modify Data vi.

If any one has any ideas why this is so

or got different results please let me know.

Any way the times were not even close to the original dqclass

so I created a new class that eliminated the Semaphores.

Download File:post-584-1114500356.zip

The 3 vis that changes were

Create New

getDataToModify

setModifiedData

And the performance results were much better.

That is what I have so far. Does anyone have anything to add.

[dafemec]

I am glad to see an OpenG version of this. In part owing to the commitment already made to the OpenG implementation by a number of developers, improvements that can be worked into a drop-in replacement for the OpenG core code would be preferable to improvements that require reworking or scrapping classes already built on the OpenG core code.

Also, in the interest of historical completeness, we would be remiss to leave out Stan Case's contributions to GOOP. The GOOP wizard he developed while at V I Engineering, and which is presented in the LabVIEW Advanced Application Development course (originally written by Stan, and now managed by NI), provided many of us our first introduction to GOOP.

[Mark Balla]

Also, in the interest of historical completeness, we would be remiss to leave out Stan Case's contributions to GOOP.  The GOOP wizard he developed while at V I Engineering, and which is presented in the LabVIEW Advanced Application Development course (originally written by Stan, and now managed by NI), provided many of us our first introduction to GOOP.

4683[/snapback]

Thankyou for mentioning this. Stan is acually the one responsible for getting me excited about Goop. I was first exposed to Goop when I attended his pesentation at NI week.

I am glad to see an OpenG version of this.  In part owing to the commitment already made to the OpenG implementation by a number of developers, improvements that can be worked into a drop-in replacement for the OpenG core code would be preferable to improvements that require reworking or scrapping classes already built on the OpenG core code.

I agree, It should be a core replacement and I've already done this with my OpenG Goop template.

But I sometimes tend to jump on the band wagon too quickly and in the past have regretted not testing out new Ideas

or ask for others opinion.

In my initial post I didn't really ask anything so I'll do in now.

Is this the next step in the goop evolution.

Does anyone see any issues, preferences or ways to improve the DQ2 or DQ3 Ideas.

[Mark Balla]

Here is the latest Goop Ideas branching off of the dqClass.

DQ3 uses a Que with 2 elements

data is locked when only one item is in the Que

to lock data one of the items is dequeued.

to write new data the Que is flushed and two data items are enqueued.

Download File:post-584-1115993086.zip

I also created a possible core replacment for the OpenG template using the DQ3 Idea.

Download File:post-584-1115994581.zip

DQ4 uses a Que with 1 element and a lock bit bundled inside the Que data.

Data is locked when lock bit is set true.

to lock data the the data is dequeued the bit is set true and then data is enqueued.

to write new data the data is dequeued and the new data is bundled with a false lock bit and enqueued.

Download File:post-584-1115992930.zip

DQ5 Uses two 1 item Ques one for the data and one for the lock bit.

Data us locked when the lock Que is empty.

to lock data the lock bit is dequeued.

to write new data the data is dequeued and new data is enqueued and the lock bit is enqueued

Download File:post-584-1115992961.zip

All of the above allow the data to be read while the data is locked. The original dqclass did not.

Here are my performance test results

[MagicWand]

Will I run into troubles if I try to convert the DQGOOP system from 7.0 to 6.1 to 6.02 ???

[brian175]

Will I run into troubles if I try to convert the DQGOOP system from 7.0 to 6.1 to 6.02 ???

4764[/snapback]

Converting to 6.1 will not be a problem, but performance is worse. dqGOOP takes advantage of internal optimizations that NI made to the queue in LV 7.0 and later. Converting to 6.02 will cause some broken arrows since the structure of the queue changed from LV 6.0 to LV 6.1. For one, there isn't a "preview" function in the 6.02 queue which is used by the getData function. You could possibly work around by using status or just dequeue and enqueue in the getData function.

I need to rerun my 6.1 performance test, but I think that niGOOP was the overall winner, but OpenGOOP was faster for set and get operations.

[klessm1]

Here is the latest Goop Ideas branching off of the dqClass.

DQ3 uses a Que with 2 elements

data is locked when only one item is in the Que

to lock data one of the items is dequeued.

to write new data the Que is flushed and two data items are enqueued.

I noticed a couple of drawbacks with the DQ3 syle of GOOP. One was that there is no way to find all of your active objects. You have to remember them somewhere else and get them. The current templates could be updated with a LV2 style global to remember all of the names and corresponding queues. They could then be created, retrieved, and removed from this repository.

The other thing I noticed was that the -1 timeout would timeout right away during the DQ3Class_getDataToModify.vi. I think this was just overlooked?

Good ideas! :thumbup: Nice to see new ways to perform GOOP.

[Mark Balla]

I noticed a couple of drawbacks with the DQ3 syle of GOOP. One was that there is no way to find all of your active objects. You have to remember them somewhere else and get them. The current templates could be updated with a LV2 style global to remember all of the names and corresponding queues. They could then be created, retrieved, and removed from this repository.

My solution to your issue would be to create a Master DQ3class that manages the other minor classes. The Master class would have an array of

minor class references in its data cluster.

Essentially DQ3 is a type of global variable just like LV2. You could just as easily create another DQ3 class or a Single item que to do what your requesting.

The other thing I noticed was that the -1 timeout would timeout right away during the DQ3Class_getDataToModify.vi. I think this was just overlooked?

Yes I believe this was an oversight.

Here is the current template I use if you are interested.

Download File:post-584-1137095989.zip

Support Files are Now included. Thanks Michael,

Ok lets try again

Download File:post-584-1137308121.zip

And here is the template with everything included

Download File:post-584-1137308268.zip

[Michael Aivaliotis]

My solution to your issue would be to create a Master DQ3class that manages the other minor classes. The Master class would have an array of

minor class references in its data cluster.

Essentially DQ3 is a type of global variable just like LV2. You could just as easily create another DQ3 class or a Single item que to do what your requesting.

Yes I believe this was an oversight.

Here is the current template I use if you are interested.

Some support VI's are missing, can you re-upload the zip. Since you're a Premium Member, just go back and re-edit your original post and replace the attachment. No need to re-post.