On Thu, 03 Feb 2011 09:13:31 +0100, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:

>Fil pisze:
>> W dniu 2011-02-02 17:53, Tomasz Kaczanowski pisze:
>>
>>> Zapewne się nadaje, ogólnie jednak kompilatory Borlanda słabo
>>> optymalizują - niezależnie od języka. Więc zależy od tego co chcemy
>>> obliczać.
>> Jak to zależy? Obliczenia to obliczenia. Zmiennoprzecinkowa arytmetyka:
>> dodawanie, odejmowanie, mnożenie, itd. nic wyszukanego. Na tablicach
>> danych - macierzach.
>
>Znaczenie ma jaki kod wygeneruje. Zresztą chyba już to zauważyłeś, bo w
>innym poście sam podajesz wyniki testu:
>
> > Jeszcze raz - ostatni test i podsumowanie:
> > PASCAL wariant 1 kompilator DELPHI: 8,2s
> > PASCAL wariant 2 kompilator DELPHI: 5,2s
> > CPP wariant 1 kompilator BUILDER: 4,5s
> > CPP wariant 2 kompilator BUILDER: 4,0s
> > CPP wariant 1 kompilator VISUAL: 1,4s
> > CPP wariant 2 kompilator VISUAL: 1,2s
>
>Zwróć uwagę na różnicę między Builderem i Visualem. Po prostu producent
>Buildera i delphi stosuje bardzo stare metody optymalizacyjne, a
>zmieniły się przez te parenaście lat i systemy i procesory. Czasami
>Tobie wydaje się, że kolejność obliczeń nie ma znaczenia, a dla
>procesora może mieć.

Kolejnosc jakich "obliczen"?..

A.L.

do góry

A.L. pisze:
> On Thu, 03 Feb 2011 09:13:31 +0100, Tomasz Kaczanowski
> <kaczus@dowyciecia_poczta.onet.pl> wrote:
>
>> Fil pisze:
>>> W dniu 2011-02-02 17:53, Tomasz Kaczanowski pisze:
>>>
>>>> Zapewne się nadaje, ogólnie jednak kompilatory Borlanda słabo
>>>> optymalizują - niezależnie od języka. Więc zależy od tego co chcemy
>>>> obliczać.
>>> Jak to zależy? Obliczenia to obliczenia. Zmiennoprzecinkowa arytmetyka:
>>> dodawanie, odejmowanie, mnożenie, itd. nic wyszukanego. Na tablicach
>>> danych - macierzach.
>> Znaczenie ma jaki kod wygeneruje. Zresztą chyba już to zauważyłeś, bo w
>> innym poście sam podajesz wyniki testu:
>>
>>> Jeszcze raz - ostatni test i podsumowanie:
>>> PASCAL wariant 1 kompilator DELPHI: 8,2s
>>> PASCAL wariant 2 kompilator DELPHI: 5,2s
>>> CPP wariant 1 kompilator BUILDER: 4,5s
>>> CPP wariant 2 kompilator BUILDER: 4,0s
>>> CPP wariant 1 kompilator VISUAL: 1,4s
>>> CPP wariant 2 kompilator VISUAL: 1,2s
>> Zwróć uwagę na różnicę między Builderem i Visualem. Po prostu producent
>> Buildera i delphi stosuje bardzo stare metody optymalizacyjne, a
>> zmieniły się przez te parenaście lat i systemy i procesory. Czasami
>> Tobie wydaje się, że kolejność obliczeń nie ma znaczenia, a dla
>> procesora może mieć.
>
> Kolejnosc jakich "obliczen"?..

1) przy niektórych obliczeniach zmiennoprzecinkowych posrednie wyniki
nie muszą opuszczać rejestrów. Kolejność istotna może być również dla
tego co znajduje się w keszu. No i pewne znaczenie mają tez potoki.


--
Kaczus
http://kaczus.republika.pl

do góry

W dniu 2011-02-03 09:54, wloochacz pisze:
> 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.
Może tak?:
dlltest.h
//--------------------------------------------------
---------------------------------------------
#ifndef DllTestH
#define DLLTestH

#ifndef __DLL__
#define DLL_EXP __declspec( dllimport )
#else
#define DLL_EXP __declspec( dllexport )
#endif

class ITest
{
public:
virtual double __stdcall Foo1(double A, double B) = 0;
virtual void __stdcall Foo2(char* A) = 0;

virtual void __stdcall Free(void) = 0;
};

#endif
//--------------------------------------------------
---------------------------------------------
dll.cpp
// dlltest.cpp : Defines the exported functions for the DLL application.

#include "stdafx.h"
#include "windows.h"

#define __DLL__
#include "dlltest.h"

class TTest : virtual public ITest
{
public:
double __stdcall Foo1(double A, double B);
void __stdcall Foo2(char* A);

void __stdcall Free(void);
};

double __stdcall TTest::Foo1(double A, double B)
{
return A + B;
}

void __stdcall TTest::Foo2(char* A)
{
strcpy(A, "Ala ma kota.");
}

void __stdcall TTest::Free(void)
{
delete this;
}

extern "C" DLL_EXP ITest* __stdcall CreateTest(void)
{
return new TTest();
}
//--------------------------------------------------
---------------------------------------------

Śmiga aż miło. Być może jest tu jakiś haczyk, ale mi to działa.
Interesuje mnie pożenienie BCB (GUI) z Visualem (obliczenia - lub
ewentualnie w przyszłości kompilator Intela, którego na razie nie mam).
Rozwiązania tylko pod Windows i to jak najprostsze, bez CLI itp. - tylko
C++. Eksport klas do innych języków/kompilatorów itp. nie interesuje mnie.

> A więc wszystko powinno być napisane jak biblioteka COM.
> Jak np. DirectX. Albo ADO.

Jak nie będzie powyższe się sprawdzać to spróbuję z COM. Na razie
sprawdzało się dla App i Dlli kompilowanych jednocześnie w BCB.

Fil.

do góry

W dniu 2011-02-03 09:55, wloochacz pisze:
> 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?
>
Dlaczego badziewny?
Niektóre komponenty podobają mi się. Np. TMS Advanced Charts. Fakt -
może nie wszystkie - kontrolki typu Button, ChomboBox, CheckBox uzywam z
DevExpress, ale w TMS jest też kilka ciekawych propozycji.

do góry

>> Wariant 2 CPP kompilowany w Visual i Builder dotyczy przypadku, gdzie
>> tablica B jest transponowana wcześniej (przed mnożeniem).
> Jesli jest transponowana to dlaczego iterujesz po pierwszym indeksie?
> for (int k = 0; k< Q; ++k) C[i][j] += A[i][k] * B[k][j];
> Powinno byc w obu macierzach po drugim:
> for (int k = 0; k< Q; ++k) C[i][j] += A[i][k] * B[j][k];

Prawda. Jednak przestawiałem indeksy jak pokazałeś i nie dało to
znaczących rezultatów. Wcześniej ostatni wariant CPP ma przestawione
indeksy i czasy dla BCB i Visuala znacznie się różnią.

W zasadzie nie chodziło mi o optymalizację samej procedury mnożenia.
Tylko zastanawiające są tak duże różnice w czasie funkcjonowania tej
samej procedury (nie ważne jak bardzo optymalnej) kompilowanej na
różnych kompilatorach - tu: PASCAL, BCB i Visual.

do góry

Całkiem fajny ten kod, który przedstawiłeś. Może się przydać.

Jak już wcześniej napisałem - nie chodziło mi o optymalizację samej
procedury mnożenia, tylko zastanowiła mnie tak duża różnica w działaniu
jednej procedury kompilowanej na trzech różnych kompilatorach.

Wniosek jest - zapewne dla niektórych oczywisty - że Visual jest lepszy
od Delphi i BCB. Niemniej zaskoczyła mnie aż tak duża różnica.

Pozdrawiam wszystkich i dziękuję za dyskusję.
EOT.
Fil.

do góry

On 3 Lut, 14:01, bartekltg <b...@g...com> wrote:
> 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.

Chyba na roznych komputerach / kompilatorach byly rozne wyniki.
U mnie chyba transpozycja dawala najwiecej, a blokowo niewiele.
Pozdrawiam

do góry

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

>
> Chyba na roznych komputerach / kompilatorach byly rozne wyniki.
> U mnie chyba transpozycja dawala najwiecej, a blokowo niewiele.

Cos niewierze;) Jak narzeczona zejdzie ze 'wspolczesnego kompa'
sprawdze:) Jakos nie che mi sie testowac tego na 'panstwowych'
maszynach.

pozdrawiam
bartekltg

do góry

W dniu 2011-02-03 15:36, Tomasz Kaczanowski pisze:
> A.L. pisze:
>> On Thu, 03 Feb 2011 09:13:31 +0100, Tomasz Kaczanowski
>> <kaczus@dowyciecia_poczta.onet.pl> wrote:
>>
>>> Fil pisze:
>>>> W dniu 2011-02-02 17:53, Tomasz Kaczanowski pisze:
>>>>
>>>>> Zapewne się nadaje, ogólnie jednak kompilatory Borlanda słabo
>>>>> optymalizują - niezależnie od języka. Więc zależy od tego co chcemy
>>>>> obliczać.
>>>> Jak to zależy? Obliczenia to obliczenia. Zmiennoprzecinkowa
>>>> arytmetyka: dodawanie, odejmowanie, mnożenie, itd. nic wyszukanego.
>>>> Na tablicach danych - macierzach.
>>> Znaczenie ma jaki kod wygeneruje. Zresztą chyba już to zauważyłeś, bo
>>> w innym poście sam podajesz wyniki testu:
>>>
>>>> Jeszcze raz - ostatni test i podsumowanie:
>>>> PASCAL wariant 1 kompilator DELPHI: 8,2s
>>>> PASCAL wariant 2 kompilator DELPHI: 5,2s
>>>> CPP wariant 1 kompilator BUILDER: 4,5s
>>>> CPP wariant 2 kompilator BUILDER: 4,0s
>>>> CPP wariant 1 kompilator VISUAL: 1,4s
>>>> CPP wariant 2 kompilator VISUAL: 1,2s
>>> Zwróć uwagę na różnicę między Builderem i Visualem. Po prostu
>>> producent Buildera i delphi stosuje bardzo stare metody
>>> optymalizacyjne, a zmieniły się przez te parenaście lat i systemy i
>>> procesory. Czasami Tobie wydaje się, że kolejność obliczeń nie ma
>>> znaczenia, a dla procesora może mieć.
>>
>> Kolejnosc jakich "obliczen"?..
>
> 1) przy niektórych obliczeniach zmiennoprzecinkowych posrednie wyniki
> nie muszą opuszczać rejestrów. Kolejność istotna może być również dla
> tego co znajduje się w keszu. No i pewne znaczenie mają tez potoki.

Dokładnie. Tutaj widzimy, że jednak ten sam algorytm (o tej samej
teoretycznej złożoności asymptotycznej) działa w praktyce w różnym
czasie w obu kompilatorach. Nie stoi to oczywiście w sprzeczności z
asymptotyką. Pokazuje jedynie, że nie tylko teoria ma znaczenie,
praktyka również :).

do góry

On 3 Lut, 22:12, bartekltg <b...@g...com> wrote:
> On 3 Lut, 22:04, Mariusz Marszałkowski <m...@g...com> wrote:
>
>
>
> > Chyba na roznych komputerach / kompilatorach byly rozne wyniki.
> > U mnie chyba transpozycja dawala najwiecej, a blokowo niewiele.
>
> Cos niewierze;) Jak narzeczona zejdzie ze 'wspolczesnego kompa'
> sprawdze:) Jakos nie che mi sie testowac tego na 'panstwowych'
> maszynach.

Tzn na jakims komputerze / kompilatorze blokowo niewiele
przyspieszalo
(albo nawet spowalnialo) wzgledem wersji z sama transpozycja, nie
wzgledem algorytmu naiwnego.

Pozdrawiam

do góry