Új hozzászólás Aktív témák

• #5385 Jester01 veterán Jim Tonic #5384

  Új Válasz 2011-09-02 01:36:15 #5385

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Jester01

  veterán

  válasz Jim Tonic #5384 üzenetére

  A kódodból ítélve nem sebesség orientált vagy

  Pedig de. Az egyébként nem az én kódom volt, és bármelyik C fordító tök optimálisra fordítja le. Amúgy gyanítom kicsit jobban értek hozzá, mint te. Azért ne menjük el személyeskedés és e-pénisz verseny felé.

  És mint írtam, a kevesebb utasítás gyorsabb.

  Inkább hadd idézzek akkor az intel optimization manualból, hátha annak hiszel:

  Assembly/Compiler Coding Rule 31. (ML impact, M generality) Avoid using
  complex instructions (for example, enter, leave, or loop) that have more than four
  µops and require multiple cycles to decode. Use sequences of simple instructions
  instead.

  Ez például azt jelenti, hogy x86 assemblyben az enter 8,0 utasítás lassabb mint az őt helyettesítő push ebp; mov ebp, esp; sub esp, 8 3 utasítás (ami 3 sor is, tipikusan) . Előbbi egyébként 4 byte, utóbbi 6 byte gépi kód.

  Vagy ezt, ugyanonnan:

  Assembly/Compiler Coding Rule 49. (H impact, ML generality) If it is
  necessary to extract a non-aligned portion of stored data, read out the smallest
  aligned portion that completely contains the data and shift/mask the data as
  necessary. This is better than incurring the penalties of a failed store-forward.

  Ez például azt jelenti (akár C szinten is), hogy érdemesebb lehet shift (<<) és mask (&) műveletekkel dolgozni egy látszólag tök egyszerű byte olvasásnál is!

  Ezek ugye erősen architektúra-függő dolgok, tehát pszeudokód szinten nincs értelme róluk beszélni. De mondok másik példát. Ha van egy általános kódod ami mondjuk x sor és mindig működik, de van egy másik kódod ami mondjuk y sor de bizonyos (gyakori) esetekben sokkal gyorsabb, akkor megéri olyanra írni a függvényed, hogy előbb z sorban ellenőrzi a feltétel fennállását és az alapján dönt, hogy melyik verzió fusson. Ilyen eset lehet például aligned/unaligned memória vagy egy adott blokkméret (jellemzően például képfeldolgozásnál, de már a mezei memcpy is a legtöbb esetben így működik). Így az x+y+z soros kód mégis gyorsabb lesz az esetek többségében.

  Még vadabbat mondok, általában a rövid kód a legegyszerűbb és legáltalánosabb, ha pedig hatékonyságra gyúrsz akkor sokszor a kifinomultabb adatszerkezet és algoritmus nagyobb kódot és nagyobb memóriafelhasználást is jelent. Példa erre, ha C-ben szeretnél kulcs-érték párokat tárolni. A legegyszerűbb egy tömb, amibe a triviális módon beszúrsz és törölsz, a keresés pedig lineáris. Ez lássuk be elég egyszerű, rövid, nem használ felesleges memóriát és nem utolsósorban dög lassú. Ha nekiállsz helyette egy hash táblát implementálni, az sokkal több sor kód lesz, több gépi kód is, lesz neki memória overheadje és ennek ellenére gyorsabb is lesz (megfelelő hash függvény esetén). Az is köztudott, hogy a kis memóriahasználatra és/vagy kódméretre optimalizálás természetétől fogva nehezen összeegyeztethető a sebességre optimalizálással (bár nyilván vannak kivételek). Extrém példa: ha akarod, tömörítheted az egész program memóriát, ezzel csökken a memória használat de ugyanakkor minden bizonnyal lassul is, kivéve ha ettől befér a fizikai memóriába és nem kell lapozni. Kevésbé extrém példa: a linux kernel szereti processzor cache line határra igazítani a kritikus adatszerkezeteket. Még kevésbé extrém példa: már a C fordító is igazítja a struktúrák elemeit:

  $ cat >t.c
  #include <stdio.h>
  int main()
  {
  struct { int a; unsigned char b; unsigned char c; } x;
  struct { unsigned char b; int a; unsigned char c; } y;
  printf("%d %d\n", sizeof x, sizeof y);
  return 0;
  }
  $ gcc -Wall -m32 t.c && ./a.out
  8 12

  Ugye a második esetben az a mező előtt van 3 byte padding, továbbá mindkét esetben van a végén is még. Ha ezek nem lennének, akkor kevesebb memóriát használna a program viszont esetleg lassabb lenne. Bizonyos architektúrákon nem is futna, vagy hibásan (pl. atomi műveleteknél).

  Nem ettől lesz felesleges egy változó. Az teljesen mást jelent. Pl. részeredmények tárolása.
  Oké, akkor minden bizonnyal elbeszélünk egymás mellett. De a példában az pont egy részeredmény volt. Most akkor ez felesleges vagy nem? Lásd még: premature optimization.

  [ Szerkesztve ]

  Jester

Új hozzászólás Aktív témák