Příspěvky

31

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 20:27:51 »

Zapnutí optimalizátoru samozřejmě není žádné cheatování ale regulérní metoda, jejíž možnost a přínosnost je naopak ukazatelem vhodnosti toho či onoho jazyka pro rychlý běh aplikací.

Ano, zapnutie optimalizatora v tomto pripade je skutocne cheatovanie, pretoze ucel testu je porovnat KTORY PROGRAM VYKONA DANY CYKLUS RYCHLEJSIE. Kedze optimalizator dany cyklus ODSTRANI, je test uplne na prd. V inom pripade, ked by cyklus mal skutocny zmysel by sa to nedalo takto osalit.
Preto stale za jediny spravny test povazujem test bez optimalizacie, v ktorom je C# 4-5x rychlejsi ako C (aj s pouzitim registrov).

32

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 20:24:58 »

Schválně si zkus ještě přeložit a pustit tohle:

Kód: [Vybrat]

int main() {
  register int n = 0;
  for (register int i = 0;  i < 999999999;  i++) {
    n++;
  }
}


skusim som a je to o kusticek rychlejsie, stale vsak asi 4x pomalsie

real   0m3.059s
user   0m3.036s
sys   0m0.004s

33

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 19:18:03 »

Nicnerobenie by mu urcite netrvalo skoro sekundu.

Musí přece nainicializovat tu svou virtuální mašinu, ne?

Můžeš si udělat test. Pokud se ten cyklus opravdu provádí, tak by se doba běhu měla měnit s počtem iterací cyklu (měla by to být přibližně afinní funkce). Co když těch iterací bude 2*999999999?

Ked je iteraci 2x viac tak aj cas behu je priblizne 2x vacsi:

real   0m1.884s
user   0m1.872s
sys   0m0.012s

mimochodom, tu je podstatna cas CIL kodu C# programu (tomu sa uz vobec nerozumiem )


   .entrypoint
   // Code size 29 (0x1d)
   .maxstack 3
   .locals init (
      int32   V_0,
      int32   V_1)
   IL_0000:  ldc.i4.0
   IL_0001:  stloc.0
   IL_0002:  ldc.i4.0
   IL_0003:  stloc.1
   IL_0004:  br IL_0011

   IL_0009:  ldloc.0
   IL_000a:  ldc.i4.1
   IL_000b:  add
   IL_000c:  stloc.0
   IL_000d:  ldloc.1
   IL_000e:  ldc.i4.1
   IL_000f:  add
   IL_0010:  stloc.1
   IL_0011:  ldloc.1
   IL_0012:  ldc.i4 999999999
   IL_0017:  blt IL_0009

   IL_001c:  ret
    } // end of method Program::Main

34

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 19:08:22 »

Ale podla mna je spravne porovnavat bez akychkolvek -O, pretoze vtedy kompilator C urobi len nejake vychytraciny (cheatuje ) zatial co C# to musi vsetko spravit poctivo. Takze zatial za pravoplatne porovnanie povazujem to z mojho prveho prispevku.

To je hloupost, kompilátor C# také jistě provádí optimalizace, takže je dost možné, že ani on ten cyklus vlastně vůbec neprovádí 

Nicnerobenie by mu urcite netrvalo skoro sekundu. Skusim sa nejako dopracovat aj k skompilovanemu C# kodu a uvidime co robi.

35

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 18:58:07 »

Ale podla mna je spravne porovnavat bez akychkolvek -O, pretoze vtedy kompilator C urobi len nejake vychytraciny (cheatuje ) zatial co C# to musi vsetko spravit poctivo. Takze zatial za pravoplatne porovnanie povazujem to z mojho prveho prispevku.

36

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 18:54:43 »

Kedze assembler neovladam, davam vam tu tie kody:

bez -O3

   .file   "test.c"
   .text
   .globl   main
   .type   main, @function
main:
.LFB0:
   .cfi_startproc
   pushq   %rbp
   .cfi_def_cfa_offset 16
   .cfi_offset 6, -16
   movq   %rsp, %rbp
   .cfi_def_cfa_register 6
   movl   $0, -8(%rbp)
   movl   $0, -4(%rbp)
   jmp   .L2
.L3:
   addl   $1, -8(%rbp)
   addl   $1, -4(%rbp)
.L2:
   cmpl   $999999998, -4(%rbp)
   jle   .L3
   movl   $0, %eax
   popq   %rbp
   .cfi_def_cfa 7, 8
   ret
   .cfi_endproc
.LFE0:
   .size   main, .-main
   .ident   "GCC: (Ubuntu/Linaro 4.7.2-23ubuntu2) 4.7.3"
   .section   .note.GNU-stack,"",@progbits

s -O3 (super rychle)

   .file   "test.c"
   .section   .text.startup,"ax",@progbits
   .p2align 4,,15
   .globl   main
   .type   main, @function
main:
.LFB0:
   .cfi_startproc
   xorl   %eax, %eax
   ret
   .cfi_endproc
.LFE0:
   .size   main, .-main
   .ident   "GCC: (Ubuntu/Linaro 4.7.2-23ubuntu2) 4.7.3"
   .section   .note.GNU-stack,"",@progbits

37

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 18:44:41 »

tak to zkompiluj s -O3

Tak s -O3 to uz facha na 0.003 sa vykon fakt zlepsil.

ale inac nebude to tym, ze s -O3 kompilator spravi take veci, ze uplne vynecha dany cyklus a dosadi do n rovno tu hodnotu, ktoru bude mat jasne na konci cyklu?

38

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 18:40:33 »

tak to zkompiluj s -O3

Tak s -O3 to uz facha na 0.003 sa vykon fakt zlepsil.

39

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 18:37:56 »

C program je skompilovany pomocou gcc

A s jakými flagy?

So ziadnymi. Teraz som to vyskusal skompilovat s -std=c99 ale vysledok je uplne rovnaky.

40

Vývoj / Re:C# je rychlejsi ako C/C++?!?!

« kdy: 12. 04. 2013, 18:33:59 »

Operacny system: Ubuntu 13.04
Mono 2.10.8.1
GCC 4.7.3

41

Vývoj / C# je rychlejší než C/C++?

« kdy: 12. 04. 2013, 18:27:27 »

Nazdar!

Urobil som maly test a vysledok ma velmi prekvapil. Napisal som tento program v C#:

Kód: [Vybrat]

using System;

namespace TestApp
{
class Program
{
public static void Main(string[] args)
{
int n = 0;
for (var i = 0; i < 999999999; i++) {
n++;
}
}
}
}
a ten isty program v C:

Kód: [Vybrat]

int main() {
  int n = 0;
  for (int i = 0;  i < 999999999;  i++) {
    n++;
  }
}
C program je skompilovany pomocou gcc, C# je skompilovany v MonoDevelop. Toto su casy behu programov odmerane pomocou utility time:

C
real   0m3.507s
user   0m3.504s
sys   0m0.000s

C#
real   0m0.707s
user   0m0.692s
sys   0m0.012s

Z toho vyplyva, ze (samozrejme pre dany program, ktory je vsak dost vseobecny ohladne vykonu) C# je takmer 5x rychlejsi ako C.

Co na to hovorite?

PS: nie nijako som sa nepomylil!

42

/dev/null / Re:Prosím o pomoc s programem

« kdy: 09. 04. 2013, 18:17:18 »

Hodil jsem ten dotaz do Googlu, protože mne zajímalo, kde všude se ještě ptal, a to, co jsem našel, mne docela překvapilo: http://programujte.com/forum/vlakno/23969-prosim-o-pomoc-s-programem/

No parada! Aj ked je uplne samozrejme, ze WEBOVY VYVOJAR nie je ani nahodou programator a tu mame zivy priklad.
Mimochodom, toto je jeho webova stranka: http://www.milankubik.cz/

(to som ale svina... )

43

Odkladiště / Re:Matematický problém s úhly

« kdy: 05. 04. 2013, 10:05:41 »

Jarek: pouzivam fyzikalnu kniznicu PyMunk a v nej GearJoint pre vytvorenie klbu medzi dvoma objektami. GearJoint urcuje UHOL, ktory maju dane objekty zvierat. Preto nemozem pouzit vektory ani nic podobne ale uhly (samozrejme v radianoch).

44

Odkladiště / Re:Matematický problém s úhly

« kdy: 02. 04. 2013, 20:43:40 »

A funguje to i kdyz je koncovy = -180 a pocatecni = 180?
Protoze pak je to (alespon v C) (-180-180+180)%360-180=-180-180=-360 misto 0 (protoze % na zaporne cislo vraci zaporne cislo - on je to ve skutecnosti operator "zbytek po celociselnem deleni" definovany pro A % B jako "nejmensi cele cislo C takove, ze C*B <= A", nebo podle c99 "(A/B) * B + A%B = A" (kde "/" je celociselne deleni, ktere zaokrouhluje smerem k nule)) - to prave zalezi na pouzitem jazyku, jestli % definuje pres zbytek po deleni, nebo jinak.

Ja bych tam navrhnul ((koncovy-pocatecni)%360+360+180)%360-180 // 360+180 dopocita kompilatorpri prekladu, do zdrojaku to napisu rozdelene aby bylo jasnejsi odkud se ktere cislo bere
Pokud mam zaruceno ze oba vstupni uhly jsou mezi -180 a +180, tak si muzu vystacit s (koncovy-pocatecni+360+180)%360-180

No v Pythone som to napisal priblizne takto:

def posun(pociatocny, koncovy):
  return (koncovy - pociatocny + 180) % 360 - 180

A nech je to akokolvek divne tak: posun(180, -180) je 0 aj posun(-180, 180) je 0. Takze mne takato funkcia funguje velmi dobre.

45

Odkladiště / Re:Matematicky problem s uhlami

« kdy: 02. 04. 2013, 18:22:58 »

Těch -170 má být +10, ne +20 ;-)

Hmm, špatně jsem pochopil, co se tam počítá, těch +20 je správně. Ten algoritmus pak stačí vhodně upravit:

(koncovy - pocatecni + 180) % 360 - 180

Super, dakujem toto funguje absolutne dokonale!

Jak výše někdo podotkl, je tam chyba, pro zápornou hodnotu koncovy - pocatecni je potřeba otočit znaménka u těch 180.

Nie je to treba. Funguje to perfektne pre vsetky pripady. Otestoval som priamo v hre.