W dniu czwartek, 15 września 2016 11:24:53 UTC+2 użytkownik slawek napisał:
> Ogólnie: pisanie w Fortranie to jak powożenie bryczką - jest to coś
> czego można spróbować, ale na codzień praktyczne nie jest.

No paczpan, a ja słyszałem, że przy mieleniu dużej ilości liczb, np. przy
wyliczeniach kartograficznych, danych pogodowych itp. fortran wciąż bije konkurencję
na głowę prędkością, stąd wśród specjalistów od geografii jest prawie obowiązkowy.

joahim

do góry

On 2016-09-15 22:28, joahim wrote:
>> Ogólnie: pisanie w Fortranie to jak powożenie bryczką - jest to coś
>> czego można spróbować, ale na codzień praktyczne nie jest.
> No paczpan, a ja słyszałem, że przy mieleniu dużej ilości liczb,
> np. przy wyliczeniach kartograficznych, danych pogodowych itp.
> fortran wciąż bije konkurencję na głowę prędkością, stąd wśród specjalistów od
geografii jest prawie obowiązkowy.

Kiedyś faktycznie był szybki, ale ostatnio widzę że istnieje bardziej na
zasadzie inercji: jest bo jest w nim jakiś soft numeryczny i jakoś tak
wychodzi. Czy *obecnie* fortran jest szybszy niż identyczny algorytm w C
i co najwazniejsze: niby dlaczego?

do góry

On Thursday, September 15, 2016 at 5:04:18 PM UTC-4, Sebastian Biały wrote:
> On 2016-09-15 22:28, joahim wrote:
> >> Ogólnie: pisanie w Fortranie to jak powożenie bryczką - jest to coś
> >> czego można spróbować, ale na codzień praktyczne nie jest.
> > No paczpan, a ja słyszałem, że przy mieleniu dużej ilości liczb,
> > np. przy wyliczeniach kartograficznych, danych pogodowych itp.
> > fortran wciąż bije konkurencję na głowę prędkością, stąd wśród specjalistów od
geografii jest prawie obowiązkowy.
>
> Kiedyś faktycznie był szybki, ale ostatnio widzę że istnieje bardziej na
> zasadzie inercji: jest bo jest w nim jakiś soft numeryczny i jakoś tak
> wychodzi. Czy *obecnie* fortran jest szybszy niż identyczny algorytm w C
> i co najwazniejsze: niby dlaczego?

Ciagle w niektorych dziedzinach (fizyka nuklearna, symulacja zjawisk pogodowych,
astrofizyka, hydroakustyka) i na niektorych superkompuerach jest ciagle najszybszy.
Nowoczesny Fortran ma dodane pelne OOP - ale tam gdzie jest uzywany (szybkie
przetwarzanie numeryczne) nikt o to nie dba - ciagle sa na poziomie Fortran 77 (ktory
z definicji poswiecal wiele dobrych cech innych jezykow dla jednego celu - szybkosc).
Najwieksza sila Fortranu (i to powoduje ze ciagle sie dobrze trzyma) jest masa dobrze
przetestowanych specjalizowanych bibliotek numerycznych ktorych nikt nie ma zamairu
prznosic na inne jezyki (bo trzeba by bylo je testowac od nowa).

do góry

On Thu, 15 Sep 2016 13:28:56 -0700 (PDT), joahim <w...@g...com>
wrote:
> No paczpan, a ja słyszałem, że przy mieleniu dużej ilo=
> ści liczb, np. przy wyliczeniach kartograficznych, danych
pogodowych i=
> tp. fortran wciąż bije konkurencję na głowę pr?=
> ?dkością, stąd wśród specjalistów od geogra=
> fii jest prawie obowiązkowy.

Też takie rzeczy słyszałem. Ale to było 30 lat temu. "Trochę" się od
tamtego czasu zmieniło.

do góry

On Thu, 15 Sep 2016 14:55:16 -0700 (PDT), Adam M
<a...@m...com> wrote:
> Ciagle w niektorych dziedzinach (fizyka nuklearna, symulacja
zjawisk pogodo=
> wych, astrofizyka, hydroakustyka) i na niektorych superkompuerach
jest ciag=

Tylko przez bezwład. Nowe pokolenie ewoluuje w kierunku Pythona i
C++. A że C++ jest szybsze niż Fortran stwierdzono już kilkanaście
lat temu.

do góry

W dniu 15.09.2016 o 23:04, Sebastian Biały pisze:
> Kiedyś faktycznie był szybki, ale ostatnio widzę że istnieje bardziej na
> zasadzie inercji: jest bo jest w nim jakiś soft numeryczny i jakoś tak
> wychodzi. Czy *obecnie* fortran jest szybszy niż identyczny algorytm w C
> i co najwazniejsze: niby dlaczego?

Obecne C/C++ jest szybkie do kresu możliwości.Sprawdzałem w VC 2015 w
Release:
Wyliczałem Hornerem :
obliczanie przyblizenia Czebyszewa exp(x) wielomianem
stopnia 7; wielomian obliczany schematem Hornera
oraz szybsz? metod?

double horner(double x)
{
double result = 0.0002047;
result = result*x + 0.001439274;
result = result*x + 0.008328596;
result = result*x + 0.041635012;
result = result*x + 0.166667986;
result = result*x + 0.500006347;
result = result*x + 0.999999901;
result = result*x + 0.999999801;
return result;
}

double hornerfast(double x)
{
return ((((((0.0002047*x + 0.001439274)*x + 0.008328596)*x
+ 0.041635012)*x + 0.166667986)*x + 0.500006347)*x + 0.999999901)*x +
0.999999801;
}

oraz dla porównania metodą szybsza od Hornera:
double fast(double x)
{
double y = x*0.297178123 + 0.155642921;
double z = y*y;
return (z + 0.732273642600117)*(y*((z + 2.4368618551)*(z + y -
1.0184605924)
+ 5.2036422682) + 1.5688833150) - 0.5565483727;
}


Przed laty pisałem coś takiego w Pascalu
i horner na Duronie 900 miał 190 taktów, hornerfast na Duronie 900 miał
72 takty a fast
na Duronie 900 miał 105 taktów, a 160 gdy "linie nie były polaczone ze sobą"
Czyli zależność procedury od tego czy ją się napisze w jednej linii a
poza tym nowa metoda fast gorsza od szybszego Hornera mimo że mniej mnożeń.
Spowodowane to było małą optymalizacją.
W C++ zupełnie co innego, pętla 20000000:
horner 68.82 ms
hornerfast 68.9 ms
fast 68.19 ms
Wszystkie tak samo, niestety szybsza metoda niż Hornera tu nie działała
chyba stopień 7 to za mało, trzeba by z 12.
Uwaga: Gdy wykonywałem pomiar czasu za pomocą std::chrono biorąc większą
lub mniejsza pętlę było źle, bo im większa pętla tym mniej na jedną
funkcję. Więc wziąłem nie największą pętlę i jeszcze ją wykonałem 100
razy biorą NAJMNIEJSZY rezultat a nie średni. Bywało źle, bo za
pierwszym razem wykonywało się zwykle najwolniej, potem z 5 razy
szybciej ale jeszcze nie tak, potem już tak samo.

WNIOSEK: C++ jest tak szybkie, że nie trzeba się już przejmować postacią
procedury.
ALE z drugiej strony stopień 7 wielomianu to za mało aby zadziałała
skomplikowana metoda, która miała przyśpieszyć Hornera.

do góry

W dniu 16.09.2016 o 01:24, slawek pisze:
> Tylko przez bezwład. Nowe pokolenie ewoluuje w kierunku Pythona i C++. A
> że C++ jest szybsze niż Fortran stwierdzono już kilkanaście lat temu.

Co ludzie z tym Pythonem? Wolny jak cholera.

do góry

W dniu piątek, 16 września 2016 01:24:49 UTC+2 użytkownik slawek napisał:
> On Thu, 15 Sep 2016 14:55:16 -0700 (PDT), Adam M
> <amorawski@...> wrote:
> > Ciagle w niektorych dziedzinach (fizyka nuklearna, symulacja
> zjawisk pogodo=
> > wych, astrofizyka, hydroakustyka) i na niektorych superkompuerach
> jest ciag=
>
> Tylko przez bezwład. Nowe pokolenie ewoluuje w kierunku Pythona i
> C++. A że C++ jest szybsze niż Fortran stwierdzono już kilkanaście
> lat temu.

Powiedz, próbowałeś kiedyś robić mapę w Pythonie?
Matplotlib-basemap jest fajne, naprawdę.
W trakcie liczenia jednej, prostej mapy na średnio-starym sprzęcie możesz pójść
wyprowadzić psa i sprzątnąć pokój, serio!

joahim

do góry

W dniu 16.09.2016 o 13:58, joahim pisze:
> Powiedz, próbowałeś kiedyś robić mapę w Pythonie?
> Matplotlib-basemap jest fajne, naprawdę.
> W trakcie liczenia jednej, prostej mapy na średnio-starym sprzęcie możesz pójść
wyprowadzić psa i sprzątnąć pokój, serio!

Jestem trochę nie w temacie. Co rozumiesz przez "mapę"?

do góry

W dniu piątek, 16 września 2016 14:05:13 UTC+2 użytkownik Borneq napisał:
> W dniu 16.09.2016 o 13:58, joahim pisze:
> > Powiedz, próbowałeś kiedyś robić mapę w Pythonie?
> > Matplotlib-basemap jest fajne, naprawdę.
> > W trakcie liczenia jednej, prostej mapy na średnio-starym sprzęcie możesz pójść
wyprowadzić psa i sprzątnąć pokój, serio!
>
> Jestem trochę nie w temacie. Co rozumiesz przez "mapę"?

Taki obraz kawałka Ziemi w 2D.

joahim

do góry