- Kompakt vízhűtés
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kormányok / autós szimulátorok topikja
- Vezeték nélküli fülhallgatók
- AMD GPU-k jövője - amit tudni vélünk
- Dell notebook topic
- Milyen videókártyát?
- NVIDIA GeForce RTX 5060 Ti (GB206)
- Milyen házat vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
-
PROHARDVER!
Új hozzászólás Aktív témák
-
kovisoft
őstag
-
#15296
pmonitor
aktív tag
Mechorganic
#15287
pmonitor
aktív tag
válasz
Mechorganic
#15287
üzenetére
Esetleg még azt lehet csinálni, hogy az egészet megírod C-ben/C++-ban. A sebességkritikus rész(ek) kódját megnézed, és ha találsz benne olyan részt, ahol szted lehet gyorsítani, akkor azokat megírhatod C-be/C++-ba ágyazott assemblyben. Macerás, de ha a gyorsaság számít, akkor talán ez a legegyszerűbb.
-
-
Livius
őstag
válasz
bambano
#15292
üzenetére
2021-ben amikor a piac szarásig van különböző fejlett fordítókkal PC-re, (intel compiler, gcc, clang, msvc stb...) amik a jelenlegi architektúrák mindenféle optimalizálást ismerik, sehol semmi értelme bárkinek is elkezdeni asm-ben lekódolni valamit, mert 100% hogy annyira köze sincs és nem is fogja megtalálni a neten azokat a dolgokat, amiket az adott CPU környezethez kéne tudnia használni, hogy tuti biztos hogy valóban jó asm kódot nem fog tudni írni, sőt lehet még működőt sem. Akár az ingyenes gcc vagy a fizetős társai is optimalizáltabb kódot fog fordítani, mert ezeket az okosságokat tudják. Az asm-nek ma már maximum a nagyon gyenge teljesítményű dsPIC szinteű mikrovezérlőkben van létjogosultsága, máshol pl ARM boardokon vagy Intel, AMD PC-ken semmi értelme ezzel bajlódni. Ráadásul a téma amire előjött kb arról szól hogy memcopy-zni kell jobbról balra, ebben könyörgőm, mit akartok asm-ben optimalizálni? Ha még pl 3 FFT és 2 mátrix invertálás és sajtérték számítás lenne a feladat közben, akkor azt mondom lehetne gondolkodni azon, hogy tudna e valamit hozni egy asm implementáció, de abban az esetben is az első az lenne, hogy az ilyenekre meg már van kész library ami már optimalizált teljesen és akár még multi-threades is alapból.
-
-
#15292
bambano
titán
Mechorganic
#15287
bambano
titán
válasz
Mechorganic
#15287
üzenetére
szerintem a nem sebességkritikus részeket meg lehet írni c-ben, a sebességkritikusokat meg c-be ágyazott assembly-ben. pl. a kép beolvasását úgyis a diszk limitálja, felesleges asm-et erőltetni rá.
-
#15291
Livius
őstag
Mechorganic
#15290
Livius
őstag
válasz
Mechorganic
#15290
üzenetére
Az IO művelet nem gazdaságos, szerintem még asm-ben sem, ezért ez a koncepció hogy sokszor kell hozzányúlnod a fájlokhoz rossz stratégia. Lehet hogy tudsz vele tárhelyet vagy adatküldést spórolni, de CPU időt meg pont hogy pocsékolni fogod nagyon sokat.
-
#15290
Mechorganic
újonc
Livius
#15288
Mechorganic
újonc
válasz
Livius
#15288
üzenetére
Hmm..jol hangzik.
2 kepnegyzet kozott csak a kulonbseget kell eltarolni, csokken a tarhelyigeny es az adatkuldesi igeny.
Le kene mernem a folyamatosan olvasok, tobb helyre irok
vagy a tobb helyrol olvasok folyamatosan irok-e a rovidebb ideju, bar elvileg IMdisk alatt nincs jelentosege, elvileg az infile es outfile is a memoriaban van.
Kovisoft koszonom szepen a linket, atbuggaraszom. -
#15289
kovisoft
őstag
Mechorganic
#15287
kovisoft
őstag
válasz
Mechorganic
#15287
üzenetére
Ha a sebesség számít, akkor lehet, hogy jobban jársz, ha C-ben írod meg a kódot, és rábízod az optimalizálást a fordítóra. A modern CPU-k bonyolult architektúrával rendelkeznek, kézzel nehéz olyan assembly kódot írni, ami gyorsabb kódot eredményezne annál, mint amit egy jó C compiler előállít sebességre optimalizált módban, mert ismerni kell, hogy mely utasítások milyen körülmények között tudnak párhuzamosan végrehajtódni, mikor mi mire vár, stb. Ha érdekel a téma, akkor ezen az oldalon találsz rengeteg infót az optimalizálással és a CPU architektúrákkal kapcsolatban.
-
#15288
Livius
őstag
Mechorganic
#15287
Livius
őstag
válasz
Mechorganic
#15287
üzenetére
Bármilyen .exe amit fordítasz egy mingw gcc-vel vagy akár a Visual studio-val console app-ként .bat fájlban használható, ehhez nem kell asm-ben írni. Én azt javaslom a standard C++-t válaszd erre, mondjuk Win XP-én a (Win 10-re is felmegy) Codeblocks ingyenes IDE-t felrakod a mingw-vel együtt és már fordíthatsz is bármilyen console-ban futó .exe-t. Ha még be is állítod a -Ofast optimalizációt, szerintem ugyan ott leszel sebességben mintha hozzáértően asm-ben csináltad volna.
Ezt a "képsorozat esetén a nem változó kép négyzeteket nem kell újra eltárolni" nem igazán értem, hogy ebben mi a lényeg. -
#15287
Mechorganic
újonc
Livius
#15285
Mechorganic
újonc
válasz
Livius
#15285
üzenetére
Nevezzuk hasznos elfoglaltsagnak.
Indoka: kepsorozat eseten a nem valtozo kepnegyzeteket nem kell ujra eltarolni.
Mukodik batch formaban is, a sebesseg miatt kezdtem el kutatni az assembly megoldast. Aztan majd fejlesztem tudasom mas prognyelvekkel is, ha az Univerzum ugy akarja. ;-) -
y@g4n
tag
Heló, fpga-val hajtanék egy Planar EL kijelzőt és végre találtam egy kódot, viszont ha jól látom benne, az 51. sorban lévő
poop <= el_vclk;miatt soha nem fog lefutni a 72. sorban található if feltétel.
A 47. sorban az van, hogy az el_vclk 4 órajelig magas, 4 órajelig alacsony, és ezt az 51. sor miatt követi a poop.
A 72. sor pedig arra alapoz hogy:if(~el_vclk && poop)
Jól látom hogy ez lehetetlen?(a kommentek nem biztos hogy oksák, ha valaki hibát talál és jelzi nagyon köszönöm!)
a kód: [link]
-
#15285
Livius
őstag
Mechorganic
#15284
Livius
őstag
válasz
Mechorganic
#15284
üzenetére
Ez most csak hobbi vagy valami konkrét cél is van ezzel?
2020-ban DOS-ba vagy Win XP-re ezt felejtsd már el. Millió másik sokkal modernebb program vagy script nyelv létezik erre, amiben 50-100 sorból minden kész van egyszerűen és még működik is a mai modern összes oprendszeren. Google-vel azért nem találsz semmit, mert ezt ma már senki sem használja, mert van fejlettebb szoftvertechnológia ilyenekre.
Ha csak simán standard C vagy C++-ban írnád Win XP-én mingw gcc-vel ugyan olyan gyors lenne 99%-ra mint amit most próbálsz egyáltalán nem hatékonyan megcsinálni asm-ben.
-
#15284
Mechorganic
újonc
Livius
#15281
Mechorganic
újonc
válasz
Livius
#15281
üzenetére
Nem kell, akarom. Dos, Win Xp. A sebesseg miatt assembly.
Masm 6.11 jelenleg.
move pointer
cx,0000h
dx, 00000h
olvasas
.....
megnyitas
move pointer
cx, 01ffh
dx, 0ff00h
iras.
Jelenleg 256 valtozoba. Ilyenbol kell 512darab. Vagy osszemasolhatom egy asm fileba, akkor nem lenne 64kB meretkorlat. Imdiskkel villan egyet a dos ablak, 256 nyitas olvasas iras zarassal 1 sec volt, bincmp es batch megoldassal 2,5 sec.
Az assembly a gyorsabb, nem meglepo modon.
Ezt az assemblyt is hetek ota bogarasztam ossze reszekbol a neten. A faagbol es kovabol elso szamitogeptol minden volt, vagyek ezt-azt reklam, de konkret peldaprogramot nem dobott ki Google nagy testver.
Dabadab: 33MB, 1Byte/pixel.
Ezt a beolvasast, matrixba tarolast, kimeneti matrixba masolast, matrix kiirast hogy tudom megvalositani assemblyben?
A bincmp batch megoldasban 2 oszlop a bemeneti adat a kepeken kivul.
0000000 0000000
0000100 0002000
0000200 0004000
...
0000f00 000e000
Kep jobb oldal
0000000 0001000
...... 0003000
.....0005000
.....000b000
.....000d000
..... 000f000 -
Livius
őstag
válasz
dabadab
#15282
üzenetére
Nah igen, akkor csak annyi kell, hogy egy fájlbeolvasási művelet kell az egész bementi fájlra, aztán ez egy nagy mátrixban le van tárolva. Ebből egy eredmény mátrixot fel kell építeni, aztán egyszerre azt kiírni fájlba, és ennyi. Ha soronként van valami extra tömörítési algoritmus, valami képfeldolgozás, akkor azt megérné még plusz szálakban párhuzamosítani.
-
#15282
dabadab
titán
Mechorganic
#15280
dabadab
titán
válasz
Mechorganic
#15280
üzenetére
A több szál tök felesleges, ez 32 bites pixelekkel számolva is csak 128 MB, az a pár memcpy nagyjából előbb lefut, minthogy elindulna egy szál. Ami tart valameddig, az az IO, azon meg nem segít a többszálúság.
-
#15281
Livius
őstag
Mechorganic
#15280
Livius
őstag
válasz
Mechorganic
#15280
üzenetére
Miben kell ezt csinálnod? Mi az oprendszer mi a programozási nyelv? Az egészet ASM-ben írod?
Ha van elég RAM-od és mondjuk 1-nél több CPU-d akkor a legegyszerűbb az, amit a végén is írtál, hogy az egészet egyszerre betöltöd egy mátrixba, aztán minden egyes sorra amit akarsz egymástól függetlenül elvégezni, azokat egyszerre elindított (egy for ciklusban egymás után, igazából nem pont egyszerre fognak indulni) külön szálakban, azt vársz azok végére és mondjuk az eredmény mátrixot meg már nem párhuzamosítva, hanem szépen sorban felépíted ezek külön eredményeiből (ekkor már csak copyzol sorról sorra).
Ez amit szeretnél C, C++, C#-ban egyaránt Linuxon vagy Windowson egy szép megoldás és még egyszerű is. Tonna számmal vannak a neten az ilyenekre a megfelelő példa kódok.
-
#15280
Mechorganic
újonc
opr
#15260
Mechorganic
újonc
Hogyan lehet tobb szalon?
256x131072raw nyit, beolvas a valtozokba 256Bytonkent 256 sort. Aztan az elsot bemasolja a 8192x4096raw elso sora elejere, a masodik 256ot a masodik sora elejere es igy tovabb 256 soron at. Kialakul az elso atmasolt 256x256 kepnegyzet.
Vagy a forrasbol olvasok folyamatosan es a celban mindig 1 sorral, 8192Bytetal kesobb kell beszurni, vagy a forrasbol olvasok nem folyamatosan es a cel normal rawba irok folyamatosan.
Vagy beolvasni a kepet egy 2d tombbe, es abban kijelolni es masolni, de azt meg nem tudom hogyan lehet megoldani assembly nyelven. -
Livius
őstag
válasz
dabadab
#15275
üzenetére
Googlizás közben erre az oldalra rátaláltam én is. Aztán valahogy eljutottam a kernel load_balance függvényéhez is ami ezt kell csinálja. Viszont nekem gyanús, hogy ez csak a sima normális nem real-time ütemezésbe beállított szálakra megy. Nálam az a szál amin hiányolom az ilyen fajta CPU-k közötti intelligens load balance-olást, az real-time-os FIFO ütemezésüre lett beállítva. Lehet az ilyenre nincs ilyen művelet a kernelben (egyértelműen nem láttam még a leírásokban ezt). Mivel nem létkérdés, hogy FIFO legyen az a szál majd kipróbálom valami sima ütemezéssel, hogy akkor hogyan viselkedik.
A "kernel/sched/rt.c" az aki a SCHED_FIFO and SCHED_RR-t ütemezi, mindjárt bele nézek van-e valami ilyesmi cucc benne. -
Drizzt
nagyúr
válasz
K1nG HuNp
#15274
üzenetére
Ugyan sose hasznaltam go-t, de ez tunik a go szinten elfogadhato megoldasnak. [link] Kb. Az a lenyege, hogy egy channelre figyelsz, s ha abban van olyan uzenet, ami miatt le kell allni, akkor leallsz. Ez nyilvan nem tul jo, ha valami hosszu blokkolo fuggvenyt kell hivnod.
Mas nyelvekben meg inkabb az explicit thread kezelessel lehet ezt megoldani, mert ott lehet kuldeni interruptot, amire a thread leallhat.
De amennyire tudom, a goroutine egyaltalan nem biztos, hogy kulont threadben fut, ez az egyik lenyege.
Emiatt viszont ezen az absztrakcios szinten nehez megallitani aszinkron dolgoknak a futasat. -
K1nG HuNp
őstag
hali, gózgatok most a 2 évnyi nodeozas után és kicsit gondolkodóba estem..
ugy go-ban a gorutinessal tudunk több "szálon", paralell kódot futtatni, a nodeban meg a promiseokkal..
Egyik nyelvben sem lehet már elindított gorutinet vagy promiset kívülről cancellelni, azaz ha elindítod az adott fvnyt (rutine, promise..) akkor ő a belső logikája szerint végig fog futni akár mi van.
van olyan nyelv/megoldás ahol az így hívott paralell függvények cancellelhetőek? úgy értve cancellelhetőek hogy jár a futása során az 56. sor kiértékelésénél, kívülről jön a cancel és fogja és bezár
illetve ha nincs, akkor miért nem baj ez hogy nincs? nekem most adatbázis olvasás történik paralell (dynamodb, ne menjunk bele) a lényeg az hogy küldök x kérést, x gorutine, és a http kérést handlelő fvt blokkolom amíg az összes gorutine nem jött vissza válasszal vagy amint 1 darab is hibával tér vissza. na ez mind fasza és jó, de megjön 1 error és a többi x-1 darab gorutine ugyan úgy lefut.
mint mondtam db olvasás tehát teljesen idempotens, kárt nem fognak tenni a lefutó gorutinek.. csak itt kezdtem el gondolkodni
ugye nodeban ez a promise.all, ott is mint utánaolvastam (eddig sosem kellett lol..), úgyan úgy lefut az összes többi promise.viszont mi van nem idempotens dolgokkal? adabázisoknál ugye erre vannak a tranzakciók, meg valami még dereng Gajdos úr órájáról is, szóval hogy adatbázisoknál is hasonlóan lefut a beérkező tranzakció összes eleme, csak ott azzal van kiküszöbölve a hiba után is lefutó szálak/fvnyek problémája, hogy rollbackelődik az egész a tranzakció előtti állapotra nem?
fú bocsi ha szerte szét van a komment, azért remélem átment a lényeg
-
-
Reflax
tag
válasz
dabadab
#15270
üzenetére
oooohhhh, de nagy segítség volt az a komment ott a githubon ennél a linknél
Gondolom hülye kérdés:
Ugye láttam van olyan, hogy stringre, ha jól értlmezem. És akkor lehet int-re is? Eléggé csecsemőcipőben járok ebben a dologban amúgy.
Szóval olyat lehet, hogy egy mondok valamit, egy függvény eéső bekérése szám, a második is, és mondjuk van utána még valamenyni szám bekérés. TehátInt N,M;
cin>>N>>M;
.
.//valamenyni sornyi kód
.
cout<<A;
.. //blablabla
cout<<B;
..//blablabla
cout<<C;
És mondjuk az N, M-et nem akarom kiszínezni, de az A és B-t igen, viszont a C-t nem. Akkor az A és B résznyi kódot valamibe bele tehetem és ott megmondhatom valahogyan, hogy minden ebben lévő szám legyen piros? Ha igen, how?
Szeretek okulni és keresem a válaszokat. Bocsánat, ha idegesítő lenne esetleg -
Reflax
tag
-
dabadab
titán
válasz
Livius
#15261
üzenetére
A linuxos SMP scheduler elég érett (huszonsokéve faragják nagyonsokprocesszoros szerverekre és az elmúlt másfél évtizedben desktop responsivityre is), alapvetően nem kell aggódnod amiatt, hogy nem elég okos
A (default) schedulerről itt egy elég jó cikk, ami úgy nagyjából elmagyarázza, hogy hogyan működik, bár pont az SMP balancingról nem nagyon esik benne szó, a konkrét technikai részletekkel (köztük az SMP balancinngal) kapcsolatban meg ajánlom a kerneldokumentációt.
-
Livius
őstag
Az simán megy hogy csak egy kizárólagos magra állítom be az affinitását, és akkor csak azon is megy ezzel nincs gondom. De most pont ezt szeretném alapos és biztos ismerettel eldönteni, hogy csináljam úgy hogy én megadom hogy csak és kizárólag a core0-án menjen, vagy mindegy lesz, majd okosan a Linux oda rakja ahol a legkevesebb a CPU használat éppen aktuálisan. Ebben az utóbbiban egyelőre nem bízok hogy így menne, mert gyanús nekem a tesztek alapján, hogy véletlenszerűen kerűl valamelyik magra a legelején mikor indul, és utána meg soha többet nem kerül át másik magra a szál, ami így nekem logikátlan. Összesen két magom van, azon kéne gazdálkodjak, és egy másik nagy CPU fogyasztású szál már megy kizárólagosan a core1-en, természetesen ott is van még bőven szabad CPU idő, de azért valami intelligens ütemezést várnák el a Linux-tól, hogy ne mindig akkor a core1-en menjen az a szál, attól még hogy ott kezdte el futtatni legelőször.
-
Livius
őstag
válasz
pmonitor
#15209
üzenetére
Szia!
Szerintem ezt a bferi.hu oldalon történő publikálást felejtsd el és térj át gyorsan GitHub-ra (még verzió kezelt is lesz a kódod) és így ott az angol nyelvű leírást is át kéne venni. Az ilyen privát weboldalakról a random open source közösség soha semmit nem fog megtalálni, főleg ha még magyar is a leírása. Jah és ha a problémának van hivatalos angol kifejezése a matematikai világban vagy numerikus analízisben azt a GitHub-on feltüntetve mindent visz az ilyen, mindenki rá fog találni, és beindulhat az igazán nagy szakmai elmélkedés ott a GitHub-on erről, akár mások javasolt átkódolásaival és ötleteivel a kódban.
Vannak már mások is akik ezzel foglalkoznak ott.
https://github.com/search?q=Cutting+stock+problem
Jah, amúgy validálásnak, hogy mennyire jó amit tud ajánlom a Matlab hivatalos megoldóját erre. A matlabnál azért általában a "state of the art" van implementálva matematikailag, tehát hobbi home office-ban nem igen lehet annál jobban működőt összerakni.
Matlab: Cutting Stock Problem: Solver-Based -
opr
nagyúr
válasz
Livius
#15261
üzenetére
Eleg regen kellett mar ilyesmit csinalnom linuxon, de ha jol emlekszem, anno ugy volt, hogy fix affinitast ki tudsz eroszakolni, hogy az n-edik magon fusson fixen, talan meg van valami olyan kiterjesztes is, hogy a "legjobb" magon fusson fixen, viszont nem fix affinitasu szal eseten amennyire tudom, nem tudsz beleszolni az utemezesbe, hogy mikor, hova legyen pakolva.
Aztan majd hatha jon valami igazi linux guru, frissebb tudassal, aki kijavit.
-
Livius
őstag
Sziasztok!
Lenne egy Linux C/C++ programozási kérdésem, de lehet nem is annyira a C/C++ nyelv a lényeg benne, Linux kernel v4.x-et használok.A kérdés az, hogy amikor C/C++-ban a pthread.h-et használva indítok egy plusz threadet FIFO ütemezésben úgy, hogy előre attribútumban beállítom neki a CPU affinitást minden magra, a futás közben ezt a Linux hogy fogja figyelembe venni és kezelni? A thread amit indítok egy végtelen ciklusban figyelget egy thread-safe queue-t, és amikor van valami új elem azt kiveszi, majd csinál vele egy két műveletet, aztán megint blockolva várja a következőt. Ez a szál teljesen jól működik, kb 3-4%-os CPU használatot eredményez, de számomra nagyon gyanús az, hogy mintha a Linux véletlenszerűen indítaná az egyik magon a sok közül ezt a threadet, és utána örökké, csak azon a magon futtatja, vagyis a blockolás feloldása után mintha sose lenne olyan, hogy a másik magra kerülne át a futtatása, pedig a másik magon több szabad CPU idő lenne láthatóan htop-ban. Tud valaki valami infót vagy valami jó linket, hogy valami nagy könyv/biblia szerint a több magot is használható threadeknek hogy kéne managelődni a Linuxban a CPU magok között?
-
#15260
opr
nagyúr
Mechorganic
#15256
opr
nagyúr
válasz
Mechorganic
#15256
üzenetére
Próbáltad több szálon megoldani? Ez a feladat elég jól párhuzamosíthatónak tűnik, illetve ha van elég ram, akkor az első beolvasást és az utolsó, teljes file lemezre írásán kívül elhagynám a lemezműveleteket. Beolvas, feldolgoz, összerak, kiír. Ebből a darabolás, meg utána a végső "fileba" (adatszerkezetbe) írás mehet párhuzamosan simán.
-
#15258
bambano
titán
Mechorganic
#15256
bambano
titán
válasz
Mechorganic
#15256
üzenetére
ramdisken próbáltad?
-
#15256
Mechorganic
újonc
Mechorganic
újonc
Udv Vilagegyetemek Nagy Alkotomesterei!
Segitsegetek es tanacsotok kerem.
Mi modon vagyunk kepesek a leheto legkevesebb ido alatt 256x131072pixel infile tomoritetlen grayscale raw filebol 512db 256x256 pixel meretu kepet atmasolni 8192x4096 pixel outfile grayscale raw fileba?
Bincmp, partcopy, copybyte, sfk es batch 16 perc.
imagemagick + copy 40 sec
Masm6.11 gyel probalkoztam. A 64kB korlat miatt minden 256B utan zartam az infile-t es nyitottam az outfile-t. 1 sec/kepnegyzet.
Azutan infile nyitas utan 256 bufferbe beolvastam a 256 sort(termeszetesen nem akarta forditani a 64k korlat miatt a bestia), majd zaras es outfile nyitas utan beillesztettem a bufferek tartalmat az outfile-ba.
Van ennel kevesebb idot igenylo megoldas?
Windows ala melyik assemblyt erdemes hasznalni erre a celra?
Az is A x 10000hByte + offset modon kezeli a file-okban pozicionalast, vagy lehet pozicionalni 01213452h modon?
Elore is koszonom a segitsegetek es tanacsotok!
Boldog Karacsonyt, jo egeszseget es jobb vilagot kivanok! <3 -
y@g4n
tag
válasz
Primary92
#15242
üzenetére
A minecraftos ötlet az jó lehet ha szereti a játékot, redstone-nal egész komoly logikákat lehet összerakni, [link] command blockkal meg *ha jól emlékszem* lehet generálni, meg szkriptelni dolgokat.
Ez nem tudom mennyire bejáratott út, de ha érdekli jó ötlet lehet aliexpressről bevásárolni vagy 5 darab arduino nano klónt, meg egy breadboardos kitet és igaz hogy alacsonyabb szintű kódolás mint egy scratch/python viszont ott van benne valós életbeli visszajelzés.
Az hogy egy led felvillan vagy hogy egy motor elindul előre hátra számomra sokkal többet tud jelenteni mint egy pythonos hasonló alap szintű progi, és lehet egy gyerek is így van vele.
Nem is túl nagy befektetés szerintem, annyi hogy itt a kezét fogni kell mert hamar elfüstölhet az összes arduino ha rosszul kötöget.Komolyabb befektetés az ez: [link] Ez is áramkörösebb, angoltudás ajánlott, de ahogy nézem nem túl sok.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
ugye nodeban ez a promise.all, ott is mint utánaolvastam (eddig sosem kellett lol..), úgyan úgy lefut az összes többi promise.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Bomba ár! Lenovo X1 Yoga 4th - i5-8GEN I 8GB I 256SSD I 14" FHD Touch I W11 I CAM I Garancia!
- LG 27GP95RP - 27" Nano IPS - UHD 4K - 160Hz 1ms - NVIDIA G-Sync - FreeSync Premium PRO - HDR 600
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 4070Ti Super GAMER PC termékbeszámítás
- LG 55G4 - 55" OLED evo - 4K 144Hz & 0.1ms - MLA Plus - 3000 Nits - NVIDIA G-Sync - FreeSync Premium
- Honor 8 32GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest