W dniu 2011-02-02 22:40, Fil pisze:
>> To tak, z tego co mi widomo, jak trochę się bawiłem w te sprawy, to:
>>
>> * dla C/C++ najlepszym (b. dobrze optymalizującym) kompilatorem był
>> ten produkcji Intela;
>> * z części obliczeniowej zrób bibliotekę dll;
>> * tej biblioteki możesz użyć w czymkolwiek, np. w Delphi.
>
> Tak właśnie chcę zrobić, ale nie jest to takie proste (wbrew pozorom). I
> nie chodzi mi o tworzenie bibliotek i eksportowanie funkcji, klas i
> takie tam... (to są banały),
Banały?
Jak uda Ci się wyeksportować klasę z DLLa napisanego w VC++ i utworzyć
obiekt z tej klasy w C+++ Builder to stawiam co tam chcesz.
Albo zrobiłeś litrówkę, albo nie wiesz o czym piszesz.
Uda Ci się to zrobić bez problemu i będzie ślicznie działać, jak
wyeksportujesz interfejsy zgodne z COM.

> tylko muszę się zastanowić nad tym jak
> poukładać wszystko do kupy od strony filozoficznej :). Mam sporo
> komponentów powiązanych ze sobą zależnościami - całość stanowi dość
> spory projekt.
A więc wszystko powinno być napisane jak biblioteka COM.
Jak np. DirectX. Albo ADO.

> Kompilatora Intela niestety nie mam. Pirat nie wchodzi w grę :). Free
> for comercial nie widziałem na stronie Intela. Może w przyszłości - jak
> zrobię te DLLki, to kupię kompilator i skompiluję je ponownie. Na razie
> musi wystarczyć Visual.

--
wloochacz

do góry

W dniu 2011-02-02 21:50, Fil pisze:
> jednocześnie używając ulubionych narzędzi (Builder do GUI z DevExpress i
> TMS components
Tak na marginesie - po co żenić bardzo dobry DevExpress z badziewnym TMSem?

--
wloochacz

do góry

On 3 Lut, 09:54, wloochacz <w...@n...gmail.spameromnie.com>
wrote:
> W dniu 2011-02-02 22:40, Fil pisze:>> To tak, z tego co mi widomo, jak troch si
bawi em w te sprawy, to:
>
> >> * dla C/C++ najlepszym (b. dobrze optymalizuj cym) kompilatorem by
> >> ten produkcji Intela;
> >> * z cz ci obliczeniowej zr b bibliotek dll;
> >> * tej biblioteki mo esz u y w czymkolwiek, np. w Delphi.
>
> > Tak w a nie chc zrobi , ale nie jest to takie proste (wbrew pozorom). I
> > nie chodzi mi o tworzenie bibliotek i eksportowanie funkcji, klas i
> > takie tam... (to s bana y),
>
> Bana y?
> Jak uda Ci si wyeksportowa klas z DLLa napisanego w VC++ i utworzy
> obiekt z tej klasy w C+++ Builder to stawiam co tam chcesz.
A czemu nie zwykly dll ktorego istnienia kompilator nawet nie
musi byc swiadomy podczas kompilacji?
Pozdrawiam

do góry

On 2 Lut, 17:47, Fil <f...@p...onet.pl> wrote:
> Witam!
>
> Są dwie procedury:
> CPP:
> void MulTab(int N, int Q, int M, double** A, double** B, double** C)
> {
>   for (int i = 0; i < N; ++i)
>     for (int j = 0; j < M; ++j) {
>       C[i][j] = 0;
>       for (int k = 0; k < Q; ++k) C[i][j] += A[i][k] * B[k][j];
>     }
>   }
>

Troche na boku dyskusji o wyzszosci siąt bozego narodzenia.
Zle to robisz;) Przynajmniej zamien petle meijscami, lepsza
kolejnosc to ikj. Przy takich zadaniach RAM jest wolny,
wiec trzeba pomagać danym trzymac cie w cache.

Odrwocenie petli pomaga. Jeszcze lepiej dziala mnozenie blokami.


test 1: n=384 najlepszy z 10 prob zwykly piorytet
test 2 n=960 najlepszy z 3 prob, real time.

void dgemm_ijk(double *A, double *B, double *C, int N)
{
int i,j,k;
for (i = 0; i < N; i++)
for (j = 0; j < N; j++)
for (k = 0; k < N; k++)
C[i*N+j] += A[i*N+k]*B[k*N+j];
}


1) 3.738s
2) ad mortem defacatum (nie bral udzialu w drugim tescie)

Odwrocmy kolejnosc. Obie macierze wejsciowe czytane sa
w prawidlowej kolejnosci.

void dgemm_ikj(double *A, double *B, double *C, int N)
{
int i,j,k;
for (i = 0; i < N; i++)
for (k = 0; k < N; k++)
for (j = 0; j < N; j++)
C[i*N+j] += A[i*N+k]*B[k*N+j];
}

1)1.011
2) 10.299 (a jest 3 razy szybszy niz wersja trywialna!)

Blkokowo, pewna podmacierz miesci sie w cache, to ja tam
zostawmy i wykorzystajmy ile sie da.

template <class T,int SM> void dgemm_bikj(T *A, T *B, T *C, int N)
{
int i,j,k,ii,kk,jj;
for (i = 0; i < N; i+=SM)
for (k = 0; k < N; k+=SM)
for (j = 0; j < N; j+=SM)
for (ii = i; ii < i+SM; ii++)
for (kk = k; kk < k+SM; kk++)
for (jj = j; jj < j+SM; jj++)
C[ii*N+jj] += A[ii*N+kk]*B[kk*N+jj];
}

SM=30

1) 0.174
2) 2.639

Kompilator nie wpadl na wszytkie mozliwe zabawy ze wskaznikami,
dodajemy brzydkie chakierstwa.

template <class T,int SM> void dgemm_bikj2(T *A, T *B, T *C, int N)
{
int i,j,k,ii,kk,jj;
double *AA,*BB,*CC;
for (i = 0; i < N; i+=SM)
for (k = 0; k < N; k+=SM)
for (j = 0; j < N; j+=SM)
for (AA=A+N*i,CC=C+N*i,ii = i; ii < i+SM; ii++,AA+=N,CC+=N)
for (BB=B+N*k, kk = k ; kk < k+SM; kk++,BB+=N)
for (jj = j; jj < j+SM; jj++)
CC[jj] = AA[kk]*BB[jj];

}

SM=32
1) 0.122
2) 1.961 1.841 (SM=64)
Przy 30s w wersji trywialnej.

Matlab (intel math kernel najpewniej), bez sse2
>> A=rand(N);B=rand(N);
>> tic, A*B; toc

1) 0.111
2) 1.560

Podsumowując, kod trywialny jest jest 20 razy gorszy niz gotowce
(atlas powinien byc niewiele gorszy niz matalb). Mimo zawziecia
i nawet zastosowania hakerstwa (te wskazniki, cos ich VC++ nie
zoptymalizowal w przypadku dgemm_bikj jak w dgemm_bikj2)
nie udalo sie dobić do wynikow pakietow (a moje wyniki sa naciagniete,
zakaldam, ze N jest wieloktornoscia szerokosci bloku!)

Kod powstal do podobnej dyskusji tu albo na *.c
Warto przejrzec zalinkowany wtedy material (to raczej podstawy)
http://wazniak.mimuw.edu.pl/index.php?title=MN06#Jak
_napisa.C4.87_kod_.C5.BAle_wykorzystuj.C4.85cy_pami.
C4.99.C4.87_podr.C4.99czn.C4.85.3F


A, wracajac do pierwotnehgo problemu, warto zerknac, czy C i pascal w
tej samej
kolejnosci odkladaja macierze (dwuwymairowe tablice) w pamieci.
Czesciej w programach numerycznych uzywa sie jednej tablicy
(tak jest w blas/lapack, tak jest w powyzszym kodzie) a nie tablic
2D.



pozdrawiam
bartekltg

do góry

W dniu 2011-02-03 11:23, Mariusz Marszałkowski pisze:
> On 3 Lut, 09:54, wloochacz<w...@n...gmail.spameromnie.com>
> wrote:
>> W dniu 2011-02-02 22:40, Fil pisze:>> To tak, z tego co mi widomo, jak troch si
bawi em w te sprawy, to:
>>
>>>> * dla C/C++ najlepszym (b. dobrze optymalizuj cym) kompilatorem by
>>>> ten produkcji Intela;
>>>> * z cz ci obliczeniowej zr b bibliotek dll;
>>>> * tej biblioteki mo esz u y w czymkolwiek, np. w Delphi.
>>
>>> Tak w a nie chc zrobi , ale nie jest to takie proste (wbrew pozorom). I
>>> nie chodzi mi o tworzenie bibliotek i eksportowanie funkcji, klas i
>>> takie tam... (to s bana y),
>>
>> Bana y?
>> Jak uda Ci si wyeksportowa klas z DLLa napisanego w VC++ i utworzy
>> obiekt z tej klasy w C+++ Builder to stawiam co tam chcesz.
> A czemu nie zwykly dll ktorego istnienia kompilator nawet nie
> musi byc swiadomy podczas kompilacji?
Zwykły DLL eksportuje zwykłe funkcje.
I OK - może być.
Ale jak chce się mieć rozbudowany projekt z zależnościami, napisany wg
założeń OOP, to to trochę mało - prawda?

--
wloochacz

do góry

> Zwykły DLL eksportuje zwykłe funkcje.
> I OK - może być.
> Ale jak chce się mieć rozbudowany projekt z zależnościami, napisany wg
> założeń OOP, to to trochę mało - prawda?

Ty to sobie umiesz znaleźć "problem"... ;)))

PK

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On Thu, 03 Feb 2011 11:56:22 +0100, wloochacz
<w...@n...gmail.spameromnie.com> wrote:

>W dniu 2011-02-03 11:23, Mariusz Marszałkowski pisze:
>> On 3 Lut, 09:54, wloochacz<w...@n...gmail.spameromnie.com>
>> wrote:
>>> W dniu 2011-02-02 22:40, Fil pisze:>> To tak, z tego co mi widomo, jak troch si
bawi em w te sprawy, to:
>>>
>>>>> * dla C/C++ najlepszym (b. dobrze optymalizuj cym) kompilatorem by
>>>>> ten produkcji Intela;
>>>>> * z cz ci obliczeniowej zr b bibliotek dll;
>>>>> * tej biblioteki mo esz u y w czymkolwiek, np. w Delphi.
>>>
>>>> Tak w a nie chc zrobi , ale nie jest to takie proste (wbrew pozorom). I
>>>> nie chodzi mi o tworzenie bibliotek i eksportowanie funkcji, klas i
>>>> takie tam... (to s bana y),
>>>
>>> Bana y?
>>> Jak uda Ci si wyeksportowa klas z DLLa napisanego w VC++ i utworzy
>>> obiekt z tej klasy w C+++ Builder to stawiam co tam chcesz.
>> A czemu nie zwykly dll ktorego istnienia kompilator nawet nie
>> musi byc swiadomy podczas kompilacji?
>Zwykły DLL eksportuje zwykłe funkcje.
>I OK - może być.
>Ale jak chce się mieć rozbudowany projekt z zależnościami, napisany wg
>założeń OOP, to to trochę mało - prawda?
No ale to da się osiągnąć inaczej. W końcu, pomiając składniowe
upiększacze, obiektowość sprowadza się do tego, że masz z danymi
powiązane procedury/funkcje. Dll może mieć to rozdzielone, a w języku
klienta stworzy się bibliotekę która odbuduje model obiektowy na
podstawie czysto strukturalnego podejścia.
--
Grzegorz Krukowski

do góry

W dniu 2011-02-03 12:29, Grzegorz Krukowski pisze:
/ciach/

> No ale to da się osiągnąć inaczej. W końcu, pomiając składniowe
> upiększacze, obiektowość sprowadza się do tego, że masz z danymi
> powiązane procedury/funkcje. Dll może mieć to rozdzielone, a w języku
> klienta stworzy się bibliotekę która odbuduje model obiektowy na
> podstawie czysto strukturalnego podejścia.
Jasne, ale po co?
Po co robić coś dwukrotnie (implementacja strukturalna + owijka
obiektowa = problem z utrzymaniem), zamiast napisać raz a dobrze i
zamknąć wszystko w bilbiotece typów?
Używać będzie można z *dowolnym* środowiskiem dla Windows, które wspiera
COM.
Ba! To nawet sprzedawać można :D

--
wloochacz

do góry

On Thu, 03 Feb 2011 12:36:41 +0100, wloochacz
<w...@n...gmail.spameromnie.com> wrote:

>W dniu 2011-02-03 12:29, Grzegorz Krukowski pisze:
>/ciach/
>
>> No ale to da się osiągnąć inaczej. W końcu, pomiając składniowe
>> upiększacze, obiektowość sprowadza się do tego, że masz z danymi
>> powiązane procedury/funkcje. Dll może mieć to rozdzielone, a w języku
>> klienta stworzy się bibliotekę która odbuduje model obiektowy na
>> podstawie czysto strukturalnego podejścia.
>Jasne, ale po co?
>Po co robić coś dwukrotnie (implementacja strukturalna + owijka
>obiektowa = problem z utrzymaniem), zamiast napisać raz a dobrze i
>zamknąć wszystko w bilbiotece typów?
>Używać będzie można z *dowolnym* środowiskiem dla Windows, które wspiera
>COM.
>Ba! To nawet sprzedawać można :D

Dwukrotnie, jednokrotnie, to zależy dla jak szerokiej grupy języków
chcesz udostępnić rozwiązanie. Biblioteka czysto strukturalna będzie
możliwa do dołączenia dla większej gamy języków za cenę niezgodności z
podejściem obiektowym (konieczność napisania bibloteki
,,obiektyzującej''). Tym bardziej, że biblioteka na poziomie
,,umownego C'' jest z reguły bardzo dobrze zdefiniowana (chodzi mi o
ABI). Bo już na poziomie obiektowym, dla C++, to ABI Borlanda jest
niekompatybilne z ABI M$, nie mówiąc o tym, że aby być kompatybilnym z
jakimkolwiek ABI dla C++ to język go wspierający praktycznie musi być
zgodny z C++ (mam nadzieję że nie napisałem tego zbyt mętnie).
Innym rozwiązaniem jest wykonanie biblioteki typu COM, RPC, CORBA,
tylko czy czasami nie jest to wyciąganie armaty na wróbla?
--
Grzegorz Krukowski

do góry

On 3 Lut, 03:37, Mariusz Marszałkowski <m...@g...com> wrote:

> Przeszukaj ta grupe, watek chyba zatytulowany: "matlab taki wydajny?"

O właśnie, tak to sie nazywalo.

> > (Jakieś specjalne ustawienia kompilatora? Przeróbki w kodzie?)
>
> Tak, bardzo prosta i skuteczna przerobka, transponowanie drugiej
> macierzy przed mnozeniem.

Samo transpoonwanie dawalo przyrost rzedu 4 (przynajmniej u mnie).
Najlepsze do czego dochodzilismy (blokowo) dawalo 20razy szybszy
wynik.

Mielismy jeszcze sprawdzic wersje blokowo transpoonwaną,
a ja mailem to puscic na wspolczesnym kompie (a nie na XP1700;),
ale się watek znudzil.

pozdrawiam
bartekltg

do góry