On 11/07/2014 21:23, slawek wrote:
>
>
> Użytkownik "Roman W" napisał w wiadomości grup
> dyskusyjnych:a...@n...plus.
net...
>
>> Ps. Moja firma używa Pythona. Znajomy hedge fund (nie ten o którym
>> pisalem w poprzednim poście) też.
>
> Wątpię jednak, czy Python to dobry język do programowania hamulców,
> poduszek powietrznych i takich tam. Symulację galaktyki na
> superkomputerze też raczej pisałbym w czymś szybszym.

Super, ale z tego nie wynika ze "jeżeli ktoś chce robić coś "poważnego"
w Pythonie, to powinien od razu dokupić sobie 999 komputerów do każdego
jednego jaki ma... oraz uświadomić sobie że będzie zużywał 1000 więcej
energii elektrycznej."

RW

do góry

On 11/07/2014 21:05, slawek wrote:
>
>
> Użytkownik "Roman W" napisał w wiadomości grup
> dyskusyjnych:a...@n...plus
.net...
>
>> Znam ludzi którzy używają. Do high-frequency trading.
>
> Tzn. czego używają:
>
> a) Pythona ?

Tak

> b) Cythona ?

Tak

> c) Iron Pythona ?

Nie wiem. Napisali tez cos swojego wlasnego w C co ma skladnie jak
Python ale kompiluje sie do kodu binarnego (jakies rozszerzenie Cythona?
nie wiem) poprzez LLVM.

>
> Interesuje mnie pytanie "czy Cython jest żywy?" Dlaczego? Cython jest
> dla Pythona czymś podobnym jak Ratfor był dla Fortranu. Cython wymaga
> Pythona 2 i jednocześnie kompilatora C. Co do kompilatora C jest
> wybredny, ostatnie MSVC jakie trawi to wersja z 2008 i to po
> patch'owaniu tego i owego. Trochę głupio tkwić w Pythonie 2.xx gdy jest
> już Python 3.xx.

Czemu?

RW

do góry

Użytkownik "Roman W" napisał w wiadomości grup
dyskusyjnych:DJCdnZCJobdwy13OnZ2dnUVZ8tIAAAAA@bright
view.co.uk...
>Czemu?

Tak samo jak trochę głupio pisać w C++ bez lambd.

do góry

Użytkownik "Roman W" napisał w wiadomości grup
dyskusyjnych:DJCdnZGJobcBy13OnZ2dnUVZ8tKdnZ2d@bright
view.co.uk...

>Super, ale z tego nie wynika ze "jeżeli ktoś chce robić coś "poważnego" w
>Pythonie, to powinien od razu dokupić sobie 999 komputerów do każdego
>jednego jaki ma... oraz uświadomić sobie że będzie zużywał 1000 więcej
>energii elektrycznej."

Zajrzyj sobie do http://benchmarksgame.alioth.debian.org/

Z tego co tam jest wynika iż (przy obliczaniu normy spektralnej) Python
potrzebuje ponad 200 sekund na to co w C++ trwa 2 sekundy. Inne testy dają
podobne rezultaty: Python działa nawet do 1000x wolniej niż C.

Nie wierzyłbym, ale sam kiedyś napisałem jakiś program w C i w Pythonie -
program w Pythonie był 1000 razy wolniejszy niż w C.

Nie twierdzę, że Python jest nieprzydatny. Twierdzę jedynie że programy w
Pythonie zwykle działają dużo wolniej niż ich odpowiedniki napisane w innych
językach programowania.

Więc do "poważnych" (real time, mission critical, massive parallel, number
crunchning, FPP video game) zastosowań może być mniej przydatne. Chyba że
właśnie kupi się te 999 komputerów więcej. Wtedy wszystko będzie spoko.

do góry

W dniu sobota, 12 lipca 2014 13:07:36 UTC+2 użytkownik slawek napisał:

> Więc do "poważnych" (real time, mission critical, massive parallel, number
> crunchning, FPP video game) zastosowań może być mniej przydatne. Chyba że
> właśnie kupi się te 999 komputerów więcej. Wtedy wszystko będzie spoko.

Raczej nie, bo niewiele problemów skaluje się tak ładnie. Do tego dochodzi koszt
komunikacji.

Ratunkiem byłby komputer 1000x szybszy, ale też nie - problemem Pythona wcale nie
jest to, że jest powolny tylko to, że jest dynamiczny. Przy programie mieszczącym się
na jednym ekranie wydaje się, że Python pomaga programiście - ale przy dłuższych
programach wydaje się, że przeszkadza. Z tego powodu nie widzę go w tematach "mission
critical" nawet gdyby ktoś wymyślił 1000x szybsze komputery.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Sat, 12 Jul 2014 12:47:11 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>W dniu sobota, 12 lipca 2014 13:07:36 UTC+2 użytkownik slawek napisał:
>
>> Więc do "poważnych" (real time, mission critical, massive parallel, number
>> crunchning, FPP video game) zastosowań może być mniej przydatne. Chyba że
>> właśnie kupi się te 999 komputerów więcej. Wtedy wszystko będzie spoko.
>
>Raczej nie, bo niewiele problemów skaluje się tak ładnie. Do tego dochodzi koszt
komunikacji.
>
>Ratunkiem byłby komputer 1000x szybszy, ale też nie - problemem Pythona wcale nie
jest to, że jest powolny tylko to, że jest dynamiczny. Przy programie mieszczącym się
na jednym ekranie wydaje się, że Python pomaga programiście - ale przy dłuższych
programach wydaje się, że przeszkadza. Z tego powodu nie widzę go w tematach "mission
critical" nawet gdyby ktoś wymyślił 1000x szybsze komputery.

Nie wiem o co chodzi z ta "dynamicznoscia" i "pomaganiu programiscie"

Python nigdy nie byl projektowany jako jezyk do zastosowan "mission
critical". Jezeli ktos go do tego celu uzywa, robi to na wlasna
odpowiedzialnosc. I nic to nei ma wspolnego z szybkoscia...

A.l.

do góry

Użytkownik "Maciej Sobczak" napisał w wiadomości grup
dyskusyjnych:3ff803de-3aa3-49f9-8383-2ab9181d0415@go
oglegroups.com...

>Raczej nie, bo niewiele problemów skaluje się tak ładnie. Do tego dochodzi
>koszt komunikacji.

Jeżeli nie ma być real-time, czyli będzie off-line, to po prostu każde
kolejne coś uruchamia się na kolejnym komputerze. I nie przeszkadza czekania
nawet i 2 lata - bo 1000 komputerów to mniej więcej 1 komputer dziennie
przez trzy lata.

> [...} problemem Pythona wcale nie jest to, że jest powolny tylko to, że
> jest dynamiczny.

To akurat - według mnie - zaleta Pythona. Tzn. gdyby nie był dynamiczny, to
byłby nudny. A tak można w nim robić dziwne dziwne rzeczy.

do góry

Użytkownik "A.L." napisał w wiadomości grup
dyskusyjnych:kl63s9tnua9fje89cbhlihh9jph0matb4v@4ax.
com...

>Python nigdy nie byl projektowany jako jezyk do zastosowan "mission
>critical". Jezeli ktos go do tego celu uzywa, robi to na wlasna
>odpowiedzialnosc. I nic to nei ma wspolnego z szybkoscia...

Pascal nigdy nie był - w założeniach - pomyślany do czegokolwiek innego jak
nauka programowania. Basic miał być językiem dla początkujących - zanim będą
programować w Fortranie lub Algolu. Fortran, gdy go tworzono, nigdy nie miał
być językiem do sterowania rakietami kosmicznymi. Itp. itd.

W przypadku języków programowania jest coś takiego jak przyzwyczajenie. Gdy
ktoś nauczył się języka X, to nie bardzo chce mu się używać języka Y. Masa
ludzi uczyła się swego czasu Fortranu - i po prostu używają do dziś
Fortranu, nie chcieli uczyć się Pascala czy C. Masa ludzi uczyła się
Pascala. I z maniackim uporem tkwią przy Pascalu/Delphi. Masa ludzi używała
C - i ci, owszem, czasami nawet przeszli na C++/C# - ale nijak nie daliby
się namówić na nauczenie się np. Haskela. "No bo po co?" - taki mają
argument. Podobnie z Pythonem: są ci którzy są fanami Pythona - i ci którzy
będą omijać, bo z Pythonem zetknęli się znając już inny język programowania.

Pod pewnymi względami Python mi się podoba. Czuję w nim pewien taki luz (jak
mawiał Stoch). A pod pewnymi względami mi się bardzo bardzo nie podoba. A z
jeszcze innych względów... no cóż, widzę do czego nie będę mógł go użyć, bo
zwyczajnie nie będę żyć dostatecznie długo, abym doczekał się wyników (1000
razy wolniej to zamiast 3 lat obliczeń jest 3000 lat obliczeń).

Python jest (?) idealny do dydaktyki. Tylko pech w tym, że 90% ludzi, którzy
nauczą się Pythona, nigdy nie sięgnie po inny język... nawet gdy staną przed
problemami "mission critical".

do góry

On 13/07/2014 19:11, slawek wrote:
> Użytkownik "Maciej Sobczak" napisał w wiadomości grup
>
> Jeżeli nie ma być real-time, czyli będzie off-line, to po prostu każde
> kolejne coś uruchamia się na kolejnym komputerze. I nie przeszkadza
> czekania nawet i 2 lata - bo 1000 komputerów to mniej więcej 1 komputer
> dziennie przez trzy lata.

No ale chyba całkiem sporo serwisów webowych, było nie było online,
działa na Pythonie i innych językach mających podobne problemy
wydajnościowe (Ruby, PHP, JavaScript, erlang). Rachunek ekonomiczny
wygląda tak, że póki masz stosunkowo niewielu użytkowników, to to
wystarczy, a time to market i dużo ficzerów jest ważniejsze niż
wydajność, potem jak masz więcej użytkowników to dokupujesz sobie
dodatkowe komputery w chmurze i faktycznie możesz mieć ich tysiąc za
stosunkowo nieduże pieniądze (bo nie są 100% obciążone przez 100%
czasu), a dopiero jak jesteś gigantycznym molochem to zaczyna się
opłacać kombinacja żeby przepisać część infrastruktury na C++ albo
pakować kasę w pisanie JIT-ów i silnie zoptymalizowanych maszyn
wirtualnych do wykonywania twojego starego (i nowego) kodu. Tak jak
Facebook zrobił z PHP.

Z kolei w enterprise jest sporo zastosowań, które są ważne i muszą się
wykonać w określonym czasie, ale taki Python czy co tam na współczesnej
maszynie po prostu wystarczą. Pomyśl zresztą, że taka współczesna
maszyna jest np. 1000 razy szybsza niż big iron kiedyś, a ten big iron
przecież realizował podobne zadania. A np. firmy dzisiaj nie mają 1000
razy więcej klientów, 1000 razy więcej pracowników ani nie produkują
1000 razy więcej śrubokrętów.

do góry

W dniu niedziela, 13 lipca 2014 21:05:40 UTC+2 użytkownik Andrzej Jarzabek napisał:

> A np. firmy dzisiaj nie majďż˝ 1000
> razy wi�cej klient�w,

Facebook, Twitter, Google, Amazon - zdaje się, że mają.

> 1000 razy wi�cej pracownik�w

Foxconn?

> ani nie produkujďż˝
> 1000 razy wi�cej �rubokr�t�w.

Śrubokrętów faktycznie nie produkują, bo teraz się produkuje smartfony - i to właśnie
1000 razy więcej, niż czegokolwiek kiedykolwiek.

Natomiast pomijając te skrajności mamy inny problem - firmy, nawet te
średnio-mniejsze, chcą *wiedzieć* 1000x więcej, niż kiedyś. 30 lat temu żadna firma
nie śledziła ruchu gałek ocznych swoich klientów, a teraz wszyscy chcą to robić. I
dlatego firma, która może w ciągu 30 lat nie powiększyła swojego zatrudnienia i nie
produkuje 1000x więcej śrubokrętów, potrzebuje (?) dzisiaj 1000x więcej mocy
obliczeniowej. Tzn. tylko mysli, że potrzebuje, ale w sumie z naszego (IT) punktu
widzenia nie ma znaczenia, czy faktycznie potrzebuje, czy tylko myśli - tak czy
inaczej trzeba im to przetworzyć.

I teraz powstaje pytanie, czy należy to robić w Pythonie.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry