"jelentős energiamegtakarítás érhető el megfelelő programozási módszerek alkalmazásával is"
Valaki tudna ilyet mondani?
Gyorskeresés
Legfrissebb anyagok
- Bemutató Route 66 Chicagotól Los Angelesig 2. rész
- Helyszíni riport Alfa Giulia Q-val a Balaton Park Circiut-en
- Bemutató A használt VGA piac kincsei - Július I
- Bemutató Bakancslista: Route 66 Chicagotól Los Angelesig
- Tudástár AMD Radeon undervolt/overclock
Általános témák
LOGOUT.hu témák
- [Re:] [Luck Dragon:] Asszociációs játék. :)
- [Re:] [sziku69:] Fűzzük össze a szavakat :)
- [Re:] PLEX: multimédia az egész lakásban
- [Re:] eBay-es kütyük kis pénzért
- [Re:] Elektromos rásegítésű kerékpárok
- [Re:] [D1Rect:] Nagy "hülyétkapokazapróktól" topik
- [Re:] [gban:] Ingyen kellene, de tegnapra
- [Re:] [Mr Dini:] Mindent a StreamSharkról!
- [Re:] [bacsis:] Készülődés a BRSZK-ra
- [Re:] [Lalikiraly:] Gigabyte G5 MF notebook bemutató
Szakmai témák
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD.hu témák
Hozzászólások
kispx
addikt
Drótszamár
őstag
assembly
( 2b || !2b ) az itt a kérdés...
buherton
őstag
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.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
MageRG
addikt
Nem hiszem hogy lenne energiatakarékos magasszintű nyelv.
Ez sokkal inkább a compilerek dolga, meg a programozói környezeté.
De érdekelne, pl. egy Java2 ME vagy Android SDK mit tud felmutatni. Hátha valaki hozzáértő tud példát mondani.
"What is bravery, without a dash of recklessness!"
#06658560
törölt tag
É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.
dabadab
titán
1. Assemblyt kell forditani.
2. Nem tennek ra komolyabb penzt, hogy barmilyen, nemtrivialis kodnal a kezzel irt assembly hatekonyabb lenne, mint az, mint amit mondjuk az icc produkal.
[ Szerkesztve ]
DRM is theft
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.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
dabadab
titán
Hat... nem.
DRM is theft
buherton
őstag
A kerneleket nem véletlenül írják C-ben és nem C++-ban vagy Java-ban, vagy PERL-ben.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
dabadab
titán
"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?).
DRM is theft
buherton
őstag
Hiszem ha látom kategória.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
dabadab
titán
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
DRM is theft
dabadab
titán
"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.
[ Szerkesztve ]
DRM is theft
dabadab
titán
"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.
DRM is theft
dabadab
titán
"Akkor melyik algoritmus az optimalis? Az amelyik 0.01 sec alatt vegez a 10 elemuvel de a millioshoz 1 honapra van szuksege, vagy az, ami a 10 elemuvel 0.02 sec alatt vegez, de a milliossal is vegez 1 perc alatt?"
Erre a valasz egy szep nagy "attol fugg".
DRM is theft