Hirdetés
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- D@reeo: Pi-hole és a Telekom Sagemcom F@st 5670 DNS beállítása
- Brogyi: CTEK akkumulátor töltő és másolatai
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- bb0t: Ikea PAX gardrób és a pokol logisztikája
- GoodSpeed: A RAM-válság és annak lehetséges hatásai
Új hozzászólás Aktív témák
-
dezz
nagyúr
Nem volt célom különösebben vitatkozni veled.
SPE-nként: X sor beolvasása az SPE LS-ébe DMA-val (X = 1...amennyi elfér egy LS-ben/2), SPE-n belül a konverzió elindítása, közben a már átkonvertált sorok kiírása DMA-val. Term. az adatforgalmat koordinálni kell.
"Biztos."
Tehát, a PC-s szoftverek túlnyomó többsége SIMD vagy FP lenne? Ezen most egy kicsit csodálkozom.
"Függ tőle? Nem adott esetben?"
Párdon?
"AMD64-nél nem volt marketing?"
Miért lett volna? 3,5 GB main ram és 2 GB/process sokszor kevés már PC-n is. Ezen kívül kicsivel gyorsabbak is a 64 bites kódok, könnyebb rá optimalizálni (gépileg vagy manuálisan, több regiszter ugye, stb.) és modernebb az egész platform.
(#46) MaUser: Egy egész program portolása per nap tempó mellett nem hiszem, hogy nagyon belenyúltak volna a kódba, mely esetben ugye tök mindegy a hossz... A hatékonyságról meg egy szó sem esett. 'Így könnyű...'
-
MaUser
addikt
Mi a bajod a kódsorok számával? Alig találsz olyan maintenance metric-et ami nem arra épül (függványek hossza, scope hossza, stb.), akkor meg lehessen már megemlíteni egy marketing anyagban, ahol pont a portolás egyszerűségét hozzák fel...
Egyébként csak egy példa ahová ezeket ezrével lehet majd eladni: rapid prototype esetén elég gyakori, hogy adott egy program, ami "csuklóból" párhuzamosít x86-on, de a mért adatok mennyisége miatt rengeteg mérnökóra megy el szimplán várakozásra, azonban cluster kiépítése és fenntartása nem érné meg az időszakos felhasználás miatt. Ha egy ilyen kártya kijön egy-kétezer €-ból és közel automatikusan kezelni fogja az x86 kódokat, akkor alapfelszereltség lesz szinten minden k/f mérnöknél...
-
P.H.
senior tag
"Cell: első nekifutásra, pár sort beolvasni minden SPE-be, azt' mehet. Csak azt nem tudom, miért releváns ilyen egyszerű feladatnál hasonlítgatni..."
Leírnád, mi történik a pár sor beolvasása után, vagy erre hogyan kellene tervezni software-t? DMA, ilyesmi?A többit összevonva: Biztos. Függ tőle? Nem adott esetben? AMD64-nél nem volt marketing? Nekik ennyi a belefektetett energia, másnak több?
Beszélgetünk és informatívan vitatkozunk, vagy csak egymás mondatait cáfoljuk?
-
dezz
nagyúr
Cell: első nekifutásra, pár sort beolvasni minden SPE-be, azt' mehet.
Csak azt nem tudom, miért releváns ilyen egyszerű feladatnál hasonlítgatni..."pl. asztalon "ritka" a nem SIMD vagy lebegőpontos kód, nagyítóval kell keresni az ilyeneket, ezért a Bulldozer nem feltétlenül jó választás ide"
Hmm, biztos, hogy ezt akartad írni?
"szervereknél viszont "ritka" a SIMD- vagy FP-kód, ott úgy tűnik, senki sem vitatja a teljesítményének versenyképességét"
Nos, attól függ, hogy adatbázis- vagy HPC szerver...
"amennyiben olyan algoritmusokat használnak, amelyeknél minimális a számítást végző egységek közti kommunikáció igénye egy-egy részprobléma esetén egészen a teljes megoldásáig, tehát jól osztható független részfeladatokra, addig hatékony. Amely problémákat nem lehet így megvalósítani, azoknál fel sem merül ezen eszközök használata."
Hát, adott esetben nem gond a kommunikáció...
"a mérnökök számos alkalmazást, összesen mintegy 5 millió sornyi Fortran, C és C++ kódot ültettek át"
Ó, micsoda marketing szöveg...
"a 32 magos Knights Ferry tesztchipre, a tudományos szoftverek "portolása" egyenként egy napot vett igénybe."
Mondhatta volna azt is, hogy 5 perc, csak mondjuk nem mindegy a hatékonyság...
-
P.H.
senior tag
Mint láthatod, én nem mondtam véleményt róla, csak valóban a legegyszerűbb példán keresztül leírtam, hogy négy eltérő - nem is architektúrára, hanem - koncepcióra hogyan lehet(ne) ugyanazt a programot megtervezni. Nyilván nem mindegy, hogy milyen memória-alrendszerek vannak köréjük építve, de ez a tervezőik dolga, nem a "felhasználóké"/programozóké (lásd az előző Knights Ferry). De ötödikként tedd hozzá nyugodtan, hogy ezt Cell-en hogyan oldanád meg, ezzel is bővülne a kép és szélesedne a látótér.
Az, hogy mi ritka, az relatív (pl. asztalon "ritka" a nem SIMD vagy lebegőpontos kód, nagyítóval kell keresni az ilyeneket, ezért a Bulldozer nem feltétlenül jó választás ide; szervereknél viszont "ritka" a SIMD- vagy FP-kód, ott úgy tűnik, senki sem vitatja a teljesítményének versenyképességét
).
Semmiképp sem nevezhetném ritkának azokat a problémákat, amiért az emberek hajlandóak mélyen a zsebükbe nyúlni. Jelen esetben általánosan az elosztott számításokról - distributed computing - beszélünk: legyen az chipen belüli (multicore, GPU, GPGPU, játékok - nyilván nem véletlenül nő a shader processzorok száma az egekbe), szobányi rendszereket felölelő (pl. Cray-rendszerek) vagy a világon átívelő (BOINC), mindegyiknél ugyanaz a lényeg: amennyiben olyan algoritmusokat használnak, amelyeknél minimális a számítást végző egységek közti kommunikáció igénye egy-egy részprobléma esetén egészen a teljes megoldásáig, tehát jól osztható független részfeladatokra, addig hatékony. Amely problémákat nem lehet így megvalósítani, azoknál fel sem merül ezen eszközök használata.Az átírás megint egy érdekes kérdés: nem öntötték el a világot a GPGPU-segített programok, de szállingóznak; akik ezeket használják, azok elégedettek. Mások pedig a saját programjaik kapcsán vannak megelégedve:
"Az MIC projekt első mérföldköve a 45 nanométeres Knights Ferry kódnevű chip, ami 32 magot tartalmazott, ezeket a lapkákat tartalmazó PCI Express bővítőkártyákat az MIC projektben résztvevő Intel-partnerek, akadémiai intézetek kaphatták meg. Glenn Brook, az Oak Ridge National Laboratoryt és a University of Tennessee mérnöki-tudományos számítástechnikai erőfeszítései felett bábáskodó Joint Institute of Computational Sciences igazgatója az eseményen elmondta, a mérnökök számos alkalmazást, összesen mintegy 5 millió sornyi Fortran, C és C++ kódot ültettek át a 32 magos Knights Ferry tesztchipre, a tudományos szoftverek "portolása" egyenként egy napot vett igénybe." -
#41
orbano
félisten
TESCO-Zsömle
#40
orbano
félisten
válasz
TESCO-Zsömle
#40
üzenetére
Akarjuk, csak még nem jöttem rá melyik a legalkalmasabb mód, meglehetősen nagy cég
-
orbano
félisten
Ahogy én képzelem ezt a cuccot, szeretni fogja a proginkat. nagyon kevés adattal dolgozunk elképesztően sokat, így sávszélesség gondunk nem lesz. mondjuk a szinkronizációval lehetnek gondok, most is van valamennyi starving sima i7-en, de úgyis nekiállunk újraírni a progit, az megjavítja. ezért is örültem volna, ha tudok szeretni ebből egy példányt, hogy le tudjuk a koncepciónkat ellenőrizni rajta.
-
dezz
nagyúr
Azért ne gondold, hogy ide nem kell átírni, vagy akár áttervezni a programokat, hogy valóban jól fussanak!
(#37) P.H.: "csak a szálszámot kell megnövelni, ha már eddig is többszálú volt a program (ennél azért többet kell tenni, de kb. ilyen egyszerű lépésekben)."
Ezt valahogy kevésnek érzem. Nem tudom, hány csatornás és milyen memória lesz mellette, de arra is oda kell figyelni, hogy ne "akadjanak össze" az adatok. Meg hát a példád a lehető legegyszerűbb, ritkán ennyire függetlenek és eleve elkülönülők az egyes szálakban elvégzendő műveletek.
-
P.H.
senior tag
Valahol elveszlik a lényeg, ha így közelíted meg. Ezek az erősen párhuzamosíható feladatok nem fekszenek a CPU-knak, a kevésbé párhuzamosíthatóak pedig a GPU-knak. Mondok egy nagyon egyszerű példát, talán így jobban kijönnek a különbségek: van egy 1 megapixeles képed, amin a pixelek YUV színtérben vannak, ezt át kell konvertálni RGB-be (tipikus JPEG- vagy MPEG-feladat); ez a konvertálás kb. CPU SIMD 20 utasítás, kell hozzá 3 konstans és pixelenként 4 regiszter.
Egy CPU-val mit csinálsz? Írsz egy ciklust, ami lefut minden pixelre. Ezek a lefutások függetlenek egymástól (egyik pixelnek sincs köze a másikhoz), OoO is a processzorod, csak az utasításdekódolás sebessége és a ROB mérete (azaz az egyszerre on-the-fly állapotban levő utasítások száma) limitálja azt, hogy mikor kezd neki a következő ciklusnak; egy modern mikroarch 4 utasítást dekódol órajelenként, azaz 5 órajelenként indulhat a következő ciklus. A ROB gyorsan betelik, mivel egyetlen összeadás vagy szorzás tipikusan 3-6 órajel, tehát nem tudja olyan gyorsan fogadni az egymást követő utasításokat, hogy hosszabb távon tartani tudja az 5 órajelenkénti következő ciklust.
Egy GPU-val mit csinálsz? Átadod neki a 20 utasítást, megmondod, hogy futtassa le 1 milliószor, ezen az bemeneti adaton, erre a kimenetre, ekkora léptékkel. Van neki 32-512 shader processzora és hozzá egy jó nagy regiszertömbje, elkezdi a ciklusmagokat lefuttatni annyi példányban egyszerre, amennyire kapacitása van, majd ha kész az egésszel, akkor jelzi. Nincs decode, ROB, OoO; nem is kell, mert csak 20 utasításod van, amit le kell futtatni 1 milliószor: számítási teljesítményben ki van gyúrva, az utasításfeldolgozási rész kicsi, mert ugyanazon a 20 utasításon miért rágódnál el 1 milliószór?
Egy Itanium-mal mit csinálsz? In-order CPU, de van egy kisebb halom regisztere, meg egy okos utasításkészlete, ami által megmondod neki, hogy most egy olyan programrész következik, ami ciklus, de a lefutások függetlenek egymástól. Megmondod továbbá azt is neki, hogy itt kezdődik a ciklusmag kódja, emitt van a vége, ennyi a lépésköz, kell hozzá 4 regiszter és 1 milliószor kell lefuttatni (mindezt pár utasítással). Végrehajtó egységből nem sok van neki, de belül megoldja, hogy elkezd annyi ciklusmagot futtatni párhuzamosan, ahánynak az igénye csak belefér a kisebb halom regiszterébe illetve amennyinek az utasításait tudja tárolni ideiglenesen. Egy-egy szorzás vagy összeadás időigénye továbbra is néhány órajel, de mivel a végrehajtói pipeline-osak, a következő órajelben egy másik ciklus utasítását indíthatja el, így nem sérül az in-ordersége sem (mivel ez csak ciklusmagon belül szükséges, hisz megmondtad neki, hogy ez olyan ciklus, aminek lefutásai nem befolyásolják egymást). Ha kész, akkor elindul a ciklust követő következő utasítások lefuttatása, mint minden rendes CPU-nál.
Egy MIC-en mit csinálsz? In-order (~Atom) x86 magok, kevés regiszterrel és kevésbé okos utasításkészlettel: annyi (de minél több) szálra bontod a programot, amennyi még nem befolyásolja negatívan a teljesítményt, pl. egy szál egy képsort dolgoz fel, lehet ez akár példából kiindulva 1000 vagy több sor/szál is. Az OS majd elosztja a szálakat a magok között, magonként 4-et. Ha egy szorzás vagy egy összeadás időigénye 4 órajel és a végrehajtók pipelined-ek, akkor in-order magon pont jó, mert órajelenként indíthatja a CPU más-más szál utasításait úgy, hogy egy-egy szál akkor se futna le számottevően gyorsabban, ha csak ezzel az eggyel foglalkozna az adott mag (mivel a következő utasítás nagy eséllyel függ az előző eredményétől 1 szálon belül). Ha kész egy-egy szál, akkor az OS számára jelenti, hogy végzett; amikor az összes kész, akkor az van vége a feladatnak.
Ha így (és kissé egyszerűsítve) közelítjük meg, akkor már talán tisztább az, hogy mire jó (és talán az is, hogy mi mire lesz jó a jövőben):
- egy általános CPU-ra nem tervezel több 100 szálat, mert csak a bonyolultságot növeli és egy x86 mag csak 2 szálat tud futtatni; egy MIC-re ez sima ügy. Mégsem GPU: elrágódik ugyan a 20 utasításon 1 milliószor (dekódolás) külön-külön, de nincs ROB, ami betelhetne, ha elég nagy a per-thread utasítássor. Nem is Itanium, mert nem kell átírni/újrafogalmazni az egészet a független lefutású ciklus miatt, csak a szálszámot kell megnövelni, ha már eddig is többszálú volt a program (ennél azért többet kell tenni, de kb. ilyen egyszerű lépésekben).
- ha ezt vesszük példának, akkor uop-bufferrel + kb. az Itanium megoldásával, azaz utasításkészlet-bővítéssel (független ciklusok felprogramozása) tudom elképzelni azt, hogy egy jelenlegi FPU-t a jövőben lecserélnek GPU-szerű megoldásokra. -
ddekany
nagyúr
Én ezt, hogy nem kell újra írni a programokat, nem teljesen vágom. Azt értem, hogy futnak a régi x86-os programok rajta, de mivel eddig nem volt ilyen felépítésű (nagyon sok mag, stb.) x86-os CPU, ha ki akarom aknázni egy ilyen potenciálját, nem kifejezetten erre az processzora gondolva kéne megírni a sebesség szempontjából kritikus algoritmusokat? Ha csak egy hagyományos programom van, ami annyi szálat alkalmaz ahány magot lát (de azt nem tudja hogy ezek pici buta magok, ki tudja milyen memória elérési tulajdonságokkal), az vajon mennyire fog hatékonyan futni? Egyáltalán van lehetősége programnak kontrollálni a magok közti adatmegosztást, vagy kötelezően mindent áttetszően a hardver old meg?
-
#32
orbano
félisten
TESCO-Zsömle
#31
orbano
félisten
válasz
TESCO-Zsömle
#31
üzenetére
mondjuk nem lenne rossz, ha az összes melegedő alkatrész beférne egyetlen fémlemez alá és lehetne lapos-széles bordákat tenni léghűtésnek ,vagy egyszerűen csak vizet egy darab blokkal. de valahogy még SSF frontos sem valami hatalmas sa fantázia. talán majd ha elkezd haldokolni a PC...
-
#29
#16939776
törölt tag
TESCO-Zsömle
#28
#16939776
törölt tag
válasz
TESCO-Zsömle
#28
üzenetére
Legyen
Nálam is mATX, és 1db vga van benne. Szóval +1 user a példádhoz. sőt 2 sata port is bőven elég a többi csak a helyet foglalja. még a tápkábeleket is méretre vágtam olyan pici a hely
A "szélirány változást", támogatom, kompaktabb, csendesebb gépeket lehetne összerakni
A többiről beszéljünk 1-2 év múlva
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#28
TESCO-Zsömle
titán
#16939776
#26
TESCO-Zsömle
titán
válasz
#16939776
#26
üzenetére
Akkor az is co-processzor.
Nagyon örülök.
A dolog lényege, hogy nem kell megtartani a bővítőkártyákat. Nem mindet. Hány olyan felhasználó van, akinek nem elég az mATX alaplap 4 bővítőhelye úgy, hogy még a VGA-t is oda kell tenni? Maradjon a lap végén 2 slot és annyi. Bőven elég...
Bár -szvsz- nem dobna hátast a világ, ha végre elfelejtenénk az ATX-et... Legyen kompatibilis a lapok furatkiosztása, meg a kivezetések, de a RAM-okat igazán beforgathatnák már "szélirányba"...
Nem ragaszkodok a QPI-hez*, de a PCIe most is szűk keresztmetszet, szóval azt inkább hanyagoljuk.
* - Legyen HyperTransport.
-
#27
Abu85
HÁZIGAZDA
shabbarulez
#21
Abu85
HÁZIGAZDA
válasz
shabbarulez
#21
üzenetére
Ez is érdekes. Beleírtam ezt az opciót is. Valamelyik csak megtörténik. Köszi.
-
#26
#16939776
törölt tag
TESCO-Zsömle
#25
#16939776
törölt tag
válasz
TESCO-Zsömle
#25
üzenetére
Nem a processzort terheli: adat darabolása/összeillesztése, paritás bitek kiszámítása, hibajavítás.
Értem hogy miről szól a cikk
Hogy ez elférjen a Cpu mellet, Eatx lap kell, ha meg akarjuk tartani a bővítőkártyákat is.
Qpi-vel nem fogjuk Desktop lapon látni
shabbarulez is azt írja hogy nem kell hozzá host cpu, ergo nem Co-processzor
-
#25
TESCO-Zsömle
titán
#16939776
#24
TESCO-Zsömle
titán
válasz
#16939776
#24
üzenetére
A RAID-vezérlő miben segíti a processzor munkáját?
Mindegy, hogy minek nevezed... Hívhatod téglának is, attól még a GPU co-processzor marad...
Az, hogy mit hiszel, lényegtelen. Itt alapvető változások mennek végbe, amik megváltoztatják a részegységek szerepét és viszonyát. Tény, hogy a PCIe iszonytatóan szűk ahhoz a direkt eléréshez képest, ami az APU-ban van. Ezzel valamit kezdeni kell... Vagy a dGPU-k szerepét kell megváltoztatni, vagy a kapcsolatot szorosabbra fűzni.
-
#24
#16939776
törölt tag
TESCO-Zsömle
#11
#16939776
törölt tag
válasz
TESCO-Zsömle
#11
üzenetére
A Raid vezérlő cpu-ja is legyen co-processzor
A VGA és CPU "között" van ez az izé, nekem csak "bővítőkártya" lesz, amíg bele nem költözik a cpu-ba
Nem hinném hogy külön qpi-t fog kapni Desktop MB-n, maradni fog Pci-Ex sávon.
-
dezz
nagyúr
Ami egy Keplert vagy GCN-t megfektet, az szerintem ezt is meg fogja fektetni. Nem a szokásos x86/x64 magokra kell gondolni, igencsak le lehetnek butítva, hogy 64db fér el belőlük egy lapkán... Talán rosszabbak is rugalmasságban és más, CPU-knak tulajdonított előnyökben, mint akár az említett architektúrák.
Mondjuk az sem mindegy, milyen memória van mellépakolva, "CPU-s" DDR3 vagy "GPU-s" GDDR5. Vélhetően az utóbbi, mert itt is kell a sávszél, a rosszabb latency árán is, amit tovább ronthat a ringbus.
-
#21
shabbarulez
őstag
shabbarulez
őstag
"Ettől függetlenül nem elképzelhetetlen, hogy később lesz egy QPI összeköttetést használó verzió, melyet jóval közelebb helyezve a processzorhoz drámaian csökkenthető az adatmozgatással járó kommunikációs késleltetés. "
Nem valószínű hogy lenne benne QPI. A MIC, ahogy az előd Larrabee is egy sok magos általános célú cpu, így önmagában is működőképes, nem szükséges host cpu a működéséhez. Egy hónapja volt Európában egy HPC konferencia, ahol az egyik előadás témája egy olyan project volt, ahol 2 KNC-t raknának egy blade-re, host cpu nélkül, közvetlen hálózati csatlakozással. Így nem kell drámaian csökkenteni a host cpu-val történő adatmozgatással járó kommunikációt, mert olyan nincs is a rendszerben. [link]
-
tocsa
senior tag
Mik a legfrissebb információk a MIC architektúra magok közötti kommunikációjával kapcsolatban? A régi Larrabee tervek még gyűrű buszról (ring bus) szóltak (ami eléggé bottleneck, emiatt alkalmazták volna a binned renderinget). Jóval később egy-egy hírben láttam említést mesh összeköttetésről említést. Szóval mi most a helyzet? Ez sokkal fontosabb, minthogy mi az egyes magok adata.
-
dezz
nagyúr
Összefoglalva a cikkben elhangzottakat: nem lesz kis teljesítménye, de nyilván nem lesz olyan hatékony (teljesítmény/fogyasztás és teljesítmény/terület), mint a mai vezető GPU-k. Az Intel az x86/x64 kompatibilitásra próbál építeni. Kvázi azt mondják: ne törődjetek vele, hogy rosszabb, kevesebb vele a meló! Hát, ez nekem nem túl rokonszenves stratégia...
(#3) NLZ: És? A GPU-kat sem csak raszter-grafikára használják... Már PC vonalon sem, de ott vannak az eleve nem erre épített kártyák is (Tesla, stb.).
(#8) Móci: Nem a GPU részét, hiszen a mai GPU-k nagyrészt szintén vektortömbökből állnak, azaz lényegében vektorprocik, a szokásos raszter-grafikára alkalmassá tevő egységekkel kiegészítve. Itt ezeket az egységeket gyomlálták ki, mert úgysem lenne alkalmas a cucc az AMD és az Nvidia GPU-ival való versenyzésre.
-
vanhalen
senior tag
Mint az űrállomásos faszi?
Ez most komoly: Meghirdettek egy TV-s/Netes szavazást anno, hogy mi legyen a nemzetközi űrállomás neve, ahhoz hasonlóan, mint amikor a majdani, végülis megyeri híd-ra keresztelt képződmény esetében nálunk. Volt egy csávó, valami TV-s sztár, showman vagy mifene és a "hívei" meg ő elintézték valami szavazóprogival, hogy ő nyerje meg, vagyis az ő nevét viselje az űrállomás. Végülis a Nasa kárpótlásul megígérte neki, hogy az egyik WC-t róla nevezik el odafönt. Nem tudom, így lett e, de azóta szomorú
-
#10
hugo chávez
aktív tag
Abu85
#5
hugo chávez
aktív tag
Annál talán valamivel igen, de azért még ebben sem vagyok teljesen biztos.
De legalább, ha az Itanium vonalat végképp dobná az Intel (amire, ha a Poulson is bukik, akkor szerintem elég nagy az esély), akkor így lesz egy újabb feneketlen pénznyelője.
(#6) mmdms:
Amiért ilyen becsületesen bevallottad, ezért most az egyszer elnézem.
-
#6
mmdms
addikt
hugo chávez
#4
mmdms
addikt
válasz
hugo chávez
#4
üzenetére
bocccs, asszem én voltam..
-
#5
Abu85
HÁZIGAZDA
hugo chávez
#4
Abu85
HÁZIGAZDA
válasz
hugo chávez
#4
üzenetére
Szóval szerinted is sikeresebb lesz, mint a Larrabee.
-
#4
hugo chávez
aktív tag
hugo chávez
aktív tag
Mintha Itanium "szagot" éreznék a levegőben...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- AMD RYZEN 7 7800X3D/RTX 5070 Ti 16GB/32GB RAM/1TB NVMe/750W
- Gamer Konfig i7-11700KF, 32 GB DDR4 3200 MHz, 2 TB SSD, RTX 3070 Ti, MSI-Z490, Lian-Li ház, 850W Táp
- DDR5 Gamer PC - I5 12400f, RTX 3070, 16gb RAM
- 2013 Late 27 iMac - 1TB HDD i5 core4 24GB RAM 2GB GTX
- AMD RYZEN 7 7800X3D/RTX 5070/32GB RAM/1TB NVMe/750W
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Dell 14 Latitude 7450 WUXGA 2in1 Touch X360 Ultra5 135U 12mag 16GB 512GB Win11 Pro WiFi7 Garancia
- Apple iPhone 11 64GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy S23 Ultra 5G 512GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest