- Xiaomi AX3600 WiFi 6 AIoT Router
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Az iPadOS-re írt appokra is díjat vet ki az Apple
- Letartóztatták a bitcoin-Jézust
- Hálózatokról alaposan
- ASUS routerek
- Asustor NAS
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Milyen program, ami...?
Új hozzászólás Aktív témák
-
dezz
nagyúr
Nos, én nem vagyok otthon x86/x64 ASM-ben (más platfomokon dolgozom, embedded, stb.), de amíg P.H. előkerül (már ha lesz kedve hozzászólni), aki igen, nos én annyit tennék hozzá, hogy a kézi optimalizálás is sokkal bonyolultabb annál, mint hogy "X assembly utasitas utan meg celszeru berakni ket NOP-ot". Már megbocsáss, de ilyet is az mond, aki meg ehhez nem sokat konyít. És igenis, meg lehet verni a fordítót is. Lehet, hogy nem a fordításban, de ASM-ben olyan dolgokat is meg lehet tenni, amit C/C++-ban nem. Pl. a x264 enkóder egyes részeit is ASM-ben írják. (A JIT meg nem tudom, hogy jön ide, az futásidőben helyettesíti be az X procis kódrészleteket az Y proci előre megírt, megfelelő kódrészleteivel.)
Amúgy nem is tudtam, hogy ilyen rivalizálás van a jó kóderek és a másfajta programozók között. Mellesleg a kettő nem zárja ki egymást, mármint hogy valaki mindkettőben jó legyen.
-
orbano
félisten
szerintem nem is mondtuk, hogy kizárná, inkább csak arra reflektáltunk, hogy " a komoly programozó nálam ott kezdődik, hogy ..."
ettől még egy adott architektúrára való optimalizálás egy fontos szakterület, de ezzel azonosítani a programozást, mint szakmát inkább a lelkes amatőrökre jellemző badarságA vér nem válik VAZZE!™
-
dezz
nagyúr
Nekem nem úgy tűnt, mintha azzal azonosítaná, hiszen így folytatódott a mondat: "hogy ismeri az OS minden nyűgjét baját, ha akarja meg is tudja kerülni, és emellett ismeri a vasat is amire fejleszt, és nem retten vissza egy kis ASM-től ha fontos a futásidő." És még ez sem teljesen, mert ugye csak itt kezdődik.
Persze ezzel sem kell feltétlen egyetérteni, mert enélkül is lehet meglehetősen komoly programokat írni (amik viszont nem feltétlen futnak a lehető leggyorsabban), ugyanakkor azokat sem kell lebecsülni, akiknek ez a specialitása. (Ami továbbra sem merül ki abban, hogy "tudja, hogy a az X assembly utasitas utan meg celszeru berakni ket NOP-ot, mert ugy az gyorsabb lesz". Az ASM kódolás nem is igazán vagy nem feltétlen erről szól.)
-
nagyúr
> ugyanakkor azokat sem kell lebecsülni, akiknek ez a specialitása
Most nem ez tortent, hanem a forditottja, azokat becsultuk le, akiknek nem ez a specialitasa.
Akkor a kedvedert kifejtem a maradekot is, bar nem mintha arra valaszoltal volna, amit en irtam, hanem eleg szep szalmabab-erveles zajlott, de azert:
- igen, ASM-ben idonkent celszeru kodolni, bizonyos extrem ritka helyzetekben, ezen extrem ritka helyzetekben. Nyilvan ha valaki drivereket ir, akkor sem Javascriptben kodol.
- "JIT meg nem tudom, hogy jön ide" -- ugy jon ide, hogy a JIT kepes peldaul az aktualis hasznalati mintazatnak megfeleloen optimalizalni a gepi kodot
- a 'valo eletben' a teljesitmenyigenyes alkalmazasok fejlesztesenek legeslegutolso, es meglehetosen ritkan alkalmazott eleme az assembly kod irasa, mert ez eleg ritkan eri meg. (Tovabbra sem a GPU-driverfejlesztes es a videoenkoderek irasa a legjellemzobb nagy teljesitmenyt igenylo feladat, nyilvan a PH-n ez van szem elott, ettol meg nem ez a jellemzo). A 'teljesitmeny' definicioja is nyilvan sokfele. Regebben irtam parallelizalo posztkompilert -- volt benne rendes ASM kodolas? Nem. Novelte a teljesitmenyt? Persze. Ertelmes lett volna ASM-szinten foglalkozni a dologgal? Nem, mert nem 5% hanem 500% teljesitmenynoveles volt a cel.
- "Mellesleg a kettő nem zárja ki egymást, mármint hogy valaki mindkettőben jó legyen." Mint ahogy az sincs kizarva, hogy valaki Nobel-dijas fizikus es iro legyen egyszerre, elvileg. Gyakorlatban persze aki evtizedeket tolt gepi kod-optimalizalassal, az nem meglepo modon menetkozben nem lesz rendkivul tapasztalt mondjuk DSL-ek gyartasaban.
- "Ami továbbra sem merül ki abban, hogy" -- egy szoval sem irtam, hogy kimerul, olvast el megegyszer, hogy mit irtam (vagy ne olvasd el, tokmindegy)Szoval a lentebbi hozzaszolasban mondjuk a 'nem komoly programozo' olyan emberekre is vonatkozik, mint mondjuk Andrejs Hejslberg, Bruce Eckel, Martin Odersky, es meg sokan masok. Hat ha te ezt az allaspontot veded...
Meg azert a rend kedveert valaki irja le, hogy a webprogramozas az nem komoly munka (hiszen mikrokontrollert hekkelni komolyabb, mint mondjuk egy Facebook-meretu rendszert egyben tartani), a menedzselt nyelvek hatulgombolosoknak vannak, ja, es persze csak a fizikai munka a valodi munka![ Szerkesztve ]
while (!sleep) sheep++;
-
Jack@l
veterán
Szép kör, +1
De itt tudod, hogy nagy api fóbiások vannak, legszivesebben mindent assemblibe írnának, konzolokraA hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
-
dezz
nagyúr
Morgyi valóban egy kicsit lebecsülte azokat, akiknek nem a futásidőre való minél alaposabb optimalizálás (és az OS hülyeségeinek kikerülése, stb.) a specialitása. De, nekem erősen úgy tűnt, hogy te meg éppen őket becsülted le.
Szó szerint reagáltam arra, amit írtál. Ezzel nem a másik álláspontot védtem. Nem csak e két álláspont létezhet.
"Meg azert a rend kedveert valaki irja le, hogy a webprogramozas az nem komoly munka (hiszen mikrokontrollert hekkelni komolyabb, mint mondjuk egy Facebook-meretu rendszert egyben tartani), a menedzselt nyelvek hatulgombolosoknak vannak, ja, es persze csak a fizikai munka a valodi munka!"
Ha valami, akkor ez egy szép példája a szalmabáb-érvelésnek... Mert ilyet én nem írtam, éppen ellenkezőleg. És köszi, hogy most már az én munkámat is lebecsülted (mikrokontroller hekkelés), mellesleg az embedded terület szintén nem merül ki ebben.
-
nagyúr
> valóban egy kicsit lebecsülte azokat
Az hangzott el, hogy ok nem komoly programozok. Kicsit?> Ha valami, akkor ez egy szép példája a szalmabáb-érvelésnek...
A vege termeszetesen ironikus(nak volt szanva), ne vedd magadra.> hogy te meg éppen őket becsülted le.
Jaj, dehogy.
A mikrokontrollerrel sincs semmi problema, az is egy szakma, en azt nem szeretem, amikor eluralkodik az a nezet, hogy minel alacsonyabb szinten van a kod, annal nehezebb/hardkorabb/profibb. Nem az, es pont az mondom, hogy ezek ma mar akkora teruletek, hogy legritkabb esetben erthet valaki sokhoz egyszerre, illetve minden teruletnek megvannak a maga autoritasai. A programozas mara nem egy konkret terulet, emiatt tok felesleges azt mondani, hogy mindenkepp erteni kell X reszehez, kulonben nem vagy komoly programozo.
[ Szerkesztve ]
while (!sleep) sheep++;
-
Fiery
veterán
"es pont az mondom, hogy ezek ma mar akkora teruletek, hogy legritkabb esetben erthet valaki sokhoz egyszerre, illetve minden teruletnek megvannak a maga autoritasai. A programozas mara nem egy konkret terulet, emiatt tok felesleges azt mondani, hogy mindenkepp erteni kell X reszehez, kulonben nem vagy komoly programozo."
+1
-
dezz
nagyúr
Jó, akkor nem kicsit. Megjegyzem, attól, hogy így vélekedik, még lehet, hogy tud programozni, akár jól is, csak úgymond régi vágású. Nem kedveli a hw-től nagyon elrugaszkodott dolgokat. (Én se nagyon.)
Na igen, ASM-ben is lehet vacak programot írni, az nem nagy kunszt (de legalább felesleges). Azonban komplikáltabb rutinokat/függvényeket úgy megírni, hogy az még igen jól is fut, nem könnyű dolog és ugyanúgy profinak (és kreatívnak) kell lenni hozzá, mint bármi más nyelvben lekódolni valami összetettebb dolgot. Az is igaz, hogy ma már nem érthet mindenki minden területhez.
(A munkámnak csak egy kisebb része a uC, van itt FPGA is, jócskán "kibélelve", meg ami még kell egy komplett feladatorientált panelhez. De kódoltam már különféle OS-ek alatt, többnyire C-ben. Volt >20e soros ASM is [amiből kb. 100 volt adat], mert akkor még sokkal lassabb lett volna C-ben.)
[ Szerkesztve ]
-
nagyúr
Ok, a szemelyes preferencia tok mas kerdes, mint az, hogy nem vesszuk komolyan azokat, akik mashoz ertenek. Peldaul en nem szeretek GUI-t programozni, de ezzel egyutt latom, hogy a modern GUI fejlesztes valami irtozatosan bonyolult dolog, es verprofinak kell lenni ahhoz, hogy ne omoljon ossze a rendszer a sajat sulya alatt.
> ugyanúgy profinak (és kreatívnak) kell lenni hozzá, mint bármi más nyelvben lekódolni valami összetettebb dolgot.
Na, eljutottunk oda, hogy azt mondod, hogy igazan jo low-level programozonak lenni ugyanugy komoly melo, mint barmely mas nyelvben programozni. En ezzel total egyetertek, merthat ez eleg messze van a kiindulasi ponttol, miszerint csakis a low-level szakertelemmel egyutt lehet valaki komoly
[ Szerkesztve ]
while (!sleep) sheep++;
-
orbano
félisten
azért jellemző, hogy egy bizonyos programozói élettapasztalat és rálátási szint alatt gondolja azt egy programozó, hogy az a tuti, ha valaki mindent saját maga vs. pure metal tud megoldani. rendszerint pont azért, mert valós programozási feladattal nem találkozott, csak beadandókat írt és hobbiprojekteket, ahol lehet tényleg egyszerűbb egy bizonyos szintig megkerülni az APIk megtanulását és mindenből sajátot írni, stb. Ez nem kritika amúgy, csak egy megfigyelés
A vér nem válik VAZZE!™
-
dezz
nagyúr
Szerintem sok régi mororos is hasonlóképpen vélekedik, akik megmaradtak a C/C++-nál és esetleg vannak ASM-es tapasztalataik is. Ez olyan macsó dolog.
Egyébként .NET-ben számít valamit a HW valamelyes ismerete? Mármint, tudhat úgy valaki optimálisabb kódot írni benne? Vagy pl. OpenCL-ben (ha valaki ismeri itt behatóbban)?
[ Szerkesztve ]
-
orbano
félisten
persze, vannak ilyenek, nyilván mindenki azt tartja a legf*szábbnak és legszükségesebbnek, amihez ért
Mondjuk én ir régi motoros vagyok és C++ vonalon kezdtem, de mára nem különösebben zavar, hogy nincs a repertoáromban az agyonhekkelt überoptimalizált kód készítésének a képessége. fontosabbnak tartom a jó algoritmusok és az azokhoz illő adatszerkezetek megtervezését (mondjuk itt be tud jönni a hw architektúra a képbe, de csak mértékkel)..NET: igen lehet, de nagyon kell ismerni a CLR fordítóját, sok hekkelés, disassembly, memory dump nézegetés, miegymás. nem éri meg. vagy legalábbis nagyon rika esetben tudom elképzelni. GPU programozás esetében pedig kötelező ismerni a GPU-t bizonyos fokig (a feladatok ütemezése a számolókon, cache/puffer méretek fontosak, ezek nélkül nem lehet értelmesen megszervezni a párhuzamosítást, de ennél lejjebb nem tudom, hogy mikor van értelme, ennyit nem foglalkoztam a témával).
A vér nem válik VAZZE!™
-
nagyúr
> Egyébként .NET-ben számít valamit a HW valamelyes ismerete?
Egeszen ritka esetekben igen, nyilvan mondjuk a cache vagy a virtualis memoriakezeles az mindig es mindenhol eleg alapveto ismeret. A regi szep idokben volt egy helyzet, ahol a .Net JITter ASM kimenetet nezegettuk, mert olyan helyzet allt elo, ahol valami miatt erezhetoen szuboptimalis kodot produkalt -- jelezni kellett az MS-nek, es es megcsinaltak a kovetkezo verzioban. Egyebkent .Net kodba is lehet lenyegeben inline assembly kodot rakni, csak nem javasolt .
OpenCL-ben muszaj tudni, hogy korulbelul hogy nez ki egy GPU architektura, hiszen meg mindig blkIdx-ekkel meg tid-ekkel van tele a kod -- ezek meg vegulis hardverspecifikus dolgok, nem a feladatrol szolnak, hanem az implementaciorol. Valojaban mindaz, ami az elmeletet es az implementaciot elvalasztja, az a kornyezetrol szol (hardver ill. szoftverkornyezet). Pelda (wikipediarol, az egyszeruseg kedveert):
# ezt akarom csinalni
# ezt mondom a gepnek
__kernel void fft1D_1024 (__global float2 *in, __global float2 *out,
__local float *sMemx, __local float *sMemy) {
int tid = get_local_id(0);
int blockIdx = get_group_id(0) * 1024 + tid;
float2 data[16];
// starting index of data to/from global memory
in = in + blockIdx; out = out + blockIdx;
globalLoads(data, in, 64); // coalesced global reads
fftRadix16Pass(data); // in-place radix-16 pass
twiddleFactorMul(data, tid, 1024, 0);
// local shuffle using local memory
localShuffle(data, sMemx, sMemy, tid, (((tid & 15) * 65) + (tid >> 4)));
fftRadix16Pass(data); // in-place radix-16 pass
twiddleFactorMul(data, tid, 64, 4); // twiddle factor multiplication
localShuffle(data, sMemx, sMemy, tid, (((tid >> 4) * 64) + (tid & 15)));
// four radix-4 function calls
fftRadix4Pass(data); // radix-4 function number 1
fftRadix4Pass(data + 4); // radix-4 function number 2
fftRadix4Pass(data + 8); // radix-4 function number 3
fftRadix4Pass(data + 12); // radix-4 function number 4
// coalesced global writes
globalStores(data, out, 64);
}A ketto kozotti tavolsagot a hardveres es szoftveres kornyezet adja. Valojaban en nem akarok tobbet, mint amit a fentebbi keplet mond, azert vagyok kenytelen ilyen bobeszeduen irni dolgokat, mert egyelore nem eleg okos az absztrakcios reteg a gep es koztem.
Valojaban mindenkinek jobb lenne, ha eleg lenne a fenti kepletet hasznalni, mert extra idot es mentalis energiat visz el az, hogy a feladat helyett az implementaciora kell koncentralni.
Van egy magyar fejlesztocsapat, akik ugy nyernek tokjo palyazatokat, hogy a kodjuk kb. 5x lassabb, mint a tobbieke (jo okuk van ra, nem az, hogy hulladek kodot irnak, esetleg privatban reszletezem). Viszont 10x gyorsabban megcsinaljak, vesznek 5x annyi hardvert, es igy is sokkal-sokkal gazdasagosabban mukodnek, mint a tobbiek. Ez nekem szimpatikus: a feladatot megoldjak, csak emberi eroforrasok helyett az olcsobb gepi eroforrasokat hasznaljak. Neha ez persze nem opcio.
while (!sleep) sheep++;
-
orbano
félisten
nálunk ugyanez a helyzet, jobban megéri egyelőre atom vasak alatt C#-ban fejleszteni, mert túl gyakran kell hozzányúlni az algoritmusokhoz, túl nagy rugalmasságra van szükség, hiába lenne 5-10x gyorsabb C++-ban, amit nyernénk, az elmenne a méregdrága programozó-munkaidőn, ráadásul a versenyképességünk is csökkenne. ha szükség van rá, egy adott verziót még így is egyszerűen át lehet portolni egy alkalmasabb nyelvre, konkrét vasra, ha éppen szükség van rá egy adott ügyfélnél.
A vér nem válik VAZZE!™
-
dezz
nagyúr
Köszi a kimerítő választ! (Persze, jöhet privátban, de elég tőmondatokban.)
A matematikusok nyilván csak akkor lesznek elégedettek, ha elég lesz a képlet. Amúgy a MathLab nem tud ilyet?
(#121) Fiery: Úgy értettem, ha valaki az OpenCL kód elkészítésekor figyelembe veszi a HW felépítését, működését. Emvy válszolt rá. Esetleg még arra lennék kíváncsi, ha már így benne vagyunk, hogy lehet-e OpenCL-ben egyik (pl. Maxwell) vagy másik (pl. GCN) architektúra számára kedvezőbb kódot írni?
(#122) orbano: 5-10x szorzó azért durva.
[ Szerkesztve ]
-
nagyúr
A Maxwellen asszem csak az OpenCL 1.1 a tamogatott, szoval celszerubb CUDA-t hasznalni rajta.
Az 5-10x-es szorzot en se ertem egyebkent, altalanos esetben (!) egy Java kod nem sokkal lassabb, mint egy hasonlo minosegu C++ kod (szoval szazalekokban, es nem szorzokkal merik a kulonbseget). Amirol en beszeltem, az a C++ vs egy bizonyos interpretalt nyelv.
while (!sleep) sheep++;
-
Fiery
veterán
"lehet-e OpenCL-ben egyik (pl. Maxwell) vagy másik (pl. GCN) architektúra számára kedvezőbb kódot írni?"
Hogyne lehetne. Szerencsere eleg sok mindent ki lehet deriteni a konkret GPU architekturarol, pl. nVIDIA GPU-knal a compute capability konnyen detektalhato, az alapjan meg eleg jol be lehet loni, hogy milyen GPU-n fut az OpenCL kodod. Az mar csak rajtad all, hogy mennyire vagy hajlando az esetleg meglevo kododat tovabb optimalizalni azert, mert mondjuk erkezett egy uj architektura (pl. Maxwell, ez jott legutobb). OpenCL-ben nyilvan nehez lemenni olyan melysegekig, mint x86-on az assembly segitsegevel, de ha tisztaban vagy a GPU architekturaval, akkor berakhatsz kulonfele trukkoket, pl. kulonbozo melysegu unrolling, inline kodreszletek, int24 adattipus, stb. Vagy le is cserelhetsz beepitett fuggvenyeket, ha az adatok fajtajanak ismereteben gyorsabbat tudsz irni, mint amit az OpenCL alapbol kinal. Az OpenCL-lel rengeteget lehet mokolni, es valahol elvezheto is az egesz, amennyiben a compiler nem gancsolja el a kerneledet.
-
orbano
félisten
ezt ne kisméretű, jól optimalizálható algoritmusokra értsd, hanem összetettebb alkalmazásokra. pl. van egy szomszédsági bejárásunk, ami dependency injection design patternt használ olyan funkciókra, amik masszívan nagyon sokszor meghívónak, teli van lambda expressionökkel, linq-t használ, stb. itt azért jócskán el tud szivárogni a teljesítmény. de bizonyos egyszerű, ciklusban műveletvégzős esetekre is mértem már ki 5x körüli eltérést, ami meglehetősen kijózanítólag hatott, addig azt hittem a CLR fordítója okos és mindent megold és alig marad el a natív kódtól. Hát a frászt... ráadásul durván lábon tudod lőni magad. Mivel minden oop, egy nagy ismétlésszámú ciklusban pl. ha használsz egy mezőt az objektumból, 10x-es a bünti, ha a ciklusod masszívan igénybeveszi a cachet, és a mezőhozzáférés iszonyat cache misseket produkál. Ezt a C++ lazán kioptimalizálja. De egy sima összezős for ciklus is lassabbra fordul (pontos számokra nem emlékszem, de nem voltam boldog az összehasonlításnál).
A vér nem válik VAZZE!™
-
Jack@l
veterán
Nekem is lenne kérdésem, hamár így felajánlottad
Nem tudod, hogy kb mikor jön ki a végleges stabil opencl 2.0? Nv 7-es szérián meg Maxwellen is fut rendes, vagy van gondjuk vele?A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Fiery
veterán
Az OpenCL 2.0 mint specifikacio mar veglegesitve lett, ha lehet hinni a Khronos weboldalanak --> [link]
Az megint mas kerdes, hogy melyik gyarto mikor es hogyan implementalja a tamogatast. Amig nincs SVM (megosztott memoria) egy adott termeknel, addig nincs sok jelentosege az OpenCL 2.0 tamogatasanak. Az Intel elso OpenCL 2.0 kepes GPU-ja elvileg a Broadwell lesz. Az nVIDIA dGPU-khoz pedig nem igazan lehet ilyesmit hasznalni, ugyhogy azok velhetoen maradnak OpenCL 1.1 vagy 1.3-on.
[ Szerkesztve ]
-
Jack@l
veterán
Ja, akkor csak a közös memória a főbb újdonság a 2.0-ban, köszi. Ez esetben elkezdem a programozást majd az 1.2-vel. (Azért kérdeztem, mert hallottam hogy az nv nem nagyon erölteti meg mostanában magát opencl driverek terén)
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
dezz
nagyúr
Izé, kicsit elhamarkodottan fogalmaztam, hiszen az Nvidia SoC-okban természetesen eddig is voltak ARM magok. Arra gondoltam, vajon lesz-e olyan nagyobb teljesítményű, PC/HPC-s Nvidia GPU, amiben lesz ARM mag? Korábban mintha ezt is pedzegették volna. Vagy esetleg éppen ez a K1 az? (Akkor viszont kár, hogy nincs benne még SVM.) Bár ezt is mobilnak írják.
[ Szerkesztve ]
-
Fiery
veterán
Amennyiben GPGPU fejlesztest csinalsz, pl. OpenCL vagy CUDA segitsegevel, akkor majdnem mindegy, hogy egy low-end mobil GPU-n fejlesztesz, vagy egy high-end dGPU-n, legalabbis amig egy adott GPU architekturan belul gondolkozunk. Jelen esetben ha mondjuk van egy jo kis CUDA-s fejlesztokornyezeted, akkor ugyanolyan frankon tudsz dolgozni egy K1-en, mint egy GK110B-n. Mas kerdes persze, hogy valoban egyforman jol mukodik-e a fejlesztokornyezet (jelen esetben a CUDA 6.0) egy low-end ARM-os "APU"-n, mint amihez hozzaszokott az ember a PC-n es a dGPU-kon.
-
tlac
nagyúr
válasz #32839680 #139 üzenetére
jah, nekem sem nyerte el a tetszésemet, pedig az első benyomások nagyon jók voltak
az meg külön bosszant, hogy csak a matlab miatt vettem egy gtx titan-t, hogy ez majd milyen jól felgyorsítja nekem a neurális hálózat tanítását, de ehelyett eddig, csak lassított...[ Szerkesztve ]
Új hozzászólás Aktív témák
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- ELADÓ - Ryzen 7 5800X - ÉRTÉKELÉSRE VÁR
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Intel Pentium 4 3,2 GHz / 1 M /800 MHz Socket 478 CPU
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest