Tomasz Zielonka <tomasz.zielo@gmail.comwrites:
Przypuszczam, że na wielu obecnych programach, a szczególnie tych
w językach skryptowych i na maszynach wirtualnych, predykcja skoków
kuleje. Może więc HT nie jest takie złe.


Perl nie ma praktycznie żadnych działających wątków. Python ma global
interpreter lock (wątki nie wykonują równolegle kodu w Pythonie, tylko
takie rzeczy jak blokujące I/O). Ruby ma wątki zaimplementowane i
schedulowane ręcznie.

co gorsza, php nie potrafi pod iis pracowac w srodowisku wielowatkowym. udaje
wielowatkowosc przez trywialne odpalanie procesow.


Czegoś tu nie rozumiem. Python przecież posiada tzw. global interpreter
lock który nie pozwala na użycie więcej wielu wątków *naraz*. Czyli
aplikacje wielowątkowe (np. Webware) nie wykorzystują pełnej mocy maszyn
wieloprocesorowych. Tego problemu nie ma w przypadku aplikacji
korzystających z procesów. M.in. dlatego SkunkWeb działa na forks a nie
threads (zobacz: http://skunkweb.sourceforge.net/FAQ.html) Jeśli więc IIS
korzysta z procesów i maszyna jest wieloprocesorowa to taki PHP powinien
pełniej wykorzystywać moc wielu procesorów serwera. Dobrze rozumuję?

bo jesli zastosuje sie standardowe pliki (powiedzmy pseudomoduly)
to taka wielka skomplikowana biblioteka za kazdym razem sie laduje
i kompiluje. jak to wplywa na wydajnosc, jesli dynamiczna strona www
musi przy kazdym odwolaniu odpalic caly ten kierat, mowic chyba nie trzeba:)


Aby jakoś się ratować, trzeba koniecznie użyć czegoś w stylu mmcache, który
(jeśli wierzyć tekstowi na stronie
http://turck-mmcache.sourceforge.net/index_old.html#about) prawie zupełnie
redukuje etap ciągłej kompilacji.

JZ wrote:
Czegoś tu nie rozumiem. Python przecież posiada tzw. global interpreter
lock który nie pozwala na użycie więcej wielu wątków *naraz*. Czyli
aplikacje wielowątkowe (np. Webware) nie wykorzystują pełnej mocy maszyn
wieloprocesorowych. Tego problemu nie ma w przypadku aplikacji
korzystających z procesów. M.in. dlatego SkunkWeb działa na forks a nie
threads (zobacz: http://skunkweb.sourceforge.net/FAQ.html) Jeśli więc IIS
korzysta z procesów i maszyna jest wieloprocesorowa to taki PHP powinien
pełniej wykorzystywać moc wielu procesorów serwera. Dobrze rozumuję?


teoretycznie tak. ale w praktyce narzut na procesy jest na tyle wysoki,
ze efekt istnienia drugiego procka staje sie mocno dyskusyjny.
poza tym w praktyce na maszynach wieloprocesorowych, serwer aplikacyjny
i tak jest jednym z rownolegle dzialajacych procesow, wiec pomimo
czesciowego niewykorzystania mocy, zazwyczaj dziala to nieco szybciej.

Aby jakoś się ratować, trzeba koniecznie użyć czegoś w stylu mmcache, który


jako ostatnia deska ratunku mozna skorzystac z takiego rozwiazania :)
szkoda ze tworcy nie przewidzieli natywnego mechanizmu ktory robilby to samo.

znik.

Adam Przybyla wrote:
[...]
|     ... przyznam, ze tez nie rozumiem, taki sciagacz informacji z www
| dziala mi calkiem calkiem, kilka razy szybciej na watkach. Z powazaniem

Mysle, ze to przez roznego rodzaju przestoje zwiazane z oczekiwaniem na
odpowiedz od serwera. W programie jednowatkowym musisz to wszystko
przeczekac zanim cos zrobisz. W programie wielowatkowym, w ktorym
faktycznie watki nie sa wykonywane rownoczesnie istnieje szansa, ze
watek przespi ten moment postoju.


Taka sytuacja w samym CPython-ie się nie zdarzy, gdyż wątki Python-a są
prawdziwymi wątkami systemu operacyjnego, a jedynie są wzajemnie
blokowane przez trzymanie Global Interpreter Lock. Przed każdą operacją
wejścia-wyjścia GIL jest zwalniany (a po niej znowu pobierany), więc
automatycznie inne wątki Python-a mogą się wtedy wykonać. Dzięki temu
stosowanie wątków w programach sieciowych jest efektywne.

GM

Gradda Makker <nob@invalid.invalidwrote:
[...]
| blokowane przez trzymanie Global Interpreter Lock. Przed każdą operacją
| wejścia-wyjścia GIL jest zwalniany (a po niej znowu pobierany), więc
| automatycznie inne wątki Python-a mogą się wtedy wykonać. Dzięki temu
| stosowanie wątków w programach sieciowych jest efektywne.

   ... hmm, chyba nie tylko operacje wejscia i wyjscia:


[...]
Tak, po prostu wspomniałem tylko o operacjach wejścia-wyjścia bo była
mowa o ściąganiu stron z sieci. W samych kodach Python-a jak w
dodatkowych modułach GIL zwalniany jest wszędzie tam, gdzie jest to
możliwe i sensowne.

Na przykład GIL zwalniany jest przy kompresji i dekompresji za pomocą
zlib-a i bz2. Patrz:
<http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/...
<http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/...

[trzeba szukać Py_BEGIN_ALLOW_THREADS, Py_END_ALLOW_THREADS]

Czyli można napisać w Python-ie wielowątkowy program archiwizujący
(zip-y, bz2) i będzie on optymalnie wykorzystywał wieloprocesorował maszynę.

Właśnie dlatego zamartwianie się z o to góry jest przesadą.

GM

Taka sytuacja w samym CPython-ie się nie zdarzy, gdyż wątki Python-a są
prawdziwymi wątkami systemu operacyjnego, a jedynie są wzajemnie
blokowane przez trzymanie Global Interpreter Lock. Przed każdą operacją
wejścia-wyjścia GIL jest zwalniany (a po niej znowu pobierany), więc
automatycznie inne wątki Python-a mogą się wtedy wykonać. Dzięki temu
stosowanie wątków w programach sieciowych jest efektywne.


        ... hmm, chyba nie tylko operacje wejscia i wyjscia:
def test():
        import time
        o= int(time.time())
        map(lambda x: time.sleep(1),range(20))
        print "Normalny tryb wykonania,   czas %s" % (int(time.time())-o)
        o= int(time.time())
        comap(lambda x: time.sleep(1),range(20))
        print "Rownolegly tryb wykonania, czas %s" % (int(time.time())-o)

if __name__ == '__main__':
        test()
gormenghast:/home/adampython
Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
[GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

| import fap
| fap.test()


Normalny tryb wykonania,   czas 20
Rownolegly tryb wykonania, czas 1



To fragment tego modulu jaki tu posylalem. Nie mam tu niestety zadnej
maszynki dwuprocesorowej pod reka do testow:( Z powazaniem
                                                                Adam Przybyla