2012. március 26., hétfő

filmek kódként

http://moviesascode.net/

2012. január 30., hétfő

aranyköpések

"linux sex: unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep"

2012. január 26., csütörtök

AJAX simply explained

Hogy működik az AJAX egy egyszerű példán keresztül:

2012. január 23., hétfő

Assembly

Minap belefutottam egy problémába, ahol ARM assembly kódot kellett ellenőrizni hogy jó-e. Elég sokáig nézegettem és vakartam a fejem, hogy most ez mi?
Azóta jobban belemélyedtem az Assembly szépségeibe...
... reggel sétálok az utcán és meglátok egy rendszámot:
JNZ-745
Első reakcióm: mennyi is volt a Zero Flag?

IRL assembly injection? nem rosz...

pic semi-related:

2011. december 21., szerda

benchmark - overkill

A fájlrendszer tesztjénél tartok.

Egy egyszerű teszt, biztos nem lehet belőle baj:
  • 10 MB-nyi nagy fájl létrehozása, majd törlése
  • 4 MB-nyi kis fájl létrehozása, majd törlése

Használhatatlanul belassult a gép, kilőttem a progit. Gondoltam a szemetet eltakarítom Total Commanderrel.

Még most is lassú... Miért?

Megoldás:
10 mega nagy fájl = 10 db 1 megás
4 mega kis fájl = 100 000 db 40 Byteos(!!!)

A windowsnak kis problémája akadt egy 4 megás mappa letörlésével :P

P.S.: a kódban a fájlok számát gyorsan lejjebb csökkentettem két nullával :D

P.S.2: Csak a Total Commander törölte lassan a fájlokat. A windóz 3 perc alatt végzett, majd kifagyott. :D

2011. december 20., kedd

Benchmark

Probléma:
Adott egy rendszer, és egy környetet. A környezet eszközei (jobbára platformfüggetlenig absztrachálva) használatával kell olyan algoritmus, ami az eszköz tulajdonságát méri. Főképp user oldalról, azaz nem a technikai blabla kell hogy hány gigaflops, és MB/s... hanem egy olyan érték, ami korrelál a user által érezhető élménnyel. Értsd: szaggat mint pék a kelttésztát = alacsony pontszám, hasít akár a szélvész = magas pontszám.

Kérdés:
Mi a legjobb módszer ennek az eldöntésére anélkül, hogy pl a kész termék FPS-ét lekérnénk (kissé overkill).

Első körben 3 (négy) alapvető komponenst határozhatunk meg:
  1. Fájlműveletek - Merevlemez/SD kártya...
  2. Memória sebessége (írás, olvasás, random elérés)
  3. Processzor sebessége (nem teljesen szétválasztható a memóriától, lehet együtt is érdemes kezelni)
  4. GPU sebesség a renderelésnél... ezt nehéz tetszőlegesen tesztelni és még ötletem sincs mi lenne releváns teszt és hogyan oldanám meg az eszköztárammal

Fájlműveletek
Az egyik legegyszerűbb, kell írni (konstans patternnel tele) néhány nagyonnagy fájlt a lemezre, és meg kell próbálni végigolvasni.
Majd nagyonsok kicsit, és ugyanezt.
Esetleg nagyonsok kicsit, és találomra kiválasztottakat keresgélni?

memóriaműveletek
Memóriával kb ugyanez, kevés nagy, sok kicsi olvas, ír, és random elérések.
Esetleg lehet még olyat, hogy túlcsordulást és garbage collectiont tesztelni, de felesleges.
Ha nincs elég memória az már alapból user számára kellemetlen, ha meg van elég, akkor minek szivassuk.

Processzor pörgetés
Olyan algoritmus kell, amit a fordító nem számol ki fordítási időben (és mondjuk jól definiált mennyiségű műveletet tartalmaz). Esetleg az is kritérium, hogy olyasmi, amit egyébként is használnánk.
Pl. lehetne hash generálás, vagy random mátrixok szorzása. Esetleg jól definiált pszeudo random függvény. Vagy nagy számításigényű számelméleti feladatok.
Másik kérdés, hogy ezzel még nem mértük a több szál használatának a lehetőségét, ami bizonyos folyamatokat felgyorsít.
Sőt a legtöbb folyamat nem tisztán a processzor teljesítményét méri, hanem memóriástól együtt a kettőt.

Összegzés:
A benchmarknak a végén egy számot kell mondania, ami jól korrelál az eszköz teljesítményével. Ebbe különböző arányban szólnak bele a komponensek. Ezt lehet heurisztikusan meghatározni (értsd: hasamra csapok), vagy sok teszteset után a teljesítményt ábrázolni a részteljesítmények függvényében, és a kapott n+1 (n=3 vagy négy) dimenziós grafikon alapján meghatározni a korrelációs együtthatókat.

Ami egy fizikusnak ugyebár gyerekjáték. :)