Új hozzászólás Aktív témák
-
-
"n a rendezendeo tomb elem szama. 10 000-es tomb, szerintem nem tul nagy."
A "nem tul nagy" eleg relativ fogalom, siman lehet, hogy a gyakorlatban szinte csak tiznel kevesebb eleme lesz. Elmeleti fejtegetesek alapjan nem lehet optimalizalni, merni kell.
"Ezek szerint akkoriban nem voltak normalis fejlesztok."
Inkabb az lehetett, hogy ezeket a file_id.diz rendezgeto cuccokat nem azok irtak, hanem fogalmatlan tinik.
-
"Ha a ciklusban 5* annyi utasitas van, de 1 000 000 helyett csak 3 000* kell lefutnia, gyorsabb lesz. Meg tobb elem eseten, meg nagyobb az elteres."
Ezzel az a problema, hogy a gyarkolatban nem meg tobb, hanem meg kevesebb elem szokott lenni, ahogy azt mar fent is jeleztem. Nyilvan, ahogy tart az elem szama a vegtelenhez, ugy lesz gyorsabb a kisebb ordoju, viszont egeszen eddig azt magyaraztam, hogy a gyakorlatban egyaltalan nem a vegtelenhez szokott kozeliteni az n, hanem kicsi.
szerk: OK, megvan a zipes sztorik, akkor az arrol szolt, hogy masok minden egyes ziphez kulon meghivtak a pkunzipet, te meg csak egyszer, es akkor tomoritette ki az osszeset. Ez nyilvan jelentos gyorsitas, de azert normalis fejlesztoknel azert alap, hogy kiszurjak, hogy ha egyetlen muvelet viszi el az ido 90%-at, az igazan gyors megoldas meg persze az lenne, ha egyszer sem hivna meg, hanem sajat maga implementalna az unzipet.
-
Amit linkeltel a sortrol, azzal meg egyreszt tisztaban vagyok, masreszt meg pont errol beszeltem, hogy hiaba kisebb az ordo, attol a gyakorlatban meg lehet lassabb, point in case.
A zipes dolgot meg tovabbra sem ertem, de lehet, hogy bennem van a hiba
-
"Az assemblyben irt leggyorsabb buborek rendezest is veri egy jobb algoritmus java-ban megirva."
Egyaltalan nem biztos. "Rule 3. Fancy algorithms are slow when n is small, and n is usually small." ([link])
A peldadat meg nem igazan ertem (a tobbi program ugyanazt a file-t tobbszor is kitomoritette?).
-
buherton
őstag
De nem compilerrel vagy interprettel, és ez a lényeg. Assemblynél a fordítás annyit jelent, hogy az előfordító elvégzi azt amit neki el kell (belhelyettesítést, stb..), és aztán már csak az marad, hogy a szöveges parancsokat, regiszterneveket átírja gépikódra, ami közel sem azonos azzal, hogy elkezd optimalizálni, stb... Erre pedig kíváncsi lennék, hogy egy összetettebb program asm-ben megírva, mennyit hozna a konyhára.
-
#5
#06658560
törölt tag
Drótszamár
#2
#06658560
törölt tag
válasz
Drótszamár
#2
üzenetére
És a bitenkénti kódolás binárisban az smafu?
Komolyra fordítva- az nem lehet, hogy hatékonyabb scriptek létrehozása az általánosan létezök helyett megoldás lehet részben? Esetleg okosan tervezett elágazások, azok vizsgálata, stb.
-
#3
buherton
őstag
Drótszamár
#2
buherton
őstag
válasz
Drótszamár
#2
üzenetére
Nekem is pontosan ez jutott az eszembe.
És hogy miért?
1. rövidebb ideig tart a fordítás, mert nem is kell fordítani
2. gyorsabb és hatékonyabb a kód.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- ÚJ Asus TUF Gaming F17 FX707 - 17.3"FHD IPS 144Hz - i7-13620H - 16GB - 1TB - RTX 4060 -3 év garancia
- Felsőkategóriás merev csöves Gamer PC! I7 12700KF / RTX 3090 24GB / 32GB DDR5 / 1TB SSD!
- Samsung Galaxy Book2 NP750XED i7-1255U 16GB 512GB GARANCIA: 1 ÉV
- Telefon felvásárlás!! Samsung Galaxy A70/Samsung Galaxy A71/Samsung Galaxy A72
- LG 27UP850NP-W - 27" IPS LED - 3840x2160 4K - DisplayHDR 400 - USB Type-C - AMD FreeSync
Állásajánlatok
Cég: FOTC
Város: Budapest