Zkušenosti s jazykem D

[RAII]

To stopWatch tam funguje perfektně jen ho tam nech. Pokud si navíc čet diskuzi, tak víš že po kompilaci na DMD to sežere 2s u mne. Když použiju GDC tak 7,6. Ale to je bug GDC.

[Reklama]

[RAII]

Jo tak ji udělá inline, a co? tak se holt vypustí pár instrukcí (call a ret + stack frame zůstane (možná)). Neprovede se jen jedna instrukce.

[Sten]

To stopWatch tam funguje perfektně jen ho tam nech. Pokud si navíc čet diskuzi, tak víš že po kompilaci na DMD to sežere 2s u mne. Když použiju GDC tak 7,6. Ale to je bug GDC.

Akorát to měří něco jiného (a menšího) než time při měření toho C++. Pokud to má k něčemu být, je potřeba to měřit to stejným způsobem.

Jo tak ji udělá inline, a co? tak se holt vypustí pár instrukcí (call a ret + stack frame zůstane (možná)). Neprovede se jen jedna instrukce.

OK, neprovádí to jednu instrukci, ale dvě. Načte to konec pole a odečte jej od začátku (který se načítá stejně, protože se s ním v tom cyklu pracuje v operator []).

Kód: [Vybrat]

mov 0x8(%rcx,%r14,1),%rax
sub %rdx,%rax

[Kozzi]

To stopWatch tam funguje perfektně jen ho tam nech. Pokud si navíc čet diskuzi, tak víš že po kompilaci na DMD to sežere 2s u mne. Když použiju GDC tak 7,6. Ale to je bug GDC.

No tak jsem delal testy a neni to bug gdc ale obecne toho frontendu ktery je v aktualni verzi gdc co pouzivas. Takze jakmile vyjde gdc a i ldc s verzi frontendu 2.64 ci vyssi tak uz to bude ok.

[gamer]

Průměrně líný programátor v C++ použije tohle:

Kód: [Vybrat]

#include <boost/numeric/ublas/matrix.hpp>
#include <random>

int main()
{
    boost::numeric::ublas::matrix<int> m1(100, 100);
    boost::numeric::ublas::matrix<int> m2(100, 100);

    std::random_device rnd;
    for (unsigned i = 0; i < m1.size1(); ++i)
        for (unsigned j = 0; j < m1.size2(); ++j)
            m1(i, j) = m2(i, j) = rnd() % 10;

    for (int i = 0; i < 1000000; ++i)
        m1 += m2;

    return 0;
}
Zkompilované bez debugů:

Kód: [Vybrat]

g++ -O3 -std=c++0x -DBOOST_UBLAS_NDEBUG main.cc -o main
Je to o 25% pomalejší než Stenův ručně optimalizovaný kód, což mi přijde jako akceptovatelná cena za obecnost matice a za 2D reprezentaci v paměti. Mimochodem jak někdo psal, že v C++ se neprovedou SIMD optimalizace, není to pravda, počítá se to SIMD instrukcemi:

Kód: [Vybrat]

.L28:
    movdqu  (%rax,%rcx), %xmm1
    movdqu  (%rax,%rdx), %xmm0
    paddd   %xmm1, %xmm0
    movdqa  %xmm0, (%rdx,%rax)
    addq    $16, %rax
    cmpq    $400, %rax
    jne .L28


[Reklama]

[RAII]

To sem říkal já. Je to pravda, kompiler c++ není schopen udělat simd optimalizace oproti D compileru. Tys tam pouzivas člověkem optimalizovanou knihovnu která pogužívá simd instrukceh nic víc nic min. A pokud si nepochopil tak mi jsme souperili o to který jazyk je rychlejší ne o znalosti knihoven. Omluvte můj psanej projev, píšu na mobilu a navíc to psací pole tady na fóru je luxusně bugli takže co napisu uz neopravim.

[gamer]

To sem říkal já. Je to pravda, kompiler c++ není schopen udělat simd optimalizace oproti D compileru. Tys tam pouzivas člověkem optimalizovanou knihovnu která pogužívá simd instrukceh nic víc nic min. A pokud si nepochopil tak mi jsme souperili o to který jazyk je rychlejší ne o znalosti knihoven. Omluvte můj psanej projev, píšu na mobilu a navíc to psací pole tady na fóru je luxusně bugli takže co napisu uz neopravim.

To se mýlíš, boost je portabilní source code knihovna, ve které žádný assembler není, SIMD instrukce generuje překladač. Stenův kód se na SIMD instrukce rozgeneruje úplně stejně:

Kód: [Vybrat]

.L12:
    movdqa  (%rbp,%rax), %xmm0
    paddd   (%rbx,%rax), %xmm0
    movdqa  %xmm0, (%rbx,%rax)
    addq    $16, %rax
    cmpq    $40000, %rax
    jne .L12
Jediný rozdíl oproti boostu je v tom, že se to všechno spočítá v jednom cyklu místo dvou vnořených (1D versus 2D pole), proto je boost o něco pomalejší.

[Kozzi11]

To sem říkal já. Je to pravda, kompiler c++ není schopen udělat simd optimalizace oproti D compileru. Tys tam pouzivas člověkem optimalizovanou knihovnu která pogužívá simd instrukceh nic víc nic min. A pokud si nepochopil tak mi jsme souperili o to který jazyk je rychlejší ne o znalosti knihoven. Omluvte můj psanej projev, píšu na mobilu a navíc to psací pole tady na fóru je luxusně bugli takže co napisu uz neopravim.

Nee tady se pletes. Jde o to ze ty optimalizace dela v obou pripadech az gcc. Takze ekvivaletni kod v D a v C++ je v takto jednoduchych prikladech velmi casto v podstate stejny. Jde o to ze gdc je jen frontend D + gcc jako backend. A jelikoz se vetsina optimalizaci provadi az na urovni backendu, tak je velka sance ze vysledny vygenerovany kod jak pro D verzi tak i pro C++ verzi bude velmi podobny. Samozrejme je treba takto porovnavat stejne backendy (gdc x g++, ldc x llvm-clang, dmd vs dmc).

Samozrejme i frontend ma vliv na rychlost a "optimalizace", viz treba ten bug v D frontendu ve verzich nizsich jak 2.64.

[RAII]

Ok, přiznávám svou chybu. Asi se do toho ponořím a kouknu se pořádně do vnitřností, nechci se ohánět bludy.

[Bloodman]

Zdravim, tak jak vidim tak sa tu konecne zacalo riesit nieco ohladom Dcka
Ja ho uz 2. rokom pouzivam na programovanie svojho operacneho systemu a frameworku. Zatial som z Dckom nemal ani najmensi problem a vsetko sa v nom dalo elegantne vyriesit. A oproti C++ je to prechadzka ruzovym sadom

Niekdo sa tu pital nieco ohladom druntime platform independant a programovaniu OS.
No ja pouzivam vzdy najnovsiu verziu Dcka aktualne 2.065, kompilator DMD a originalny druntime v ktorom som si akurat odstavil GC a premostil ho na pouzitie vlastnych funkcii malloc, free. Vsetky casti druntimu ktore pouzivam su platform independant tak ze s tym problem nemam.

[RAII]

TO Bloodman: Neleakují paměť některé funkce v druntime? Pokud ne tak je to celkem fajn. Škoda je, že paměť se leakne bez GC dost snadno. Ne všude kde by se hodilo volat funkci z druntime, se volá funkce z druntime:

Kód: [Vybrat]

int[] arr1 = [47,85,96];
int[] arr2 = [88,96,75];
arr1 = arr2;
 
Původní paměť v arr1 leakne a pokud vím, tak při týhle operaci se nevolá žádná funkce v druntime, což je škoda.