eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingprocedura tworzenia programów
Ilość wypowiedzi w tym wątku: 130

  • 111. Data: 2012-02-20 19:26:13
    Temat: Re: procedura tworzenia program?w
    Od: Bronek Kozicki <b...@s...net>

    On 20/02/2012 18:29, Edek Pienkowski wrote:
    > (nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i
    > transactional memory będzie dostarczane z kompilatorem, a za
    > jakiś czas będzie standartem faktycznym i skończy się to voodoo.

    łudzisz się. Po pierwsze, pamięć transakcyjna musi mieć wsparcie w
    sprzęcie, a to dopiero jest na etapie eksperymentów. Po drugie, prawo
    Amdahla pozostanie i trzeba będzie się gimnastykować nad skalowalnością
    programów niezależnie od tego jak będą wyglądały mechanizmy synchronizacji.


    B.


  • 112. Data: 2012-02-20 19:31:11
    Temat: Re: procedura tworzenia program?w
    Od: Bronek Kozicki <b...@s...net>

    On 20/02/2012 19:26, Bronek Kozicki wrote:
    > On 20/02/2012 18:29, Edek Pienkowski wrote:
    >> (nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i
    >> transactional memory będzie dostarczane z kompilatorem, a za
    >> jakiś czas będzie standartem faktycznym i skończy się to voodoo.
    >
    > łudzisz się. Po pierwsze, pamięć transakcyjna musi mieć wsparcie w
    > sprzęcie,

    zanim ktoś mnie weźmie za słowo, dodam: bo inaczej bez tego jest zbyt
    wolna, aby była pożyteczna na większą skalę.


    B.


  • 113. Data: 2012-02-20 19:31:46
    Temat: Re: procedura tworzenia program?w
    Od: Michoo <m...@v...pl>

    W dniu 20.02.2012 19:29, Edek Pienkowski pisze:
    > Ale zgadzam się, że wielu programistów tego nie ogarnia,
    > co jest jedną z dwóch głównych motywacji transactional memory
    > (nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i
    > transactional memory będzie dostarczane z kompilatorem, a za
    > jakiś czas będzie standartem faktycznym i skończy się to voodoo.
    Pamięć transakcyjna oparta o biglock ma rozwiązać problem?

    --
    Pozdrawiam
    Michoo


  • 114. Data: 2012-02-20 19:55:36
    Temat: Re: procedura tworzenia program?w
    Od: Edek Pienkowski <e...@g...com>

    Dnia Mon, 20 Feb 2012 20:31:46 +0100, Michoo napisal:

    > W dniu 20.02.2012 19:29, Edek Pienkowski pisze:
    >> Ale zgadzam się, że wielu programistów tego nie ogarnia,
    >> co jest jedną z dwóch głównych motywacji transactional memory (nie da
    >> się popsuć). Jeszcze jedna czy dwie wersje gcc i transactional memory
    >> będzie dostarczane z kompilatorem, a za jakiś czas będzie standartem
    >> faktycznym i skończy się to voodoo.
    > Pamięć transakcyjna oparta o biglock ma rozwiązać problem?

    Nie rozumiem. Dlaczego oparta o biglock? Co to ma do kwestii
    "programowanie bez locków nie wywoła deadlocków"?

    Edek


  • 115. Data: 2012-02-20 19:57:27
    Temat: Re: procedura tworzenia program?w
    Od: Edek Pienkowski <e...@g...com>

    Dnia Mon, 20 Feb 2012 19:31:11 +0000, Bronek Kozicki napisal:

    > On 20/02/2012 19:26, Bronek Kozicki wrote:
    >> On 20/02/2012 18:29, Edek Pienkowski wrote:
    >>> (nie da się popsuć). Jeszcze jedna czy dwie wersje gcc i transactional
    >>> memory będzie dostarczane z kompilatorem, a za jakiś czas będzie
    >>> standartem faktycznym i skończy się to voodoo.
    >>
    >> łudzisz się. Po pierwsze, pamięć transakcyjna musi mieć wsparcie w
    >> sprzęcie,
    >
    > zanim ktoś mnie weźmie za słowo, dodam: bo inaczej bez tego jest zbyt
    > wolna, aby była pożyteczna na większą skalę.

    Ja pisalem o "nie da się zepsuć", a nie o tym, o czym pisze większość,
    czyli demonie szybkości. Wydajność tego typu jest potrzebna może w 1%
    zastosowań.

    Edek


  • 116. Data: 2012-02-20 20:03:58
    Temat: Re: procedura tworzenia program?w
    Od: Edek Pienkowski <e...@g...com>

    Dnia Mon, 20 Feb 2012 19:55:36 +0000, Edek Pienkowski napisal:

    > Dnia Mon, 20 Feb 2012 20:31:46 +0100, Michoo napisal:
    >
    >> W dniu 20.02.2012 19:29, Edek Pienkowski pisze:
    >>> Ale zgadzam się, że wielu programistów tego nie ogarnia,
    >>> co jest jedną z dwóch głównych motywacji transactional memory (nie da
    >>> się popsuć). Jeszcze jedna czy dwie wersje gcc i transactional memory
    >>> będzie dostarczane z kompilatorem, a za jakiś czas będzie standartem
    >>> faktycznym i skończy się to voodoo.
    >> Pamięć transakcyjna oparta o biglock ma rozwiązać problem?
    >
    > Nie rozumiem. Dlaczego oparta o biglock? Co to ma do kwestii
    > "programowanie bez locków nie wywoła deadlocków"?


    Dodaję, że przypuszczam, że pomyliłeś implementację z semantyką:

    The transactional memory system to be implemented in GCC provides single
    lock atomicity semantics. That is, a program behaves as if a single
    global lock guards each transaction.

    Kluczowe jest "as if".

    Pozdrawiam
    Edek


  • 117. Data: 2012-02-20 21:26:37
    Temat: Re: procedura tworzenia program?w
    Od: Wojciech Jaczewski <w...@o...pl>

    A. L. wrote:

    > Poza tym zadziwie mnei pakowanie watkow do kategorii "moda". Ciekawe
    > jak Kolega zrobi pod Windows, w Javie, program ktory bedzie robil
    > dlugie obliczenia, a uzytkownik bedzie chcial mniec wglad w stan tych
    > obliczen bez przerywania procesu obliczania. Rozumiem ze bedzie jedna
    > wielka petla ktora co milisekunde bedzie sprawdzala stan klawiatury i
    > co milisekunde wysylala na ekran?

    Gałąź wątku zaczęła się od komentarza dotyczącego programisty C++. Inaczej
    się robi w Javie (nie mam w niej większego doświadczenia) a inaczej w C++.

    W C++ długotrwałe obliczenia wolałbym wyrzucić do osobnego procesu - bo
    proces w przeciwieństwie do wątku, zawsze daje się zatrzymać/ubić - gdyby
    użytkownik stwierdził że jednak mu to obliczenie niepotrzebne.


  • 118. Data: 2012-02-20 21:38:07
    Temat: Re: procedura tworzenia program w
    Od: Wojciech Jaczewski <w...@o...pl>

    Andrzej Jarzabek wrote:

    >> Wolę message passing na procesach.
    >> Częściowo wynika to z tego, co dotychczas robiłem, a POSIX-owe API ma
    >> bardzo poważne - jak dla mnie - wady:
    >> - pthread_cond_timedwait operuje na czasie systemowym a nie monotonicznym
    >
    > A do czego byś chciał używać tej funkcji, że ci to robi różnicę?

    Włącza się jakieś urządzenie, które mogło być ileś dni wyłączone, więc ma
    zegar rozsynchronizowany o kilka minut. Synchronizacja nastąpi wtedy, gdy
    będzie łączność z internetem, a ta może być od razu, a może za pół godziny.

    Nie mogę w takim przypadku używać pthread_cond_timedwait, bo zamiast
    poczekać planowane np. 5 sekund, raz poczeka mi 0 sekund a raz 5 minut.

    >> - nie mam możliwości nastawić czekania (select/poll) na pierwsze ze
    >> zdarzeń: cond (lub semafor), otrzymanie danych na socket-cie.
    >
    > Można to łatwo zrobić tworząc osobne wątki, które czekają na zdarzenie
    > i generują komunikat czy warunek, na który czeka "główny" wątek.

    I w ten sposób zwiększyć komplikację programu, bo pojawia się więcej
    równoległych wątków niż byłoby w wersji z potokami/gniazdami.


  • 119. Data: 2012-02-20 21:51:48
    Temat: Re: procedura tworzenia program?w
    Od: Wojciech Jaczewski <w...@o...pl>

    Michoo wrote:

    > Ja mówię o imo najsensowniejszym układzie w większości przypadków:
    > - producent/ci generujący zdarzenia przetwarzania
    > - konsument/ci generujący wynik i ewentualne zdarzenia odpowiedzi(np
    > większość GUI pozwala na wywołania tylko z wątku głównego)
    > - cały kontekst enkapsulowany w żądaniu/odpowiedzi.

    A czy masz jakieś narzędzie, które automatycznie zweryfikuje, że
    rzeczywiście cały kontekst jest enkapsulowany? W przypadku procesów: jeśli
    nie używają pamięci dzielonej - jest oczywiste, że cały kontekst przechodzi
    przez potoki/gniazda/itp. Jeśli jest pamięć dzielona, jest gwarancja że
    jeden proces może namieszać drugiemu tylko w tej pamiędzi dzielonej, ale nie
    w pozostałych blokach.
    [Podejrzewam że istnieją języki, w których da się taką weryfikację zrobić; w
    tej chwili chodzi mi o C/C++].

    >> Częściowo wynika to z tego, co dotychczas robiłem, a POSIX-owe API ma
    >> bardzo poważne - jak dla mnie - wady:
    >> - pthread_cond_timedwait operuje na czasie systemowym a nie monotonicznym
    >> - nie mam możliwości nastawić czekania (select/poll) na pierwsze ze
    >> zdarzeń: cond (lub semafor), otrzymanie danych na socket-cie.
    >> A skoro zwykle i tak muszę używać komunikacji przez potok lub gniazdo, to
    >> wolę osobny proces zamiast wątku.
    > Ok. Ale to już specyfika problemu.
    >
    > A ja piszę, że ogólnie o ile ktoś wie jak je używać to wątki są dobre.

    Pewnie w niektórych przypadkach mogą być dobre.
    Ja po prostu widziałem (a i sam tak robiłem dopóki się tego nie oduczyłem)
    bardzo wiele programów, które dało się zrobić w jednym wątku na select/poll,
    a były robione na wielu wątkach, co skutkowało wielokrotnie dłuższym czasem
    ich testowania i likwidowania co bardziej uciążliwych błędów.
    Prawie każdy wie co to jest wątek i do czego służy, natomiast znacznie
    mniejszej liczbie ludzi chce się zagłębić w to, jak działa system
    operacyjny, w którym tworzone przez nich programy będą uruchamiane i jakie
    przydatne rzeczy ten system oferuje.
    Jeśli ktoś zna alternatywy i wybierze wątki - OK, ale często wybieranie
    wątków wynika z nieznajomości tych alternatyw.


  • 120. Data: 2012-02-21 09:24:20
    Temat: Re: procedura tworzenia program?w
    Od: Roman W <b...@g...pl>

    On Monday, February 20, 2012 6:27:31 PM UTC, A. L. wrote:

    > Poza tym zadziwie mnei pakowanie watkow do kategorii "moda". Ciekawe
    > jak Kolega zrobi pod Windows, w Javie, program ktory bedzie robil
    > dlugie obliczenia, a uzytkownik bedzie chcial mniec wglad w stan tych
    > obliczen bez przerywania procesu obliczania. Rozumiem ze bedzie jedna
    > wielka petla ktora co milisekunde bedzie sprawdzala stan klawiatury i
    > co milisekunde wysylala na ekran?

    Nawet taki pozornie prosty problem jak "piszemy addin do Excela ktory musi stworzyc
    swoje wlasne okienko dialogowe, ktore umozliwia kopiowanie danych pomiedzy soba a
    arkuszem Excela" konczy sie na uzyciu watkow.

    RW

strony : 1 ... 11 . [ 12 ] . 13


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: