BGAFC Vendégkönyv

Σ: 16 post

TCH (statz)

#1, Főfasz (10443)

155 | #1bc0 | ^ | Idézet | Sat, 14 Apr 2012 13:53:22 +02

80.98.*.*

*.catv.broadband.hu

http://hup.hu/cikkek/20120414/egyes_hp_procurve_switchek_malware-rel_kerultek_forgalomba#comment-1446647
Nekem hihetőnek tűnik ez az elmélet. :P

Prometheus (statz)

#3, Főfasz (1824)

43 | #1bc1 | ^ | Idézet | Sat, 14 Apr 2012 17:09:35 +02

84.0.*.*

*.dsl.pool.telekom.hu

Valamelyikőtök játszik a Mass Effect 3-mal?

kemi (statz)

#2, Főfasz (2970)

35 | #1bc2 | ^ | Idézet | Sat, 14 Apr 2012 20:37:19 +02

178.164.*.*

*.pool.digikabel.hu

TCH egész biztos nem, és én sem. :P

TCH (statz)

#1, Főfasz (10443)

163 | #1bc3 | ^ | Idézet | Sat, 14 Apr 2012 22:47:09 +02

80.98.*.*

*.catv.broadband.hu

De én igen! Várjatok miről van szó? Mijaza Maszatfekete Masztieke Maszekta Bassz Seggbe MEKK úgyistuggyátoknemongyátokhogynem 3?

saxus (statz)

#9, Agyfasz (419)

77 | #1bc4 | ^ | Idézet | Sun, 15 Apr 2012 04:40:57 +02

84.3.*.*

*.catv.pool.telekom.hu

Prometheus: vegigvittem a szeriat.

Jha, hai mindenkinek, gondoltam benezek.

kemi (statz)

#2, Főfasz (2970)

533 | #1bc5 | ^ | Idézet | Sun, 15 Apr 2012 10:44:39 +02

94.21.*.*

*.pool.digikabel.hu

Kicsit átírtam a benchmarkot: nagyobb, 8k méretű tömböt rendez, és nem process lefutási időt nézek, hanem algoritmusidőt, mert kicsit unfairnek tartottam az összehasonlítást úgy, hogy a .NET a winfos része, a javának meg ugye el kell indulnia, kicsomagolnia a jart, interpretálni a bytecode-ot, aztán le kell állnia. Így viszont már elég érdekes eredményt kaptam. (mindkettő milliszekundumban mér.)

C:\Users\kemi242>sort.exe
704

C:\Users\kemi242>java -jar sort.jar
312

C:\Users\kemi242>

TCH (statz)

#1, Főfasz (10443)

87 | #1bc6 | ^ | Idézet | Sun, 15 Apr 2012 13:06:01 +02

80.98.*.*

*.catv.broadband.hu

saxus: Beléd is bazdmeg. :)

kemi: Vagyis akkor mégis a ciszta a szarabb, nem a dzsuva?

kemi (statz)

#2, Főfasz (2970)

308 | #1bc7 | ^ | Idézet | Sun, 15 Apr 2012 18:03:46 +02

94.21.*.*

*.pool.digikabel.hu

TCH írta/wrote:
Vagyis akkor mégis a ciszta a szarabb, nem a dzsuva?

Még azért meg kéne próbálni valami mással, mondjuk prímszámkereséssel, (és algoritmusidőt mérni, nem lefutási időt) és meglátjuk melyik nyer.

Ha már sci-fi RPG, én most a Borderlandst keztem el.

TCH (statz)

#1, Főfasz (10443)

270 | #1bc8 | ^ | Idézet | Sun, 15 Apr 2012 18:49:17 +02

80.98.*.*

*.catv.broadband.hu

kemi írta/wrote:
mondjuk prímszámkereséssel

Ahhoz tömbök kellenek? (Sík vagyok matekból, fingom sincs; tudtommal prímet úgy keresünk, hogy a gyökéig elosztjuk minden számmal és ha nincs maradék nélküli, akkor prím, so no tömbök.)

kemi (statz)

#2, Főfasz (2970)

276 | #1bc9 | ^ | Idézet | Sun, 15 Apr 2012 19:14:41 +02

94.21.*.*

*.pool.digikabel.hu

x-ig úgy lehet megkeresni a prímeket, hogy felírod x-ig az egész számokat, megkeresed az első prímet, az a 2, kihúzod a többszöröseit, majd megkeresed az első számot amit nem húztál ki, az a 3, annak is kihúzod a többszöröseit, és így tovább, és a végére csak prímek maradnak.

TCH (statz)

#1, Főfasz (10443)

50 | #1bca | ^ | Idézet | Sun, 15 Apr 2012 19:18:26 +02

80.98.*.*

*.catv.broadband.hu

Szerintem ez lassabb, mint elosztogatni, vagy nem?

kemi (statz)

#2, Főfasz (2970)

106 | #1bcb | ^ | Idézet | Sun, 15 Apr 2012 19:28:56 +02

94.21.*.*

*.pool.digikabel.hu

Az szerintem csak valamekkora valószínűséggel mondja meg. Nem véletlenül vannak prímtesztelő algoritmusok.

TCH (statz)

#1, Főfasz (10443)

106 | #1bcc | ^ | Idézet | Sun, 15 Apr 2012 22:15:48 +02

80.98.*.*

*.catv.broadband.hu

Dehogy is, 100%. Ha a számot a saját gyökéig mindennel elosztasz, akkor tudni fogod, hogy prím-e vagy sem.

saxus (statz)

#9, Agyfasz (419)

50 | #1bcd | ^ | Idézet | Sun, 15 Apr 2012 23:44:42 +02

84.3.*.*

*.catv.pool.telekom.hu

Lemaradtam, ti most mit is akartok benchmarkolni?

saxus (statz)

#9, Agyfasz (419)

2714 | #1bce | ^ | Idézet | Mon, 16 Apr 2012 00:06:38 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
tudtommal prímet úgy keresünk, hogy a gyökéig elosztjuk minden számmal és ha nincs maradék nélküli, akkor prím, so no tömbök.)

Vannak jobb módszerek is, pl. tesztelési módszerek, amely adott valószínűség mellett mondja meg, hogy prím-e vagy sem. Az osztogatásos módszer elég favágó módszer. Fejből meg nem mondom mi az algoritmus neve, majd megkeresem.

Egyébként menedzselt nyevleknél arra jöttem rá, hogy NAGYON nem érdemes előre optimalizálni. Először a feladatot triviálisan megoldó kódot érdemes megírni (természetesen, az adatstruktúrákat értelmesen kell megtervezni), majd utána, ha valahol nem stimmel valami, akkor szigorúan profileing után (mert valószínűleg hamarább hoz ki elvi hibát) benchmarkolni. Miután a jittereket (és a sima statikus fordítókat is egyre okosítják -) felkészítik arra, amit tipikusan írnak az emberek, így egy-egy mikrooptimalizációval sokszor sokkal-sokkal többet árt az ember.

http://tothviktor.wordpress.com/2011/08/22/mikro-optimalizacio-i/
http://tothviktor.wordpress.com/2011/08/23/if-vs-switch/

További érdekességek:

http://tothviktor.wordpress.com/2011/08/27/stringinternal/
http://tothviktor.wordpress.com/2011/12/13/jitter_inlining/

Külön kiemelném, a stringekkel foglalkozó cikket, amely jól bemutatja, hogy miért nem feltétlen szabad hinni a régi ökölszabályoknak. (Erre tudnám hozni példának azt, amikor múltkor az FSZEK-ben mászkáltam, aztán belefutottam egy "Hatékony .NET" című könycbe. Belelapoztam, majd mikor megláttam azt a fejezetet, ahol azt fejtegetik, hogy ne használjunk propertyket, hanem mindig az adattagot publikáljuk ki inkább, tettem is vissza a könyvet a polcra. Ezeket ugyanis, mind a Java, mind a .NET jól kioptimalizálja én meg nem vagyok hajlandó feláldozni azt a biztonságot, amit nyújt - főleg egy többtagú csapat esetén - pl. egy private setter. Ugyanis, aki csak a kódot látja, az nem feltétlen fog tudni arról, hogy azt nem kellene csak úgy írkálni, hanem mondjuk van rá SetLofasz() metódus.

(És akkor még nem beszéltünk a processzornak a mindenféle optimalizációs trükkje, ami mikroarchitektúránként változik.)

Java esetén egyébként nem tudom mi a helyzet, de a tapasztalatom az, hogy ott is lehet gyors dolgot fejleszteni, csak akarni kell. Persze, ott is keresztbe lehet tenni a JIT-ternek meg van pár dolgom, amiben van fenntartásom a nyelvvel. Viszont a tapasztalat az, hogy sok esetben egyszerűen nem éri meg az a plusz időráfordítás, amely a gyorsabb kód fejlesztéséhez kell. Java HotSwap meg <333333 (igazán átemelhetnék a .NET-be is, infrastruktúra igazából félig adott lenne hozzá).

A különféle C fordítók rigolyái meg önmagában egy érdekes témakör.

saxus (statz)

#9, Agyfasz (419)

83 | #1bcf | ^ | Idézet | Mon, 16 Apr 2012 00:07:23 +02

84.3.*.*

*.catv.pool.telekom.hu

Izé... Akarom mondani, szigorúan profileing után optimalizálni ÉS újramérni nutána.