ACUEBO

A repository URL-je hiányzik.

D9RKIN

A repository nem látszik, nem érhető el.

F5HV4G

A leírás így egy kicsit még vázlatos. Konkretizálni kellene, hogy a felhasználó hogyan fogja tudni majd megadni az említett adatokat.
Részletesebben ki kellene térni arra, hogy a mátrixok szorzásának párhuzamosítását hogyan tervezi megoldani.
A BFS gráffal kapcsolatban is szükséges lenne további részletezésre, esetleg hivatkozásokra a módszerrel kapcsolatban elérhető további leírásokra.
A repository alapján nem látszik, hogy félév közben milyen munkálatokat végzett a tárgy kapcsán.

F9Y7TW

A repository nem látszik, nem érhető el.

FJJIO1

Nincs feltöltve semmilyen kód a repository-ba.

FZ1AKR

A repository-ba fel kellene tölteni a gyakorlatokon elkészített feladatokat is. (Aktuálisan csak egy február 13-adikai látható. Feltételezem, hogy azon kívül is voltak még munkálatok.)
A .gitignore fájl használata mindenképpen dícsérendő.

FZIE3D

A teljes repository-hoz tetszetős lenne egy README.md fájlt készíteni.
A gyakorlatokkal kapcsolatos jegyzékek nevei nem egészen egységesek.
Jobban figyelni kellene az általános kódolási konvenciók betartására. (Ahogy láttam főként az első pár feladat megoldásánál jelentkezett a probléma. Utána inkább csak felesleges üres sorok voltak néhol.)
A forrásfájloknak a neve jobb lenne, hogy ha jobban utalna arra, hogy mi található a fájlban.
A scanf függvény használata nem hiba, de érdemes lenne áttérni a parancssori argumentumok vagy a konfigurációs fájlok használatára.
A függvényekhez (esetleg fordítási egységekhez, struktúra definíciókhoz, globális változókhoz, konstansokhoz) tartozó dokumentációt elegánsabb angolul készíteni.

Beadandók/C/OpenMP

MarkDown formázással tetszetősebbé tehető a leírás.
Érdemes lenne Makefile-t és header fájlokat is használni.
A mérések eredményei is kerülhetnek közvetlenül a feladat specifikációját követően a README fájlba.
A dokumentációs kommentek a függvények előtt kiindulásnak teljesen jók. Érdemes kiegészíteni a paraméterekre vonatkozó leírással.
A Miller név a függvénynek nem szerencsés. Érdemes igével kezdeni úgy általában a függvényneveket, és konvenció szerint kisbetűvel. Hogy ha a visszatérési érték logikai érték, akkor lehet bool típussal jelölni. (Korábbi szabványok szerint include-olni kell az stdbool.h fejlécet hozzá.)

Beadandók/C/Pthread

Hasonlóak ezzel kapcsolatban is az észrevételeim: kommentezés, dokumentáció, scanf, fájlszervezés, mérések.

Beadandók/Java

A kiírás alapján azt nem látom egészen, hogy hogy tudja a program a bemenetet úgy hatékonyan mondatokra vágni, hogy a keresett szavakat véletlenül se vágja közben félbe. Ezt érdemes lehet részletezni.
Az sztenderd bemenet használatát ilyen formában itt sem javaslom.
Apróbb formázási hibák ebben is előfordulnak.
Ahhoz, hogy megfelelő pontosságú mérést lehessen végezni, jóval nagyobb bemenetekre lenne szükség. A FileReader.zip használata olyan szempontból jó, hogy az adatokat így kisebb tárigénnyel tette (volna) föl, de a lefordított class fájlokra nincsen szükség. Helyette a build folyamatot érdemes leírni. (A "volna" arra vonatkozik, hogy ilyen méretű szövegnél nagyobb a ZIP fájl fejléce, mint amit a tömörítéssel nyerni lehet.)

Mérései eredmények.pdf

A szálkezelés kapcsán az első 2 ábrán érdemes azt megnézni, hogy mennyi az a szál szám, amitől kezdve elkezd romlani a futási idő a plusz adminisztrációs költség miatt.
A méréseket jobb lenne úgy elvégezni, hogy a futási idő nagyságrendileg elérje a másodpercet. Az OpenMP esetében az 50 ms alatti mérések túl kicsinek tűnnek. (Apróság, de nem lett átírva a "Diagramcím".)
A Java-s programhoz a görbe így ránézésre nagyon jó, mert azt sejteti, hogy a szálak számának függvényében szépen csökken a futási idő. Itt is ami gyanús, hogy ekkora méretű bemenetre így még nem lehet valós eredményt mérni.
A méréseket érdemes lenne bemenet-számítási idő függvényként is lemérni.
A grafikonok értelmezéséhez, és úgy általában a kapott eredmények bemutatásához írni kellene még szöveges összesítést.

G6HV2W

A README.md (és ezzel együtt a feladatkiírás) hiányzik.
A forrásfájloknak a neve jobb lenne, hogy ha jobban utalna arra, hogy mi található a fájlban.
A repository gyakorlatok jegyzékében lévő fájlok alapján úgy látszik, hogy a munkálatok március 12-ig rendben zajlottak.

GDVK5H

A feladat leírásának már bele kellett volna kerülnie a repository-ba.
A helloworld.c-t nem feltétlenül kellene a repository gyökerében hagyni.
A forrásfájloknak a neve jobb lenne, hogy ha jobban utalna arra, hogy mi található a fájlban.
Jobban figyelni kellene az általános kódolási konvenciók betartására.
Az .exe fájlokat nem kellene feltölteni.
A Makefile-ok használatára úgy általában át kellene térni.

GKIU70

A repository gyökerébe közvetlenül is célszerű megadni egy README.md fájlt.
A gyakorlatok jegyzék tartalma alapján szépen látszik, hogy min és milyen formában dolgozott.
A beadandó kapcsán mindenképpen külön jegyzékeket kellene használni.
A C programok esetében jó lenne Makefile-t használni majd.
A header fájlok használata szintén javallott.
Meg kellene próbálni dinamikusan lefoglalni és felszabadítani a memóriát.
A scanf függvény használata nem hiba, de érdemes lenne áttérni a parancssori argumentumok vagy a konfigurációs fájlok használatára.
A mérésekkel kapcsolatos fájlokat szintén külön jegyzékbe lenne jó tenni.
A beadando/main.c fájlban a choice az inkább egy felsorolás típus lenne, ahogy látom.
A grafikonok.pdf-ben látszik, hogy a szálak számának növelésével alapvetően csökken a futási idő. Ez viszont csak egy pontig van így, amit érdekes lehet lemérni.
A méréseket módszeresen jobb lenne elvégezni, úgy értve, hogy az összeadás, szorzás, minimumkeresés esetében is végigmenni különböző méretű mátrixokon, és az azokkal kapott futási időket ábrázolni.
Tetszetős lenne olyan grafikon is, ahol a szekvenciális és a párhuzamos futási idő kerül összehasonlításra.

H5BEU4

A harmadfokú egyenlet ábrázolásánál érdemes a vízszintes tengelyt széthúzni, mert az ábra nagy része így feleslegesen foglalja a helyet.
A mérésekhez tetszetősebb lenne 3 szál felé is menni.
A pontosabb mérésekhez a futási időt érdemes másodperces nagyságrendűre hozni.
A Subtitution-Cipher-rel kapcsolatban további részletezés kellene, hogy pontosan milyen módszerről van szó, mit csinált párhuzamosítás kapcsán.
Konkretizálni kellene, hogy az egyes módszerekkel összességében milyen szintű gyorsítást sikerült elérni.
Az "Add files via upload" jellegű commit megjegyzéseket érdemes kerülni.
A fájlok és jegyzékek elnevezése túlságosan változatos. Érdemes lenne következetesebben használni.
A lefordított .exe fájlokat nem kellene feltölteni. (Úgy általában semmilyen átmeneti fájlra nem lenne szükség.)
Jobban figyelni kellene az általános kódolási konvenciók betartására.
A C programkódok szervezéséhez header fájlokat is célszerű lenne használni.

HK74CE

A helloworld.c fájlt nem kellene a repository gyökerében hagyni.
Az Feladatok jegyzékbe a fájlok egyszerre lettek feltöltve. Ez nem probléma, de érdemes lett volna folyamatában, az éppen elkészült részeket külön-külön feltölteni.
A scanf függvény használata nem hiba, de érdemes lenne áttérni a parancssori argumentumok vagy a konfigurációs fájlok használatára.
A README.md-ben érdemes MarkDown formázást használni.
A tökéletes számokhoz érdemes lehet egy hivatkozást is tenni (akár csak a Wikipedia oldalra).
A feladatok leírása alapvetően szép részletes. A 2. beadandóval kapcsolatban annyi észrevétel, hogy a pi közelítéséhez hasonló szimulációs alkalmazás a példaprogramok között is elérhető. Hogy ha ezzel szeretne foglalkozni, az nem kizáró tényező, de érdemes összemérni a saját és a példában szereplő módszer hatékonyságát.
A 3. feladatrész leírása hiányzik.

I5XJTC

A README.md fájlt rendbe kellene szedni. Az elején van egy felesleges rész, és úgy általában lehetne formázni.
A feladat érdekesen hangzik, de azt nem egészen látom, hogy mi jelentené a számításigényes feladatot benne.
Azt szintén konkretizálni kellene, hogy a Pthread, OpenMP és az egyéb technológia használata hogyan jelenne majd meg benne.
A repository-ban úgy általában át kellene gondolni a fájlok elnevezését, jegyzékekbe szervezését. Jó lenne, hogy ha elkülönülne a programkód, bemenetként használt adat, kimenet, a dokumentációhoz kapcsolódó részek.
A threadtomb.c fájlnak nem kellene a repository gyökerében lennie.

IY5AM2

A feladatokhoz tartozó leírás szép, részletes.
A 4k méretű képet esetleg érdemes lehet közvetlenül, felbontás formájában is megadni.
A méréseknél az időmegtakarítás/időkülönbség is egy érdekes érték, de tetszetős lenne a gyorsítás mértékét megadni.

beadando1

A forrásfájlokat érdemes lenne külön jegyzékekbe rendezni.
Makefile-t is célszerű lenne használni.
A lefordított futtatható állományt nem szükséges feltölteni.

beadando2

Ennek a projektnek az elrendezése már lényegesen jobb. Esetleg a mérésekkel kapcsolatos fájlokat érdemes valahogy (például egy jegyzékben) külön kezelni.
A futási idővel kapcsolatos grafikont képernyőképmentés helyett külön fájlba lenne jobb menteni. (A plt.show helyett lehet plt.savefig-et használni erre.)
A Num.c-ben a 10000-es érték mágikus konstansnak tűnik.

beadando3

Érdemes lenne jobban, OOP szemlélet szerint szétbontani a programot.
A class fájlok feltöltése nem szükséges. (Hogy ha külön build-et szeretne közreadni, azt .jar fájlok formájában szokták, és jobb esetben nem közvetlenül a forrásfájlok között.)
Néhány eredményképet tetszetős lenne feltölteni, mint kapott kimenetet.
A bemenetméret függvényében lenne érdemes vizsgálni a futási időt, hogy különböző számú szál használata mellett hogyan változott.

Összességében kifejezetten tetszenek a látottak.

JW8DEC

A README.md így nem elég specifikus és nem elég részletes. Részletezni lehetne például, hogy milyen párhuzamosítási módszert szeretne használni hozzá, és hogy a méréseket hogyan tervezi lemérni.
A mérések eredményei (táblázatokkal, grafikonokkal együtt) szintén kerülhet majd ebbe a fájlba.
A gyakorlatokhoz tartozó fájlokat érdemes lenne külön jegyzékbe szervezni.

M4ADVQ

Hiányzik a feladat leírása. A sablon README.md fájlt szerkeszteni kellene.
A beadandóhoz a leírás így túlságosan szűkszavú. Részletezni kellene, hogy pontosan hogy érti a Sobel architektúra használatát. (Feltételezem, hogy 3x3-mas lineáris, konvolúciós szűrőben gondolkozik, de ezt konkretizálni kellene.)
Szintén konkretizálni kellene a képformátumot, a mérésekkel kapcsolatos terveket.
A leírásból nem derül ki, hogy mi lenne a harmadik feladatrész.

M8TNTH

A magyar és angol nyelv használatát érdemes lenne valahogy egységesíteni. Lehetnek az .md fájlokban a leírások magyarul vagy angolul is, de jobb, hogy ha mindegyiknél ugyanúgy szerepelnek.
A gyakorlatoknál az .exe fájlokat nem lett volna muszáj feltölteni.
Az "Add files via upload" megjegyzéssel ellátott commit-okat kerülni kellene.

beadandók

A feladatok leírása így szépen formázott, kiindulásnak mindenképpen jó.
Az eredmények kiíratásánál ilyenkor valamilyen kód jellegű környezetet szoktak használni (MarkDown-ban a `` jelöléssel, mint kódblokkal).
Az eredményeket legalábbis táblázatos, de inkább grafikon formájában lenne jobb megjeleníteni.
Az adatok bekérése elegánsabb, hogy ha parancssori argumentumokon keresztül történik.
A szekvenciális és a párhuzamos futási időt érdemes lenne majd összehasonlítani.
A szekvenciális és a párhuzamos komplexitást is lehetne vizsgálni.

javathreads

A class fájlokat nem szükséges feltölteni. Helyette érdemes azt leírni, hogy hogyan build-elhető és futtatható az alkalmazás.
A problémaméret megadása itt is tetszetősebb lenne, hogy ha parancssori argumentumokon keresztül történne.

openmp

A mérési eredmények kiíratás történhet egyszerű CSV fájlokba is.
Érdemes összevetni a közelítéssel kapott sorfejtés értéket és a math.h-val kapott eredményt pontosság szempontjából.
A taylorS.h fájlban érdemes dokumentálni a függvényeket, és azok paraméterezését.

pthread

Hasonlóképpen dokumentálandó a matrixMult.h is.
A header fájlban lévő globális változókat célszerű kerülni.
A mátrixokhoz elegendő lett volna int* típust használni int** helyett. A memória lefoglalását és felszabadítását is szépen megoldotta így, töredezett memória esetén a kisebb allokálási egységek lehetnek ugyan előnyösek, de általában egy egy dimenziós tömb, és hozzá némi indexszámítás szokta az egyszerűbb megoldást jelenteni.

MX6WLR

A repository nem látszik, nem érhető el.

NORS38

A repository nem látszik, nem érhető el.

OG17WD

Érdemes lenne jegyzékeket használni a repository-ban lévő fájlok szervezéséhez.
A commit-oknál a megjegyzések lehetnének informatívabbak, leírás jellegűek.
Az .exe fájlokat nem kellene feltölteni a repository-ba.
A README.md fájlt tetszetősebb MarkDown formázással ellátni.
Az MPI-vel kapcsolatban további részletezés lenne szükséges, mivel ott nem csak egy gép, hanem elvileg több gép is lehet.
A C#-os rész kapcsán a leírás alapján nem igazán látszik, hogy mi jelentené majd a lényegi számítási problémát.

P2MZHY

Külön dícsérendő, hogy a leírást angolul adta meg. Érdemes viszont MarkDown formázással ellátni, illetve részletezni, hogy pontosan mit is szeretne majd csinálni.
A base.c állománynak nem kellene a projekt gyökerében lennie.
A gyakorlatokon elkészített feladatok alapján jobban figyelni kellene az általános kódolási konvenciók betartására.

P4QKJP

A projekt gyökerébe is érdemes lenne beletenni egy README.md fájlt.
A mérési eredményeket táblázatként lehetne formázni, de grafikonként is tetszetős lenne ábrázolni.
A feladatok leírása így még nem elég részletesen. Le kellene írni, hogy milyen párhuzamosítási módszert használ.
A méréseket követően a kapott eredményeket szöveges formában is értékelni kellene.
A Python-os résznél teljes egészében hiányzik, hogy mit szeretne csinálni.
A header fájlokban látszik, hogy törekedett arra, hogy dokumentálja az egyes függvényeket. Érdemes lenne a paraméterezésre is kitérni.
A measurements.png nagyon nem tűnik indokoltnak. Hogy ha szöveges a kimenete a programnak, akkor azt valamilyen szöveges formátumba célszerű menteni, majd valahogy abból egy tetszetősen közreadható formátumot (például táblázatot, grafikont) készíteni.

QCQJA0

A feladatleírás így kiindulásnak jó, de részletezni kellene benne, hogy a párhuzamosításhoz milyen algoritmust, módszert tervez használni.
Az említett módszerekhez (Dijkstra algoritmus, Gauss-Seidel egyenletmegoldó) érdemes lehet esetleg linkeket is megadnia.
A leírásba azt is érdemes lehet beletennie, hogy a repository-n belül majd mi hol lesz megtalálható.

R8H3FT

A README.md-ben a leírást mindenképpen célszerű lesz formázni, és további részletezésekkel kiegészíteni.
Az LU felbontáshoz érdemes beletenni egy linket. (Az alapvető módszert nem célszerű itt ennél jobban részletezni.)
A párhuzamosításhoz használandó módszerre jobban ki kellene térni, tehát hogy hogyan tervezi megoldani a párhuzamosítást.
A leírásban nem esik arról szó, hogy mi lenne majd a harmadik feladatrész.
A C programokhoz készíteni kellene majd Makefile-t, külön jegyzékbe lenne jó, hogy ha kerülnének a .c és a .h fájlok.
A kódközi kommenteket érdemes minimalizálni, vagy hogy ha szerepel is benne, akkor inkább angolul megfogalmazni.
A commit-okhoz tartozó megjegyzéseket tetszetősebb lenne elegánsabban megfogalmazni.

RBSFOP

A README.md-ben lévő leírás így még elég törmelékes.
A gyakorlatokhoz tartozó feladatokat látszik, hogy módszeresen elkészítette és szépen rendszerezte.
Hogy ha "Homework"-öt írt a külön feladatoknál, akkor a féléves feladatokhoz használhatja például az "Assignment" vagy a "Project" nevet is.

Beadandó 1

A header fájlban a függvényekhez célszerű dokumentációs megjegyzéseket írni.
A main függvény így túlságosan hosszúnak tűnik.
A scanf függvény használata nem hiba, de érdemes lenne áttérni a parancssori argumentumok vagy a konfigurációs fájlok használatára.
Mivel több mérést célszerű végezni, ezért a különböző méretű bemenetekhez azt automatikusan lehet jobb megtenni, majd az eredményeket egy szövegfájlba (például CSV formátumban) lementeni. Ezt lehet aztán táblázatos és/vagy grafikon formájában a dokumentáció részeként közreadni.

S4AP5X

Az Exercises jegyzék alapján látszik, hogy a gyakorlatokhoz tartozó feladatokat szépen elkészítette, és rendszerezett formában feltette.
A README.md-ben a feladatok leírása így túlságosan vázlatos. Jobban ki kellene térni arra, hogy mit és milyen formában szeretne kiszámoltatni, hogyan párhuzamosítaná azt, és hogyan tervezi hozzá a méréseket.

S90NXK

Hiányzik a feladat leírása. A sablon README.md fájlt szerkeszteni kellene. A Beadandó/README.md-ben ugyan van egy mondat, de az közel sem olyan specifikus, mint kellene, hogy legyen. Részletesebben le kellene írni, hogy mit és hogyan szeretne majd csinálni.
A félév közben elkészített munkálatai nem látszódnak a repository-ban.

TJQ86A

A feladathoz a leírás így még nem elég specifikus. Hogy ha jól értem, akkor az első feladat a véletlenszám generálás lenne. Ehhez a választott (vélhetően) pszeudóvéletlenszám generátort kellene részletezni. Az implementálandó számítást, algoritmust célszerű hivatkozni is.
A mátrix szorzásával kapcsolatban is konkrétabbnak kellene lenni, tehát le kellene írni, hogy milyen módon tervezi azt párhuzamosítani.
A Gauss-Jordan eliminációs feladatrésznél ennyiből szintén nem derül ki, hogy pontosan mit szeretne csinálni.
A Classwork jegyzék alapján nem látszik, hogy félév közben milyen feladatokat és hogyan oldott meg.
Egyedül április 21-én került eddig feltöltésre kód, és azoknál a commit-ok megjegyzései nem túl elegánsak.

UB4URC

A README.md fájl MarkDown-al formázni kellene. A leírás így nem elég specifikus, és nem elég részletes. Le kellene írni, hogy milyen formában tervezi megvalósítani a párhuzamosítást, annak a hatékonyságára vonatkozóan milyen méréseket tervez.
A második feladatrész lehet Open MPI-s is. A "például" helyett itt már konkrétan szerepelnie kellene, hogy mit fog majd a programmal kiszámoltatni.
A C#-os feladatrész aktuális leírásából egyáltalán nem látszik, hogy mit szeretne majd csinálni.
A repository-ban lévő anyagokat úgy általában jegyzékekbe kellene szervezni.

VTJ4ES

Érdemes lenne részletezni, hogy a mátrix szorzását majd hogyan tervezi megoldani párhuzamos algoritmus formájában.
A harmadik feladatrész lehet Open MPI, de azt érdemes a leírásban konkretizálni.
A mátrix méretének a megadását szintén konkretizálni kellene, értem ez alatt, hogy például parancssori argumentumokon keresztül hogyan történne.
A repository gyökerében lévő C fájlokat érdemes lenne valahova átszervezni.
A beadando jegyzékbe aljegyzékeket lenne célszerű létrehozni a feladatrészeknek. Makefile-t és a forrásfájloknak és a header fájloknak külön jegyzéket kellene használni.

VUB9YS

Az "A description goes here..." részt ki kellene cserélni a repository tartalmára vonatkozó leírásra.
A Project/README.md fájlban az elkészített feladatok leírása így szép részletes, de inkább csak a használati módra, nem pedig az alkalmazott módszerekre, algoritmusokra utal. Tetszetős lenne ezekről is írni benne.
A programkódjainak formázása egyáltalán nem rossz, de a felesleges üres sorokra érdemes lehet jobban figyelnie.
A Huffman kódfa készítésénél elég sok kódközi komment van. Ez időszakosan elő szokott fordulni másnál is, de érdemes arra törekedni, hogy a kódból közvetlenül látszódjon, hogy az mit csinál, és így ezekre ne legyen szükség.
A külön is használható adatszerkezeteket (például kódfa) érdemes lehet leválasztani a programban.
Az elkészített programja szép példája a fájlok domain alapú felbontásának. (Ezt azért is írom, hogy többségében részemről funkció szerint (tehát hogy .c vagy .h fájlról van-e szó) bontom fel a forráskódot, ezt szoktam másoknak is javasolni, de úgy is teljesen jó, ahogy Ön oldotta meg.)
Az elvégzett mérésekhez majd még táblázatok, grafikonok és hozzájuk tartozó szöveges leírások is kellenek.

WN6YVX

A README.md-ben a leírás így nem eléggé specifikus. Le kellene írni, hogy pontosan mit és hogy szeretne majd számolni, milyen képformátumot használni, hogyan oldaná meg a párhuzamosítást és hogy milyen méréseket tervez elvégezni ezzel kapcsolatban.
A 3. feladatrész témáját is célszerű lett volna már eldönteni.
A leírást majd MarkDown formázással lenne célszerű ellátni.
A repository gyökerében nem kellene benne hagyni a C forrásfájlokat. (Azokat külön jegyzékbe lenne tetszetős szervezni.)
A gyakorlatokhoz elkészített feladatokban indokolatlanul soknak érzem a magyar nyelvű kódközi megjegyzéseket. Inkább a függvényekhez kellene részletesebb leírást készíteni, és előnyösebb angol nyelven megtenni.
A fájlok elnevezését is érdemes lehet jobban átgondolni.
C programok esetében célszerű Makefile-t (vagy legalábbis valamilyen build folyamat leírót) használni, és a függvények deklarálását külön fejlécekbe szervezni.
A Szincsere/kiindulo jegyzékbe aljegyzékeket lenne célszerű létrehozni. El kellene különülnie a programkódnak, a bemeneti adatoknak és a mérésekkel kapott eredményeknek.

WZZTLL

A repository gyökerébe is érdemes lenne megadni egy README.md fájlt, hogy lehessen tudni, hogy összességében mit tartalmaz.
A feladat specifikálásához a beadando/README.md-ben lévő egy mondat jellegű leírás nyilván nem elegendő. Részletezni kellene, hogy pontosan mit és hogyan szeretne csinálni, milyen algoritmusok használatában gondolkozik, és hogy hogyan tervezi majd mérésekkel vizsgálni a párhuzamosítás hatását, hatékonyságát.
A test.c állományt ki kellene venni a repository gyökeréből.
A commit-okhoz tartozó megjegyzéseknek elegánsabbaknak, informatívabbaknak kellene lenniük.

ZY5P7F

A repository nem látszik, nem érhető el.