Polskie Centrum LabVIEW

Ja odnośnie tego tematu. In Place jest jednym z tych elementów (obok break i rekurencji), dla których rozważam przejście na 8.5, które jak do tej pory leży sobie w kopercie nawet nieodfoliowane. Zawsze mnie dziwiło, że żeby zmienić jeden element tablicy trzeba robić taki wygibas, a w dodatku cała tablica jest kopiowana. Tym bardziej jest to dla mnie istotne, że często operuję na dużych tablicach idących w miliony elementów - nierzadko rozbudowanych klastrów. Co prawda nie zauważyłem, żeby podmiana elementów w tych tablicach była jakimś wąskim gardłem, ale perspektywa przyspieszenia i zwiększenia przejrzystości kodu jest dla mnie kusząca. I dlatego zdziwiły mnie opinie, że to wcale nie jest takie piękne jak się wydaje.

Mam więc prośbę do kogoś kto dysponuje LV8.5 i chwilką czasu by przeprowadził jakieś miarodajne testy, które byśmy tu wcześniej zaprojektowali i obdyskutowali.

Nasunął też mi się pomysł "trzeciego przypadku": funkcja w C, skompilowana do DLL, która umieszcza przekazanego jej stringa w miejscu pamięci wyznaczonym przez przekazany wskaźnik i ofset (iloczyn przekazanego indeksu i długości stringa), po czym zwraca wskaxnik, który dostała. Pełniłoby to taką rolę jak In Place - przekazuje się tablicę przez wskaźnik, indeks do podmiany i "zflatenowany" do stringa element do podmiany. String musiałby oczywiście mieć na początku zapisaną swoją długość ze względu na to, że może zawierać zera. Ciekawi jak miałoby się wywoływanie tego za pomocą Call Library Function Node do wersji klasycznej i In Place. Czy LV kopiowałoby całą tablicę?

Sprawdzone, przetestowane, nie tylko na tym przykładzie z linka z forum NI z bugiem ale i na Compact FieldPoincie w LabVIEW RT.
Mam program, gdzie występuje dużo podmian, liczenia z zagnieżdżonych klastrów, podstawień itp. Nie ma problemów.
Pojawiają sie dopiero kiedy ktoś chce stosować dwie konwencje na raz, to znaczy In Place dla Index/Replace Array a Bundle/UnBundle zamiast odpowiedniego In Place'a .

Na 8.5 ogólnie ujmując warto.
Na przyklad dla folderów projektu synchronizowanych lub nie do zawartosci w rzeczywistych folderach i jeszcze kilku innych pozytywnych rozwiązań.

Zresztą teraz to już 8.5.1 powinno być w folii na biurku

Ciekawi mnie jednak informacja ilościowa...

Niestety zdążył mi się skończyć support przed 8.5.1

Najprościej zatem będzie rozpakować pudełko i zrobić konkretne, interesujące testy.
Na pewno In Place poprawia czytelność kodu i na pewno nie obniża jego prędkości wykonania.

Robiłem wczoraj jakieś małe testy i wyszło na to, że In Place nie zwiększa prędkości działania, a jeśli występują jakieś różnice to raczej na korzyść rozwiązania klasycznego.
Testowałem tryby Index/Replace Array i Unbundle/Bundle (dla klastrów). Rzecz polegała na zamianie 10000 elementów 100000-elementowej tablicy. W pierwszym przypadku sprawdzałem tablicę doubli; w drugim - tablicę klastrów z klastrami tablic klastrów... Chodziło o to żeby maksymalnie skomplikować strukturę danych, w której gdzieś zagrzebana znajdowała się właściwa podmieniana liczba typu double.
Spodziewałem się zobaczyć coś takiego:

• dla prostego typu danych - brak wyraźnych różnic ewentualnie niewielka przewaga rozwiązania klasycznego.
• dla typu złożonego (którego optymalizacja powinna być dla kompilatora trudniejsza) - przewaga In Place

Wyniki były dość zaskakujące: czas wykonania In Place w obydwu przypadkach był większy w stosunku ok. 1,2:1
Robiłem też jakieś inne testy, w niektórych był mniej więcej remis, ale w żadnym z nich rozwiązanie In Place nie uzyskało przewagi czasowej, a tego właśnie można by się spodziewać, po umiejscowieniu In Place w kategorii Memory Control. Tutaj też dość ostrożnie jest sformułowana teza, że In Place nie przyspiesza.
Podsumowując:

In Place poprawia czytelność kodu

PRAWDA Różnica jest szczególnie widoczna przy złożonych typach danych - to na pewno jest powód, dla którego warto ją stosować.

nie obniża jego prędkości wykonania

NIE ZAWSZE PRAWDA
Na pewno warto stosować In Place jako część dobrego stylu - czytelność kodu poprawia się znacząco.
W zastosowaniach, gdzie każdy zysk na efektywności jest sprawą kluczową, warto przetestować obydwa rozwiązania i wybrać bardziej efektywne.
Przy okazji znalazłem też ciekawego kruczka TUTAJ - warto być ostrożnym, ale to akurat nie pierwszy i zapewne nie ostatni z takich bugów w LV. Wino kiedyś znalazł kiedyś coś podobnego. (Rozwikłałeś to, wino?) Zwróćcie uwagę na numery probówek w pierwszym i drugim przypadku - może są jakieś przeklęte ;]
Pozdrawiam
PS. Nie udostępniam viajów testowych, bo są brzydkie i niepoukładane i też nie są niczym specjalnym, ale jakby ktoś był zainteresowany, to poukładam i wrzucę.

1. Odnośnie próbowek (probe) - te elementy sa owszem stosowane dla "prezentacji danych w trybie rzeczywstym" jednak pracują w wątku o wyraźnie niskim priorytecie . Najlepiej widać to w aplikacjach RT, w pozostalych też jest to dostrzegalne. Stąd moga własnie wynikać różnice w wynikach w prezentowanych przez ciebie przykładach.
2. Wątek
na forum NI to przykład jak wpływa łamanie pewnej konwencji tworzenia kodu - warto go prześledzić, a zwłaszcza rozwiązania.
Krótko: zamiast stosować wewnątrz kodu In Place'a w trybie Array Index - Replace element elementy Unbundle/ Bundle cluster
wystarczy zastosować In Place w odpowiednim trybie czyli własnie UnBundle - Bundle cluster czyli trzymać sie jednego sposobu tworzenia kodu.

Stąd moga własnie wynikać różnice w wynikach w prezentowanych przez ciebie przykładach.

W przykładzie wina problem wynika najprawdopodobniej z błędnej interpretacji wskazań probówek; w przykładzie z forum NI w dwóch różnych częściach druta rzeczywiście siedzą dwie różne wartości i można to sprawdzić, niekoniecznie probówką.

zamiast stosować wewnątrz kodu In Place'a w trybie Array Index - Replace element elementy Unbundle/ Bundle cluster wystarczy zastosować In Place w odpowiednim trybie czyli własnie UnBundle - Bundle cluster czyli trzymać sie jednego sposobu tworzenia kodu

A jak ktoś spyta "dlaczego, skoro obydwa sposoby są poprawne"? (To oczywiście pytanie retoryczne.)
Wątek jest poświęcony temu czy warto, czy nie warto iść w stronę In Place i (być może) przerabiać istniejące programy oparte na metodzie klasycznej, - taki bug jest głosem przeciw.
Pozdrawiam ]

Głosem przeciw stosowaniu narzedzia Probe? Może. Dla mnie raczej
jest to wniosek o ograniczonym zaufaniu, wspominam o tym w wypowiedzi powyżej: wątek o niskim priorytecie.
Mam wrażenie, że opierasz na wskazaniach narzedzia Probe tezy o poprawności pracy struktury In Place bez sprawdzenia jej dzialania w najprostszy alternatywny sposób.


Załaczam zatem screen i VI, analogiczny do tego, od którego rozpoczeła sie dyskusja na forum NI.

Nie zrozumieliśmy się.

taki bug jest głosem przeciw

Głosem przeciw stosowaniu narzedzia Probe?

Nie. Bug w strukturze In Place jest głosem przeciwko stosowaniu struktury In Place. vugie pytał ile ta struktura jest warta, więc jak na razie mamy:
zaleta:

• poprawa czytelności kodu

wady:

• niezwiększenie szybkości działania programu (czasem zmniejszenie)
• możliwość wystąpienia różnych niespodziewajek (jak ta podlinkowana)

A co do probówek... Jakiego by priorytetu nie miały, to mają działać dobrze przy ich właściwym użyciu i poprawnej interpretacji wyników (Zagadka wina jest - najprawdopodobniej - przykładem złej interpretacji, ale nie bugiem w LV).

Mam wrażenie, że opierasz na wskazaniach narzedzia Probe tezy o poprawności pracy struktury In Place bez sprawdzenia jej dzialania w najprostszy alternatywny sposób.

Zarówno tezy o poprawności jej pracy w rozwiązaniach, które przytoczyłeś na rysunku, jak i o tym, że w tymrozwiązaniu (składniowo poprawnym!) objawia się bug.
Zamiast probówek można podłączyć dwa klocki Equal, podłączyć do jednego 2, do drugiego - 0 i na obydwu wyjściach będziemy mieć TRUE.
Co do priorytetu probówek, to nikt raczej nie robi screenshota probówek przy kręcącym się programie. Chociaż... ;) Na jakiej podstawie opierasz twierdzenie o ich niskim priorytecie (nowoutworzona probówka jest viajem o priorytecie normalnym)?
Pozdrawiam ]

Jogurcie, ok, mamy diagram: taki czyli ten na który enigmatycznie powołujesz sie linkami

co jest na kontrolkach? bo jak na razie mam tylko tekst, pokaż mi to na kodzie. (Talk is cheap - pamietasz Linusa?)
Z mojej strony wyglada to tak:...ha wersja porównawcza (...też mnie podkusiło...)

Wnioski wewnatrz struktury InPlace nie nalezy stosowac starszych wersji operacji jesli te moga być zrealizowane przez InPlace.
Zakładam że jest juz na to CAR (Corrective Action Request) i numer u NIMenów. Ha i jeszcze jedno - sprawdzałem na 8.5, może ktoś to sprawdzić na 8.5.1 ?

Lepiej później niż wcale, ale w końcu się dogadaliśmy.

Talk is cheap

Czasami jednak warto też co nieco przeczytać obok obrazka, bo jak ktoś na wstępie z rozpaczą pisze "I won't use this structure anymore -- it is unreliable", to znaczy, że jednak coś musi być na rzeczy.
Probówki uniewinnione? ;)

Nie, próbówkom sie zawsze bedzie dostawać, sprawdź kiedys jak się zachowują w RT.
A jak wynika z przykładów - InPlace samo w sobie jest rygorystyczną konwencją tworzenia kodu - albo InPlacy wszędzie gdzie mozna - łaczenie z klasyka niedopuszczalne.

Swoją drogą sprawdziłem na 8.5.1 - to samo

Ciekawe jak bedzie w 8.6.