- D1Rect: Nagy "hülyétkapokazapróktól" topik
- GoodSpeed: Bye PET Palack, hello SodaStream
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- btz: Internet fejlesztés országosan!
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- LordAthis: AI Kérdés érkezett - 3600 soros Spagetti kód refaktorálása és budget
- LordOLOG Szféra
- sh4d0w: Netflix? Ugyan, VW előfizetés!
-
LOGOUT
Új hozzászólás Aktív témák
-
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 12Ugye 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.
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- Óvodások homokozója
- Megjött a jubileumi Pixel széria
- Notebook / laptop alkatrészek cseréje (processzor, RAM, HDD)
- iPhone topik
- Azonnali alaplapos kérdések órája
- Kormányok / autós szimulátorok topikja
- Elektromos autók - motorok
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Új Dell 13 XPS 9315 FHD+ IPS i7-1250U 4.7Ghz 10mag 16GB RAM 512GB SSD Intel Iris XE Win11 Garancia
- Bomba ár! Dell Latitude 5320 - i5-11GEN I 16GB I 256SSD I HDMI I 13,3" FHD Touch I Cam I W11 I Gari!
- Xiaomi Redmi Note 13 Pro 256GB Kártyafüggetlen 1 év Garanciával
- HIBÁTLAN iPhone 11 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS2132
Állásajánlatok
Cég: FOTC
Város: Budapest