HTML

Programozó Páternoszter

Ez a Programozó Páternoszter (PP) blogja, a programozásról szól. Aktualitása, hogy a Debreceni Egyetem Informatikai Kara Magasszintű programozási nyelvek 1-2, C++ esattanulmányok, Java esettanulmányok című kurzusainak blogja is egyben.

A vadászat

A Debreceni Egyetem Programozói Évkönyve: az UDPROG projekt. A szakmai fórumunk a Facebook-en. Az új előadások a prezin.
A régi előadások:
Prog1:
1. C bevezetés
2. C tárgyalás
3. C befejezés
4. C a gyakorlatban
5. C++ bevezetés
6. C++ tárgyalás
7. C++ befejezés
8. C++ a gyakorlatban
9. Java platform bevezetés
10. Kvantuminformatikai alg. bev.
Prog2:
1. Java bevezetés
2. Java tárgyalás
3. Java befejezés
4. Java a gyakorlatban
5. Software Engineering bev.
6. Java EE bevezetés
7. AspectJ bevezetés
8. BPMN-BPEL SOA programozás
9. C++ haladó
10. Tensorflow

Kövess engem!

Friss topikok

Linkblog

YANonymous élesítve

2013.10.21. 00:48 nb

Múlt hét szerdától elérhető a git repó a SF-on, most már át is szerveztem: egy "Helló, Világ!" szintű Google Protobuf kommunikációs osztályt formálisan betettem a Maven projektbe (lásd a pom.xml-t). Ez lesz az alapja a YANonymous Construct és a YANonymous Puzzle közötti kommunikációnak.

Az API forgatása

Az előző laboron az immár IDE független (azaz Maven csomagként elkészített) YANO csomagot szereltük fel különféle riportokkal, s kicsit a projekt szakmai vezetőjeként ellenőriztünk néhány riportot, hogy például betartottuk-e a kódolási szabályokat? egyébként koránt sem... 

A mostani poszt fővonala előtt jöjjön egy reguláris kitérő: 5 pontért ismételd meg az alábbi mérést. Nem haszontalan, hiszen ezt a Java (vagy saját, de ugyanezt végző) programot kell "félévközbeni védésként" bemutatnod.

Nyilván a prog1 után lerágott csont a humán genom 2. kromoszómája, de ismételjük  meg most Javában a futtatást:

norbi@colossus:~/P2$ javac LZWBinFa.java
norbi@colossus:~/P2$ wget ftp.ncbi.nlm.nih.gov/genomes/H_sapiens/CHR_02/hs_alt_HuRef_chr2.fa.gz
norbi@colossus:~/P2$ gunzip hs_alt_HuRef_chr2.fa.gz
norbi@colossus:~/P2$ time java LZWBinFa hs_alt_HuRef_chr2.fa -o kimenet

real    4m22.409s
user    3m51.348s
sys    0m52.252s
norbi@colossus:~/P2$ tail kimenet
------------------------------------------------------------------------------------------0(29)
------------------------------------------------------------------------0(23)
------------------------------------------------------------------0(21)
------------------------------------------------0(15)
------------------------------------------0(13)
------------------------0(7)
------------------0(5)
depth = 291
mean = 77.910095987775
var = 8.81903638228341

Ha menet közben elszállna a program, pl. notebook-okonez tipikus lesz, akkor add ki a jconsole parancsot, ha a JDK bin könyvtára szokás szerint benne van a PATH-ban, akkor ez indulni fog simán, s látni fogod, hogy a heap használatával volt a gond, ez esetben a java nem sztenderd opcióit kell használnod (lásd java -X, a képen nem volt gond egyébként, ahogyan látszik is)

prof1.png

S most jöjjön maga a mérés, aki az átírásban a java.io.PrintWriter helyett eleve a java.io.PrintStream osztályt használta, az alapban élvezheti a 2. kromóra futtatást :) Egyébként elég formálisan cserélni a Writer-t Stream-re, illetve a main-ben az alábbi pár sort tedd a szereplő helyére:

      java.io.PrintStream kiFile =
              new java.io.PrintStream(
              new java.io.FileOutputStream(args[2]));

Csak ki tudtam várni az eredményt:

norbi@colossus:~/P2$ javac LZWBinFa.java
norbi@colossus:~/P2$ time java LZWBinFa hs_alt_HuRef_chr2.fa -o kimenet

real    63m31.260s
user    17m31.872s
sys    47m20.944s

prof2.png

15 pontot ér, ha megmagyarázod a futási idő 5 percről 1 óra 5 percre növekedését, 5 pont, ha jeéentkezik memóriagond, de elhárítod, további 10, ha a Stream-el is lefut jó időben.

Védési szezon

A következő két hétben javaslom beütemezni az első védést, ahol éppen az iménti programot kell védeni, lehat akár már holnap is! Laborközösségenként az első 3 sikeres védőnek holnap, de csak holnap 10-10 pont is üti a markát. Védeni természetesen teljesen saját programot is lehet, feltéve, ha ugyanazt adja, mint a fenti (természetesen minden félévben más és más az eredmény, s nyilván nem a 2. kromoszóma változott meg, hanem a programunk javult, de most igazodjunk a default progi kimenetéhez.)

A védések lesznek tehát a fókuszban, de íme néhány feladat a következő két laborra:

  • 5 pontért végezd el a BBP-s sebességtesztet, ahol a C és a Java implementációt veted össze. További 25 pontot könyvelhetsz el magadnak, ha ehhez a 2 nyelves összehasonlításhoz további nyelveken (pl.: C#, Python stb.) is implementálod a programot (nyilván ugyanazt adja). Ne felejts el elolvasni a Javát tanítok ezeket a programokat tárgyaló részét! Hiszen itt találod a szóban forgó forrásokat is.
  • 15 pont, ha ezt a Maven alapú "Helló Világ!" szervletes példát feléleszted tetszőleges környezetben, s további 15 pont minden más környezetért (pl. az előadás fóliák alapján defaultban deployolod Tomcat-re, majd további ismerkedésként az alkalmazásszerverek használatával: GlassFish 2, GlassFish 3-ra, vagy ébben JBoss-ra).
  • 30 pont, ha feltöröd ezt a hibásan implementált RSA-val kódolt titkos szövege. Indulj ki az előadás fóliáiból és szótár alapon törd! Ilyen törés lesz az írásbeli vizsga szokásos "beugrója", ezért szerintem semmiképen ne hagyd ki!

55 komment

A bejegyzés trackback címe:

https://progpater.blog.hu/api/trackback/id/tr95590136

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

veni_vidi_vici 2013.10.21. 02:06:26

A PrintStream úgy ír karaktereket, hogy előbb byte-tá konvertálja azokat a platform alapértelmezett kódolásával. PrintWriter használata esetén nem történik konverzió, valamint mi határozzuk meg a kódolást, ezzel elkerüljük a platformtól való függőséget.
A futási idő drasztikus növekedése a char -> byte konverziók miatt következik be. (15 pont)

Moonquake · https://soundcloud.com/alice-margatroid-1/nhato-moonquake?fb_action_ids=602478393129432&fb_action_ty 2013.10.21. 07:34:28

Jelentkezett a memória gond, de elhárítottam.

A hiba:
kepfeltoltes.hu/131021/error_www.kepfeltoltes.hu_.png

A megoldás monitorozás mellett:
kepfeltoltes.hu/131021/elindul_www.kepfeltoltes.hu_.png

...
kepfeltoltes.hu/131021/kesz_www.kepfeltoltes.hu_.png

A megoldás time-al és kimenettel:
kepfeltoltes.hu/131021/time_es_kimenet_www.kepfeltoltes.hu_.png

...

(Ez most 5 pont, mert sikerült az időmérés, vagy 10, mert sikerült az időmérés hibaelhárítás után?)

Moonquake · https://soundcloud.com/alice-margatroid-1/nhato-moonquake?fb_action_ids=602478393129432&fb_action_ty 2013.10.21. 08:08:09

Továbbá 15 pontért a - remélem helyes - magyarázatom a futási idő megnyúlására:

A PrintStream sokkal lassabb, mert a buffer-ürítés (flush) mindig megtörténik byte array után, println metódusra hivatkozás után, vagy újsor karakter, ('\n') után.
Ezzel szemben a PrintWriter esetén:
Autoflush engedélyezése mellett is csak akkor üríti a buffert, ha új println() metódust hívunk.

B.Norbi93 2013.10.21. 20:22:07

Ezeket a futtatásos pontokat úgy is be lehet adni, hogy már 1x beadtam (és nyilván futtattam is) egy saját BinFa verziót?

Valamint a saját verzió az kiváltja a védést, vagy azt is ugyanúgy meg kell védeni?

nb · http://fersml.blog.hu 2013.10.21. 21:12:13

@B.Norbi93: persze, ahány valóban különböző sw megoldás, annyiszor élted át az élményt, így pont is annyiszor. Mint a P1, hogy ki-mit véd, az függ habitustól-tudástól-időbeli elfoglaltságtól stb. Annyit kérek, hogy futtatáskor ugyanazt adja, mint amost a posztban (ahhoz rontsuk :)

Láthajátok, szinte minden évben más eredmény jött ki, mert a progi mindig BUG-os, hiszen ez az alaptermészete :)

nb · http://fersml.blog.hu 2013.10.21. 22:34:32

@Moonquake: vitatható kérdésben mindig a többet számolnám, ha engem kérdezel, de egyébként is Neked kell számolni :)

nb · http://fersml.blog.hu 2013.10.21. 22:43:58

@Moonquake:
@veni_vidi_vici:

nem egyezik pontosan a véleményetek, ami remek alapot ad egy szakmai párbeszéd megkezdésére (ugye a szakmai párbeszédben, ha a másik hitelesíti, hogy kapott valami infót, akkor 5 pont)

Szóval, hogy kicsit mátrixos képzavarral éljek és csak az utat mutatom meg, programozni Nektek kell, illetve Mulder is megmondta, hogy a válasz a forrásban van :)

Lefordítva az érvelésetek az API-n alapszik, ez jó, ezt várjuk a tömegesen jó API programozótól, de ez itt ugye az elit képzés, ami konkétan annit tesz, hogy a válaszotok (vagy a szakmai diskurzus) alapuljon a forrásokon! Emlékezzetek, hogy prog1-ből kimondottan esti olvasgatásra ajánlottuk a JDK forrásait, mert amilyen a jó API program, ez is hasonló, annyire jól olvasható, hogy túléli az íróját, hiszen erre vannak eleve kitalálva a Java-típusú "homokozó" nyelvek.

Szóval mivel ez egy élő környezet, így pár kattintással ott a két lefutó kódcsipet, egyrészt:

public void write(String s, int off, int len) {
try {
synchronized (lock) {
ensureOpen();
out.write(s, off, len);
}
}
catch (InterruptedIOException x) {
Thread.currentThread().interrupt();
}
catch (IOException x) {
trouble = true;
}
}

másrészt:

private void write(String s) {
try {
synchronized (this) {
ensureOpen();
textOut.write(s);
textOut.flushBuffer();
charOut.flushBuffer();
if (autoFlush && (s.indexOf('\n') >= 0))
out.flush();
}
}
catch (InterruptedIOException x) {
Thread.currentThread().interrupt();
}
catch (IOException x) {
trouble = true;
}
}

Ugye, hogy más élmény, az API sosem olyan jól érthető, mint maga a forrás.

B.Norbi93 2013.10.22. 13:25:56

Akkor én is beadnám a két 5 pontos feladatot:
Futtatás hibásan és javítás:
imagerz.com/QE4UXktvAwMCUQpPFAVQ

Jconsole monitorozás:
imagerz.com/QE4UXktvAwMCUQpPFQVQ

veni_vidi_vici 2013.10.23. 17:02:30

lzw binfa, PrintStreamet használva:
imagerz.com/QE4UX0tvAwMCUQoYGQVQ

A tapasztalat az, hogy valóban az autoflush okozta a futásidő megnövekedését, nem a char -> byte konverzió (bár lehet kis mértékben az is közrejátszik)

Kassen 2013.11.04. 17:04:14

Kódolási konvenció:
Osztályok
Főnév, belső szavak első betűi nagyok. Egyszerű, kifejező, ne legyen rövidítés

5 pontos

VSanyi94 2013.11.04. 17:12:59

Kódrészlet:
int szo = (int) b;
for (int i = 0; i < 8; ++i)
{
// maszkolunk eddig..., most már simán írjuk az if fejébe a legmagasabb helyiértékű bit vizsgálatát
// csupa 0 lesz benne a végén pedig a vizsgált 0 vagy 1, az if megmondja melyik:
if ((int) (szo / Math.pow (2, 7 - i)) == 1)
{
// ha a vizsgált bit 1, akkor az '1' betűt nyomjuk az LZW fa objektumunkba
binFa.beolvas ('1');
szo -= Math.pow (2, 7 - i);
}
else
// különben meg a '0' betűt:
binFa.beolvas ('0');
}

Cvanger 2013.11.04. 18:43:37

Kérlek titeket, hogy igazoljátok, hogy a Sanyi kódjától:

int szo = 65;
for (int i = 0; i < 8; ++i)
{
if ((int) (szo / Math.pow (2, 7 - i)) == 1)
{
//binFa.beolvas ('1');
szo -= Math.pow (2, 7 - i);
}
//else
//binFa.beolvas ('0');
}

a Tanár Úr kódja:

for (int i = 0; i < 8; ++i)
{
if ((b[0] & 0x80) != 0)
{
//binFa.egyBitFeldolg ('1');
}
else
{
//binFa.egyBitFeldolg ('0');
}
b[0] <<= 1;
}

ennyivel
www.dropbox.com/s/7huufka7r56ws8i/Screenshot%20from%202013-11-04%2018%3A36%3A21.png
gyorsabb. Ezzel meg is lesz a védésem. Köszi :D

VSanyi94 2013.11.04. 20:08:57

Nekem is körülbelül annyi jött ki:
kepfeltoltes.hu/view/131104/Sebess_g_www.kepfeltoltes.hu_.png

(10 pont)

A Humángenom program egyébként, ha valakinek szüksége lenne rá:

pastebin.com/s299YUUk

Moonquake · https://soundcloud.com/alice-margatroid-1/nhato-moonquake?fb_action_ids=602478393129432&fb_action_ty 2013.11.04. 21:19:08

Nekem is kb. annyi lett.
A minimális eltérés szerintem abból fakad, hogy a Core2Duo processzorom nem veszi fel a versenyt a Ti i5-öseitekkel.

kepfeltoltes.hu/131104/Screenshot_from_2013-11-04_21_11_43_www.kepfeltoltes.hu_.png

(10 pont)

Gratulálok a védéshez! :)

Cvanger 2013.11.05. 10:40:39

@Moonquake: Köszi. Az eltérés inkább azért van, mert más architektúrán, (esetleg más fordító, meg ki tudja még mi más) az egyes kódok más sebességgel futnak.
@VSanyi94: Köszi

+10 pont

veni_vidi_vici 2013.11.06. 01:25:28

BBP-s sebességteszt (5 + 25 pont)
A méréseket egy Ubuntu 12.04.3 LTS operációs rendszerrel felszerelt 3.2.0-55.85 verziójú kernellel ellátott Intel Core i3-2350M processzoros 4GB memóriával rendelkező gépen gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 verziójú gcc, gij (GNU libgcj) version 4.6.3 és java version "1.6.0_27" OpenJDK-s Java, Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-1ubuntu2.2) verziójú Mono(c#), valamint Python 2.7.3 verziójú Python mellett végeztem el.

screenshotok:
10^6 imagerz.com/QE4VXUtvAwMCXl8bFQVQ
10^7 imagerz.com/QE4VXUtvAwMCXl8bFAVQ
10^8 imagerz.com/QE4VXUtvAwMCXl8bFwVQ

python source:
pastebin.com/m8UsEd15

eredmények táblázatba foglalva:
imagerz.com/QE4VXUtvAwMCXl8bFgVQ

B.Norbi93 2013.11.09. 14:53:24

BBP mérések:

OS: Linux Mint 15
kernel: 3.9.9
CPU: Intel Core i3-3120M, 2.5 GHz
RAM: 4 GB
GCC, GCJ: 4.7.3
Java: 1.7.0_40 (OpenJDK)

10^6:
kepfeltoltes.hu/131109/Screenshot_from_2013-11-09_14_14_17_www.kepfeltoltes.hu_.png

10^7:
kepfeltoltes.hu/131109/Screenshot_from_2013-11-09_14_26_29_www.kepfeltoltes.hu_.png

Python:
pastebin.com/JhktREVk

(5 + 25 pont)

Püsök Levente 2013.11.11. 00:44:40

BBp mérések:

Linux Mint 14 LTS x64, kernel verzió: 3.5.0-17
Intel Core i7-3610QM (ivy bridge) 2,30GHz x4, 8GB RAM
GCC: 4.7.2
GCJ: 4.7.2
java: 1.7.0_25 OpenJDK Runtime Environment (IcedTea 2.3.10)

Érdekességképpen hozzácsaptam a gcc -O3 kapcsolójával generált full optimalizált verzió eredményeit is.

10^6: imagerz.com/QE4VCUtvAwMCXlJJEQVQ

10^7: imagerz.com/QE4VCUtvAwMCXlJJEAVQ

10^8: imagerz.com/QE4VCUtvAwMCXlJJEwVQ

Gula 2013.11.11. 18:35:37

Védésem:
Az 5. eredmény az átlag.
Az első széria beágyazva, a második anélkül.
kepfeltoltes.hu/131111/Screenshot_from_2013-11-11_18_08_38_www.kepfeltoltes.hu_.png

Moonquake · https://soundcloud.com/alice-margatroid-1/nhato-moonquake?fb_action_ids=602478393129432&fb_action_ty 2013.11.11. 18:54:16

Védésem:
A "First" az eredeti - beágyazott csomópontú verzió.
Méréseim szerint a külön csomóponttal gyorsabb.
(Véletlenül rosszul jelöltem az időt, azok nem szekundumok)

kepfeltoltes.hu/131111/Screenshot_from_2013-11-11_18_14_28_www.kepfeltoltes.hu_.png

VSanyi94 2013.11.11. 20:33:24

Védés:

Az első az eredeti program

kepfeltoltes.hu/view/131111/Iv_d_s_www.kepfeltoltes.hu_.png

A mérés szerint a külön csomóponttal gyorsabb.

Püsök Levente 2013.11.11. 20:41:32

Védésem:

Eredeti forrás, beágyazott Csomopont osztállyal:
imagerz.com/QE4VCUtvAwMCXlIYFQVQ

Csomopont külön szedve:
imagerz.com/QE4VCUtvAwMCXlIYEgVQ

Az eredmény: a beágyazott verzió egy kicsivel lassabb.

A.Betti 2013.11.11. 21:48:53

Védésem:

Az első az eredeti program.

kepfeltoltes.hu/131111/vedes_www.kepfeltoltes.hu_.png

Mérésem szerint külön csomóponttal gyorsabb.

szelepsapka 2013.11.11. 22:39:00

Itt az én védésem:

kepfeltoltes.hu/view/131111/56469187vedes_www.kepfeltoltes.hu_.png

Az én méréres alapján közelít egymáshoz a két verzió ideje, tehát bizonyos tűréshatáron belül azt mondom, hogy egyforma.

PHP_Barbar 2013.11.11. 22:55:45

Védés:

A baloldali az eredeti LZWBinFa. A jobb oldali pedig a külön vett csomópontos program.

Az utóbbi mérés szerint a jobb oldali, azaz a külön szedett csomópontos példa gyorsabban lefutott, mint az eredeti.
5-ször futtattam le egy ciklussal, és ki is átlagoltam az eredményt, hogy ténylegesen látható legyen.

hegedustibor.com/images/vedes_2.png

Viszont többszöri lefuttatás alapján mindig változtak az eredmények. Ez gondolom következménye annak, hogy van háttérben futó néhány program, ami befolyásolhatja a tiszta eredményt.
Például a legérdekesebb, hogy szinte teljesen megegyező eredményt kaptam az egyik lefuttatásnál.

hegedustibor.com/images/vedes_1.png

Ahol a különvett csomópontos program 389,4-es átlagot kapott, míg az eredeti 389-et.

Többszöri mérés alapján a külön vett programkód nyerte a sebességtesztet, tehát ez a hihetőbb verzió, hogy az gyorsabb, mivel bizonyított. De fenntartom azt a lehetőséget, hogy nem tesz különbséget a kettő között, mivel az időbeni ingadozások leginkább a háttérfolyamatok eredménye. Ha nem így lenne, akkor minden egyes tesztnél azonos eredményt kellene kapnunk. A kód kettéválasztása csupán a programozók életét könnyíti meg a kód átláthatóságával és szépségével.

Disassemblinator777 2013.11.11. 23:39:07

Védés:

Mindkét módszerrel teszteltem a programkód lefuttatását: eredeti kóddal (LZWBinFa.java)beágyazott Csomopont osztállyal és a Csomopont osztályt külön kiszedve.
Miután for ciklus segitségével lefuttattam mindkettőt 5-ször,aztán átlagoltam az eredményeket,a következő eredményeket kaptam,:
A kép felső részén látható a Csomopont osztály kiszedve az eredeti kódból, alsó részen persze az eredeti kód lefuttatva a humán genomra.
Az eltérés valójában tényleg nem nagy, az én esetemben 3 sec.
A beágyazás nélküli progi gyorsabb eredményt mutat mint a beágyazott.
p1.picsto.re/Screenshot_from_2013-11-11_17:13:58.png

veni_vidi_vici 2013.11.13. 19:54:10

hibássan implementált RSA-val titkosított szöveg feltörve, 30 pont.
A megoldás menetét és a feltört szöveget e-mailben elküldtem Tanár úrnak.

nb · http://fersml.blog.hu 2013.11.13. 20:06:39

@veni_vidi_vici: +20 pont az elsőségért, azaz az úttörő munkáért. Ha bárki kér szakmai helpet, akkor ne felejtse el az 5 pontokat visszaigazolni, ha segített a help.

Egyébként gratulálok!

ICsaba 2013.11.18. 20:52:57

vedes:
garbage collection -nak (GC) 2 generacioja van, young, es old. a young tartalmazza az eden space-t
es ketto survivor space-t. A JVM kezdetben minden objektumot az eden
space-be rak, a legtobb itt is hal meg. fenn marado objektumok a
survivor spacek egyikebe kerulnek. Azok az objektumok amelyek eleg sokaig elnek
a "kinevezett" old generation spacebe kerulnek.

a harom zold sav: eden space, survivor space, old generation.
ertekuk: space-ek maximum hasznalhato memoriajanak hany szazaleka van hasznalatban eppen.

gyzsolt 2013.11.18. 23:59:07

védés:
Kiegészíteném még az előttem szólót annyival hogy mikor a young generation megtelik akkor egy minor "szemét"gyüjtés indul el ami viszonylag gyors mivel young generation töredéke a telje felhasznált memoriának és arra van optimalizálva hogy kevés túlélők száma.
Aki túlélte az átkerül a tenured generacioba(amit a 3. zöld oszlop jelöl) és amikor ez megtelik akkor indul el egy teljes(major) szemétgyűjtés ami viszont már lassabb.

RunOfTheMill 2013.11.19. 00:00:21

Csatlakozom az előttem szólóhoz és hozzáfűzném még, hogy az Eden-ben a leggyakoribb a GC, az Old-ban pedig a legritkább abból a megfontolásból, hogy ha már régóta használjuk azt a példányt, akkor talán ez után is szükség lesz rá, így elég lehet ezek között ritkábban gyűjteni a szemetet. Egyébbként a program futása közben is szépen látszik a sávokon, ahogy pakolja az objektumokat egyik kategóriából a másikba.

Kassen 2013.11.19. 01:51:23

www.dropbox.com/s/z79r7pfhqam4mqx/binfa1vs2.jpg

Itt az eredményeken látszik, hogy a 32 bites rendszeremen igen jelentős különbséggel a külső osztályos vezeti a gyorsasági versenyt. Hamarosan küldöm a heap-memóriás zöld csíkok kifejtése is.

Moonquake · https://soundcloud.com/alice-margatroid-1/nhato-moonquake?fb_action_ids=602478393129432&fb_action_ty 2013.11.19. 04:20:53

Védésemhez:
Tovább fejtegetjük a beágyazott és a külön csomópontos binfa progikat.
Véleményem szerint a külön csomópontos verzió gyorsabb, és kevesebb "szemetet" termel, kímélve ezzel a memória-használatunkat.

A heap memóriában zajlik ugye a szemétgyűjtés (GC), ami azt jelenti, hogy amelyik objektumra már nincs referencia azt törli onnan, memóriát szabadítva fel ezzel.

Jconsole-on a memória fülön, heap blokkban balról jobbra az oszlopok és jelentésük:

Eden Space:
A memória-terület,amiben a legtöbb objektum elhelyezkedik,amíg el nem öregszik (=át nem helyeződik a másik generációba)
vagy nem törli a GC.

Survivor Space vagy Young Generation: (GC/ PS Scavenge takarítja)
A memória-terület,amiben azok az objektumok vannak, amik túlélték a GC (szemétgyűjtő) munkáját.

Tenured Space vagy Old Generation: (GC/ PS MarkSweep takarítja)
A memória terület,amiben azok az objektumok vannak, amik már eltöltöttek némi időt a Survivor Space-ben.

Képeim:
Eredeti verzió:
kepfeltoltes.hu/131119/eeeee_www.kepfeltoltes.hu_.png

Külön csomópontos verzió:
kepfeltoltes.hu/131119/kkkk_www.kepfeltoltes.hu_.png

Képeimen látszik, hogy abban a pillanatban, hogy lefutottak a programjaink, az eredeti beágyazott csomópontos verzió mintegy 130 MB-al több ramot használ (lsd: Used utáni szám), tehát a szemétgyűjtés hatásosabban zajlik le a külön csomópontos verzióban.
Ennek oka ha jól értelmezem a GC működését az, hogy a külön csomópont hamarabb törlődik, mert hamarabb szűnik meg a rá mutató referencia.

Leírás a GC-ről, a Jconsole-ról, a Heap részeiről, stb:
docs.oracle.com/javase/1.5.0/docs/guide/management/jconsole.html

A.Betti 2013.11.19. 12:55:09

Védésemhez:

Szerintem is a külön csomópontos verzió gyorsabb, és kevesebb memóriát használ, mikor végez.

képek:
eredeti:
kepfeltoltes.hu/131119/Screenshot_from_2013-11-18_16_50_36_www.kepfeltoltes.hu_.png

külön csomóponttal:
kepfeltoltes.hu/131119/vedes2a_www.kepfeltoltes.hu_.png

Nálam a PS Old Gen telítettsége alig mutat eltérést a két verzió között, a fiatal generáció pedig egyértelműen jobban ki van takarítva a külön csomópontos verziónál.

Egyenletesebb eloszlást tapasztaltam a generációk között, mint az előző hozzászóló, ezt talán az magyarázza, hogy a gépemen 32 bites, de fizikai címkiterjesztést használó (PAE) ubuntu van.
(Más a memória címzési metódus)

Kassen 2013.11.19. 14:25:16

@Kassen: Védés:

A fenti kollégáktól eltérően az én 32 bites fedora 19 linuxomon a lényegi különbség nem a memóriahaszálatban van, hanem a futási időben. A külső osztályos sokkalta gyorsabb.
Memóriahasználatban az összes lefoglalt memória(committet) a külső osztályosnál kb 65 MB-al kisebb, amit én is a referenciákra tudnék visszavezetni.

További teszteket végzek a pontosabb eredményért, de eddig mindig a külső osztály viszi a prímet.

szelepsapka 2013.11.19. 23:22:03

Védéshez:

Belső csomóponttal: kepfeltoltes.hu/view/131119/belso2_www.kepfeltoltes.hu_.png

Külső csomóponttal: kepfeltoltes.hu/view/131119/kulso2_www.kepfeltoltes.hu_.png

Futási idő szempontjából nagyjából ugyan úgy teljesített mindkét verzió, azonban heap memory használat alapján mindenképp a külső csomópontos a nyertes, az én gépemen ~200 megás előnnyel. Amint a képeken is látszik a belső-s verziónál a szemétgyűjtés nem olyan hatékony az eden space részen, márpedig mint tudjuk először ide kerülnek be az objektumok, ezért teljesíthet sokkal kedvezőbben a külsős verzió mivel ott szinte nullán van ugyanez az érték, tehát az utóbbi verzióban jóval hatékonyabban zajlik a szemétgyűjtés.

veni_vidi_vici 2013.11.20. 20:48:24

C++11 lambda függvények (20 pont)

A lambda függvények (névtelen függvények) a C++11 legérdekesebb újításai közé tartoznak: tiszta, tömör szintaxissal váltják fel az eddig használt függvényobjektumokat és függvénypointereket.

imagerz.com/QE4SW0tvAwMCX1lMEQVQ
Ebben az egyszerű példaprogramban a container függvényben létrehozunk egy lambda függvényt, eltároljuk azt a myfunc változóban, majd visszaadjuk az értékét. Az auto kulcsszót használtuk, a fordító ugyanis képes meghatározni a lambda függvény típusát. A container függvény visszatérési értéke azonban már nem lehet auto, itt hívjuk segítségül az std névtér function nevű template osztályát, mellyel egyszerűen tárolhatjuk lambda függvényeinket. A main függvényben eltároljuk a container függvény visszatérési értékét egy változóba, majd (mivel az egy függvény) háromszor mehívjuk azt.

imagerz.com/QE4SW0tvAwMCX1lMEAVQ
A következő példaprogram az úgynevezett "closure" technikát mutatja be. A lambda függvényünk használja a hívó függvény egyik paraméterét. A main függvényt megvizsgálva könnyen levonhatjuk a következtetést, hogy a lamda függvényeinknek valamilyen módon "meg kell jegyezniük" az 50 és 60 értékeket.

Végezetül kijelenthető hogy a lambda függvények nagyon erős és rendkívül sokoldalúan használható elemei a nyelvnek, viszont körültekintéssel kell használnunk őket, ha nem akarunk fordítási hibát, vagy nem várt viselkedést kapni.

VSanyi94 2013.11.23. 15:31:10

Védéshez:

Nekem nincs nagy eltérés a heap memória használatban, futási időben is azonos. Ez valószínűleg az i5-ös processzoromnak köszönhető. Tehát az én gépemen a szabad tár memóriahasználata közel azonos, mindkettőnél körülbelül 600 Mega kerül felhasználásra.

kepfeltoltes.hu/view/131123/memory1_www.kepfeltoltes.hu_.png

kepfeltoltes.hu/view/131123/memory2_www.kepfeltoltes.hu_.png

A másik védési feladatra (chekstyle a (saját) LZWBinFa programra) kapott eredményem:

kepfeltoltes.hu/view/131123/checkstyle_saj_t_LZWre_www.kepfeltoltes.hu_.png

Püsök Levente 2013.11.23. 17:00:44

Titkosított szöveg feltörve, elküldtem az nbatfai@inf.unideb.hu címre az eredeti szöveget és forráskódokat, amibe megjegyzések formájában a gondolatmenetemet is megpróbáltam belesűríteni.

30 pont (ha még pontot ér a feladat)

Valamint +5 pont jár veni_vidi_vici -nek az útmutatásért, és ezúton is köszönöm neki a helpet.

Kassen 2013.11.25. 00:41:24

@Kassen:
Elvégeztem a tesztet egy egyetemi gépen is. Időben egyértelműen jobban teljesít, mint az én őskövület laptopom, viszont meglepő különbség, hogy a 64 bites egyetemi gépen jobban látszik a belső és külső osztály közti különbség a szemétgyűjtögetés közben. Memóriában is bő 200 Megával csökken a felhasznált memória a külső osztályban.

Az összehasonlítás mindkét gépen és minden teszten azt adta vissza, hogy a külső osztályos jobb memóriafoglalás és CPU terén is. Bár a két teszt eltér a heap memória maximális korlátjában, ugyanis az és gépemen csak 1 GB-ot tudtam adni a teszthez, míg a benti gépen lazán volt neki 2 GB, amit hozzávághattam. A tesztek "esélyegyenlősége" miatt próbáltam először az egyetemi gépen is 1 GB-ra korlátozni de az látható volt az eredeti belső osztályos BinFánál, hogy több memóriát igényel. (fel tudom tenni arról is az összehasonlítást, ha szükséges)

Saját:
www.dropbox.com/s/1m45zn7bbio4p9m/sebes%C3%A9teszt%20inspiron%201721%20max%20heap%201G.jpg

Egyetemi:
www.dropbox.com/s/ce9bm4na0wq610y/sebessegteszt%20egyetemi%20g%C3%A9p%20max%20heap%202G.jpg

VSanyi94 2013.12.01. 15:18:37

BBP mérés:

Javaban (5 pont) és Pythonban (25 pont):

kepfeltoltes.hu/view/131201/BBP_www.kepfeltoltes.hu_.png

Python forrás:
pastebin.com/E8WLFCfw

Összesen 30 pont

VSanyi94 2013.12.07. 19:03:07

Első cikk kielemzése:

goparallel.sourceforge.net/c11-lambda-functions-returns-calls

kepfeltoltes.hu/view/131207/Lambda1_www.kepfeltoltes.hu_.png

A container metódusban létrehozunk egy lambda függvényt, melyet a myfuncban tárolunk el. Visszatérési értéke auto, azaz a fordító meg fogja tudni határozni a metódus visszatérési értékét. A container visszaadja ezt a myfunct, ezt úgy tudjuk megoldani, h sablont (template) alkalmazunk. A main függvényben a somefuncban eltároljuk a myfunc-t és mivel ez egy lambda függvény, ezért meghívhatjuk.

kepfeltoltes.hu/view/131207/lambda2_www.kepfeltoltes.hu_.png

A következő példaprogram annyiban különbözik az előzőtől, hogy a myfunc használja a paraméterként megkapott számot (kiiratja). Ezt úgy tudjuk megtenni, hogy megadjuk a myfuncnak a q értéknek a referenciáját (Ezt azért kell megtenni, mert ha nem a referenciáját adnánk meg, akkor nem tudnánk a változó értékét módosítani. Bár ez jelen lambda függvényünk mellett nem érdekes dolog.)

A lambda függvények a C++11 újításai között található. Fordításuk a következő módon történik:

g++ -std=c++11 lambda.cpp -o lambda

Legnagyobb előnye szerintem az, hogy a fordító határozza meg hogy mi a lambda metódus visszatérési értéke.

+20 pont

Disassemblinator777 2013.12.14. 18:58:28

Kérhetnék tanár úrtól egy kis segítséget vagy valamilyen ötletet a 2. védéssel kapcsolatban, mert nem jön az ihlet, és igy hátha könyebb lenne. Meg ahogy gondolom nem csak én vagyok így vele ahogy beszélgettünk a csoportba és ahogy tanár úr is látja... (Ugye az 5 commitról lenne szó)

Disassemblinator777 2013.12.14. 21:21:35

Vagy valaki valamilyen ötletet felvetne segítségül???

nb · http://fersml.blog.hu 2013.12.14. 22:49:06

@Disassemblinator777: akkor ötletekek egyet:

- README a gyökérbe is, általános bemutatással
- a Construct/README-be az angolt előre és esetleg az API install miatti hibára is kitérni
- a cikkbe megadott hivatkozott cikkeket megnézni, rövid kivonatot készíteni belőlük (ami jöhet pl. a levlistára) kommitolni a cikkbe lehet hivatkozott 1-2 mondatot a megvizsgált cikkek eredményéről (ez annak lehet izgalmas, aki társszerző akar lenni)
- a program kapcsán egy külön ágba kidolgozni protobuf-ban a gráfok reprezentációját
- fel a Puzzle-t benne a Helló Világos, Mavenes órai szervlet YANonymousra átírt változata (pl. a szerver egyelőre POST-al átveszi a klienstől a protobuf-os gráfot, ha GET-el hívják, akkor meg a bongészőbe kiküldi a globális gráfot
- van már fent pár ág, kellene őket tesztelni, s lehetne BUG-reportot nyomni ide: sourceforge.net/p/yanonymous/tickets/
(1 BUG jelzést szeintem elfogadhatunk egy kommitnak is)
- s ha már teszteltek, nyilván jön egy csomó ötlet, amit lehet forrásba is kommitolni

elsőre ennyi

nb · http://fersml.blog.hu 2013.12.14. 23:55:06

@Disassemblinator777: példaképpen fel is nyomtam a Puzzle-t és "Helló Világ" szervlettel, itt is lehet azonnal a fájlokban dolgozni, pl.:

- copyright-ok a fájlok eleje (xml-be, java-ba)
- README bele
- a pom.xml-be, hogy nyomjon mvn site-re pár riportot, ehhez kiindulhattok ebből:
www.inf.unideb.hu/~nbatfai/PeldaServlet-0.0.1-project.zip
mert kell pom.xml módosítás, meg a megfelelő könyvtárszerkezet a riportokhoz stb. (de inkább már a COnstruct riportolása mintájára dolgozzatok)

(nyilván GSM-es, SIM kártyás telefonon ne teszteljétek a szerver oldalt, majd a laboron adok telefonokat, tabletet és wifin, bár még nincs is mit tesztelni azért :)
süti beállítások módosítása