On Sun, 18 Jan 2015 12:21:35 +0100, "AK" <n...@n...com> wrote:
> Heh. Przeciez numpy jest szybsze od Matlaba.

Jakieś dane?

do góry

On Sun, 18 Jan 2015 12:20:08 +0100, "AK" <n...@n...com> wrote:
> PS: Po to jest wlasnie numpy aby nie dzialac na macierzach
niskopoziomowo.

Słusznie. A w czym napisane jest numpy?

do góry

On Sun, 18 Jan 2015 12:07:35 +0100, "AK" <n...@n...com> wrote:
> Niestety tablice w Fortranie to koszmar (nawet w tym nowym 90, nie
tylko 4).

Jest 2008. Wypadałoby wiedzieć.

Ale jeżeli dla ciebie tablice w Fortranie to za trudna koncepcja...

do góry

On Sun, 18 Jan 2015 12:07:35 +0100, "AK" <n...@n...com> wrote:
> PS1: Poza tym gdybys byl uczciwy to przyznalbys, ze pod spodem
numpy siedzi sobie
> "niewinnie" soft fortranowy wlasnie. LAPACK-i, czesc NAGa chyba o
ile pamietam.
> wiec jesli wolne i bledogenne to zglosc to tworcom Fortranowcom :)
a nie "nadawaj"

I właśnie dlatego wolę Fortran niż wynalazki w rodzaju Ratforu czy
Pythona.

do góry

Dnia 18.01.2015 slawek <f...@f...com> napisał/a:
> On Sun, 18 Jan 2015 12:20:08 +0100, "AK" <n...@n...com> wrote:
>> PS: Po to jest wlasnie numpy aby nie dzialac na macierzach
> niskopoziomowo.
>
> Słusznie. A w czym napisane jest numpy?
To binding do LAPACK, który jak pewnie wiesz napisany jest w Fortranie.

Podobnie ma się z benchmarkiem pidgits na shootout.alioth.debian.org.
http://benchmarksgame.alioth.debian.org/u32q/benchma
rk.php?test=pidigits&lang=all&id=1&data=u32q
Różnice pomiędzy z C, C++, Javą, PHP, Lua, Ada, Pascalem, Ruby zupełnie
się zatarły. Bo wyszystkie jak jeden korzystają z mocy biblioteki GMP.
Jedynie bodajże Go Lang wyłamuje się z tego schematu.

do góry

Użytkownik "grapeli23" <g...@g...com> napisał:

> Bo wyszystkie jak jeden korzystają z mocy biblioteki GMP.

Na Windowsach jest podobnie.
Numpy jest kompilowany z wykorzystaniem:
https://software.intel.com/en-us/intel-mkl/

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
http://www.avast.com

do góry

On Sunday, January 18, 2015 at 9:26:58 AM UTC+1, AK wrote:
> Użytkownik "M.M." napisał:
>
> > Hm..
> > Np. w poziom zawodowo/"zyciowy" dzisiejszego pokolenia polskich "wyksztalconych z
duzych miast".
> > Zwanych rowniez "pokoleniem smieciowym", OFEowo/frankofonskim.
> > W jezyku "tasm prawdy" zwanym: np. "wydymanym bydlem".
> > Moge, czy to juz (np. w/g mendiow polskich) "mowa nienawisci" ? ;)
>
> > Możesz, ale nie rozmawialiśmy o krasnoludkach :)
>
> To prawda. Tyle tylko ze to ja nie rozmawialem o nich, a tylko wylacznie o
technikaliach.
> To wlasnie Ty zaczales "o krasnoludkach" wiec z "wrodzonej uprzejmosci"
odpowiedzialem
> Ci/pociagnalem temat.
> Jeszcze czegos/cus Cie jeszcze gryzie :) ?
Och co za uprzejmość.

do góry

W dniu niedziela, 18 stycznia 2015 12:07:44 UTC+1 użytkownik AK napisał:

>
> > Ale prościej jest użyć Fortranu. Wtedy nie trzeba się ratować.
>
> Niestety tablice w Fortranie to koszmar (nawet w tym nowym 90, nie tylko 4).
> Tak sie sklada ze wydajnosciowo wcale bardzoi nie odbiegaja od tych z numpy.

Bo numnpy to nakładka na blas, fortranowską (z rzadka czasem c++) bibliotekę.

Ale, jak ktoś już wspomniał, pobaw się ręcznie indeksami i pojedynczymi
zmiennymi, czy to w matalbie, czy w numpy, wydajność staje się koszmarna.

Większość rzeczy da się napisać jako 'grube' operacje macierzowe,
wtedy problemu nie ma. Ale niestety, nie zawsze.



> PS1: Poza tym gdybys byl uczciwy to przyznalbys, ze pod spodem numpy siedzi sobie
> "niewinnie" soft fortranowy wlasnie. LAPACK-i, czesc NAGa chyba o ile pamietam.


Przecież wszyscy od początku o tym mówią. Matlab i numpy są szybkie,
póki używasz 'mnożenia macierzowego'. Chcesz poza to wyjść, wydajność
spada na łeb.

pzdr
bartekltg

do góry

W dniu niedziela, 18 stycznia 2015 14:42:09 UTC+1 użytkownik grapeli23 napisał:
> Dnia 18.01.2015 slawek <f...@f...com> napisał/a:
> > On Sun, 18 Jan 2015 12:20:08 +0100, "AK" <n...@n...com> wrote:
> >> PS: Po to jest wlasnie numpy aby nie dzialac na macierzach
> > niskopoziomowo.
> >
> > Słusznie. A w czym napisane jest numpy?
> To binding do LAPACK, który jak pewnie wiesz napisany jest w Fortranie.
>
> Podobnie ma się z benchmarkiem pidgits na shootout.alioth.debian.org.
> http://benchmarksgame.alioth.debian.org/u32q/benchma
rk.php?test=pidigits&lang=all&id=1&data=u32q
> Różnice pomiędzy z C, C++, Javą, PHP, Lua, Ada, Pascalem, Ruby zupełnie
> się zatarły. Bo wyszystkie jak jeden korzystają z mocy biblioteki GMP.
> Jedynie bodajże Go Lang wyłamuje się z tego schematu.

Zatarły się, pod warunkiem, że robisz standardowe rzeczy.
Chcesz zrobić coś więcej niż bliblioteka, leższ wydajnośćiowo.

Znów sprawa rozbija się o problem 'dobierz język do potrzeb'.
Bardzo często używam matlaba, bo całkowicie wystarcza.
Ale czasem nie wystarcza, i przydatny jest c++ (z zestawem
bibliotek numerycznych oczywiście, nikt nie pisze od początku).

Ale też dlatego imho pewną nieuczciwością jest twierdzenie,
że ptthon/matlab etc jest równie szybki jak c++/(fortran dla
cierpliwych). Jest tak samo szybki jeśli traktujemy go jako
odpalacz funkcji bibliotecznych, ale jako pełny język - niestety nie.

Ale to się zmienia. Jakieś 3 lata temu zaczęła mocno rozwijać
się Julia, tam nieszczęsne pętle po skalarach chodzą praktycznie
jak w kompilowanym (znajomy nie wierzył, robił test, c++ kontra
julia symulując błądzenie losowe z własnym generatorem liczb,
wyniki były obiecujące).
Więc też nie jest tak, że się zupełnie nie da.

pzdr
bartekltg

do góry

On Friday, January 16, 2015 at 7:23:02 PM UTC+1, slawek wrote:
> >> 1. Za wolno działa (nawet 1000x wolniej niż program napisany w C).
> >
> > To jest język interpretowany i będzie wolny. Trzeba z tym żyć.
>
> Zgoda - gdy zależy nam na prędkości omijajmy Python. A kiedy nie zależy nam
> na prędkości?

To używamy pythona :)

> >> 2. Bałagan z wersjami. Wersje 3.* mają problemy z Cythonem.
> >
> > Wersja 3 jest rozwijana na gałęzi cythona, jakie masz problemy?
>
> Zaraz, zaraz... cpythona czy cythona? Bo, AFAIR, to zupełnie dwie różne
> rzeczy są: "standardowy" interpreter Pythona w C vs. rozszerzenie Pythona o
> niektóre elementy "prawie C".

Ok, mój błąd, myślałem, że chodzi Ci o cpythona.

> >> 4. Koszmarnie źle zrobione wątki.
> >
> > Co z nimi jest nie tak?
>
> Standardowo wątki jadą na jednym rdzeniu. Czyli można pisać programy
> wielowątkowe... dla sportu. Bo na pewno nie dla zwiększenia wydajności
> (hallo, ilu z was ma 1 rdzeń CPU? teraz nawet komórki mają po 4).

Zgoda, ale znowu: python nie był do tego projektowany i szczerze mówiąc
wątpię, żeby dało się go elegancko "urównoleglić" bez całkowitego
przeprojektowania i przepisania runtime. To już lepiej nowy język
o zbliżonej składni zrobić. :)

> >> 5. Brak tablic.
> >
> > A [1,2,3,4] to czym jest? #define tablica
>
> Ok, uzupełnię - tablic równie wydajnych jak w Fortranie. Bo to co jest to
> symulacja tablic na listach.

W takim razie ten punkt to jedynie wariant pierwszego Twojego zastrzeżenia. :)

w.

do góry