- sziku69: Fűzzük össze a szavakat :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Meggyi001: RTX 5060 - Az új népkártya?
- Luck Dragon: Asszociációs játék. :)
- Ndruu: Segíts kereshetővé tenni a PH-s arcképeket!
- gban: Ingyen kellene, de tegnapra
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- bitpork: Phautós tali a Balcsinál 2025 Augusztus 2 napján (szombat)
- bambano: Bambanő háza tája
- eBay-es kütyük kis pénzért
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
LOGOUT
Új hozzászólás Aktív témák
-
válasz
Livius
#15800
üzenetére
Köszönöm, ez érdekes oldal.
Annyi fenntartásom van az olyanokkal, akik egyetem mellett oktatnak, vagy hivatásos tanárok, hogy én egyetemi tanulmányaim során azt tapasztaltam, hogy szinte senki sem volt igazán tisztában azzal ami zajlik valójában a versenyszférában, a multinacionális cégek berkein belül. A tanárok remekül oktatták a leadandó elméleti anyagot, és fogalmuk sem volt, hogy valójában mely skillek az igazán fontosak a munka életében, mivel ők maguk még nem dolgoztak olyan helyen, vagy nagyon rég, keveset. És így nem tereltek annyira jó irányba, mint ahogyan egy tapasztalt versenyszférában dolgozó mérnök tudott volna. Ez lehet, hogy az IT-ban nincs annyira így, de a gépészmérnöki képzésben nagyon is.
De bizonyára az IT-ban is így van, hogy nem feltétlenül az a jobb programozó, aki az adott programnyelvet jobban ismeri.
-
válasz
Livius
#15782
üzenetére
Ezt a template programozást arra érted, hogy előre fel van töltve pár típus struktúra különböző SPI controllerek fv pointereivel meg konfigjaival?
Nem, hanem pl. az MXC_SPI_BUF_RX makróra, ahol a makróparaméter egy típus.
Más kernel forrásban úgy emlékszem van olyan postfix sokszor a változóknak, hogy _u64, _s32, ez itt egyáltalán nincs, pedig nálunk erre nagyon lenne majd igény.
NE!
Szerintem rosszul emlékszel, mert Linus véleménye erről az, hogy "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer" - és ez nyilván érvényes a változókra is és pont ez a félreértett hungarian notation, amiről az elején beszéltem - Simonyinak esze ágában sem volt ilyen hülyeséget kitalálni. Amit ő kitalált, az az, hogy szemantikus típusjelentést rakjon bele a változónévbe. Primitív és némileg erőltetett példa, de mondjuk koordinátáknál az X és az Y koordináta is int (vagy float vagy akármi), szóval a fordítóprogram szempontjából tök egyforma típus, de mégis teljesen más a jelentésük, amit érdemes jelezni a programozónak, szóval a pos_x és a pos_y az legitim használata a HN-nek - a s32_pos viszont nem.Figyelmes olvasók itt rámutathatnak a hozzászólásom elejére, ahol az a makro olyan függvényeket generál, mint spi_imx_buf_rx_u8 meg spi_imx_buf_rx_u32. Igen, ez itt a kivétel, ahol van értelme belekódolni a függvénynévbe, mert a függvény lényege (és megkülönböztető eleme) az, hogy milyen értékkel dolgozik, az soha, semmilyen körülmények között nem merülhet fel, hogy az spi_imx_buf_rx_u8 mégis inkább egy előjeles 16 bites integerrel dolgozzon.
-
válasz
Livius
#15771
üzenetére
de azért én erre nem merném kimondani, hogy annyira patent, közelebb áll a vacakhoz mint a tökéleteshez
Pedig ha megnézed, van benne template programozás is, az szerintem jópofa.
A nevezéktannál meg jól látszik, hogy a következő szabályok vannak:1. nincs camelcase, underscore van
2. minden függvény neve az a scope, ahol érvényes
3. a függvénynevekben csak tök elterjedt (tx, rx, clkdiv, buf) illetve a domainspecifikusan egyértelmű (pl. wml) rövidítéseket használ, minden más ki van írva
4. ha boolt adnak vissza, akkor eldöntendő kérdés a függvény neveMost így gyorsan ránézve a kódra nem nagyon látszott, hogy lenne benne különösebben nehezen érthető dolog.
-
válasz
Livius
#15768
üzenetére
Függvényre az a naming convention, amit írtál feljebb is, hogy értelmes kereteken belül a függvény legyen rövid, a függvény egyetlen dolgot csinál, és az a neve, amit csinál. Ezen felül megegyeztek valami olyan dologban, hogy:
a) fv nagy betűvel kezdődik, változó kis betűvel és amúgy camelcase, plusz változó esetén a pointer első betűje mindig p és beszédes (tehát pl az a pointer (array), ami random inteket tartalmaz az pArrRandomInts)
b) camelcase, függvények kis betűvel, változók aláhúzással kezdődnek, amúgy ugyanaz, mint az a)
c) bármi hasonló, ami eszetekbe jutEz tényleg ízlés kérdése, találjátok ki együtt, valami olyat, ami mindkettőnknek szimpatikus.
-
válasz
Livius
#15768
üzenetére
De nektek egyébként muszáj C-t használnotok? Nem tudom, hogy a libraryk milyen formátumban vannak, de alapvetően C++-ból tök simán lehet C-s libeket használni, de ha valami nagyon elborult saját bináris formátum, akkor az is létező opció, hogy C++-ból C kódot generáltok (clang biztosan tud ilyet, meg szerint g++ is) és azzal etetitek az ő fordítójukat.
-
válasz
Livius
#15765
üzenetére
Szerintem nagyon kevés benne a kernel-specifikus cucc, a nagyobb része általános C programozás.
A változónevek meg... hát annyi, hogy értelmes ÉS rövid legyen, ennél sokkal specifikusabban nem nagyon lehet semmit sem mondani, mert ami ennél többet mond, az mind olyan változónevezési módszertan, ami plusz infókat rak a változónévbe valamilyen rendszer szerint (mint pl. a rettenetesen félreértett Hungarian notation), itt meg arról van szó, hogy ne legyen benne ilyen. Ha meg példa kell, akkor ott a komplett kernelforrás (és ez a guide egyébként ezért is jó, mert egy valós, több évtizedes, több ezer ember által írt hatalmas kódbázisra működik, amiben nagyon-nagyon sok dologra van példa, méghozzá jó példa, mert ide vacak kód nem kerül be).
-
válasz
Livius
#15760
üzenetére
Lényegen nem változtat sokat, clean code plusz valami naming convention és ennyi, mivel oop nincs, ennél sokkal messzebb nem fogsz jutni, ezért nem fogsz találni direkt
C-re kitalált stílust, mert nem igazán van miről beszélni.Ui: jobban belegondolva legjobban akkor jársz, ha használsz valami auto formattert (itt a cpp-hez kitalált dolgok mind tökéletesen működnek C kódra is), a többi meg naming convention. Az meg tényleg az, amit akarsz, csak legyen logikus és konzekvensen végigvezetve.
Ami ezen felül van C-ben, az meg már gyakorlatilag business logic, ott már plane nincs helye stílusnak. -
válasz
Livius
#15753
üzenetére
C az a cpp valós részhalmaza, nem igazán szoktak hozzá külön style-ok lenni, sőt, általában ha C+PC a kombó, akkor max legacy vagy valami nagyon speciális esetben van C használva, sokszor cpp vagy egyéb kódban libként behúzva, tehát jobb esetben ugyanaz a style, mint a cpp-nél, rosszabb esetben pedig vagy nincs, vagy már senki sem emlékszik rá, mert valamikor a 80-as években írta a random Béla, aki olyan régen ment nyugdíjba, hogy már az is nyugdíjba ment, aki utoljára tudta a telefonszámát.
-
-
pmonitor
aktív tag
válasz
Livius
#15740
üzenetére
Látod barátom, tényleg rossz helyen járok, ha egy perfekt angolos nem tudja lefordítani angolra a magyar hibaüzenetet. Egyébként mint írtam, megoldottam nélkületek is.
Egyébként a fórumszabályzat is azt írja:
A Szolgáltatással kapcsolatos főbb szabályok az alábbiakban kerülnek kifejtésre.
.
.
.
A Felhasználói Tartalom nyelve a magyar, ettől eltérni csak indokolt esetben lehet.Amúgy meg amit kell, azt megértem angolul is.
-
pmonitor
aktív tag
válasz
Livius
#15727
üzenetére
Kezdésnek?
Szted. itt mit használok, ha nem azt?
Nagyon kezdőnek nézel engem, mert nem vagyok programozó(hála isten). Legalábbis nem mondom magam annak. Mert vannak, akik csak állítják magukról, hogy programozók.
-
pmonitor
aktív tag
válasz
Livius
#15722
üzenetére
>Általában amikor feltételezzük hogy lassú valami a .Net ben vagy valamiben a végén mindig kiderült hogy a user a hülye
Köszönöm a megtiszteltetést
Ezt légyszíves csináld már meg úgy, hogy a C# gyorsabb legyen. Ha megmutatod a gyorsabb kódot, akkor beismerem, hogy tényleg hülye vagyok, mert csak nem tanultam meg a .Net-ben azokat a dolgokat, amitől gyors lesz.
Szerk.: egyébként ez nem particionáló/formázó program.
-
pmonitor
aktív tag
válasz
Livius
#15638
üzenetére
Próbálgatom szárnyaimat. Az a baj, hogy angolul az írott szöveg lényegét megértem, de önálló mondatot nem tudok összerakni. Meg a szavak szinonimái is 1 kicsit gondot okoznak. Úgyhogy marad a kevert angol/magyar. De pl. a QuickSort-ot meghagytam angolul.
-
pmonitor
aktív tag
válasz
Livius
#15593
üzenetére
Nem megyek el dolgozni 1 multihoz sem, mert én nem vagyok programozó, csak programoz(gat)ok. Ezen kívül teljesen igaz, amit írsz, szóról-szóra. Viszont attól a C# nem fog begyorsulni(főleg, ha ragaszkodik valaki az OOP-hoz). Egyébként én azt az utat szoktam választani, hogy ha valamit nem tudok megoldani(vagy kritikus helyen lassú) C#-ban, akkor C/C++-ban készítek 1 natív .dll-t, és azt használom a C# programommal. Ilyen pl. ez a programom is. Ugyanis egy másik alkalmazásnak nem minden adatához enged hozzáférni .Net-ben. De a fő programom C#-ban készült. A C# nagy előnye, hogy nagyon sok mindent meg lehet csinálni 1-2 kattintással, meg hogy áttekinthetőbb kódot lehet benne írni. De ez a sebesség rovására megy. Assembly és C esetén meg pont fordítva van.
@Ispy: Fordítsuk meg a dolgot: szerinted az igazi programozók csak C#-ban programoznak? De a tény az tény.
-
-
pmonitor
aktív tag
válasz
Livius
#15458
üzenetére
A kérdésem az hogy portableként bármilyen setup.exe nélküli Java progit hogyan tudsz futtatni?
Azért tegyük hozzá, hogy kell hozzá a nem kis méretű framework. Igaz, hogy most már alapból benne van a win-ben. De nem volt ez mindig így. Az xp-re pl. külön kellett telepíteni.
Ettől függetlenül nekem is tele van a t...m a több megás telepítendő programokkal. Ezek csak azért ilyen méretűek, hogy csili-vili legyen a progi, és hogy (ugyan törhetetlen progi nincs) minél jobban védjék törés ellen. Arról nem is beszélve, hogy teleszemetelik a registryt. Ha csak az én fő programom nézzük(1D vágás ), ez egy 14 kb-os .exe-ből, és egy 22 kb-os .dll-ből áll. Telepíteni nem kell. Nézd meg pl. a hasonló free programot. Biztosra veszem, hogy telepíteni kell(azért, mert évente meg kell újítani a licence-t). És a file sem hiszem, hogy 35 kb. körül van. Bár nem próbáltam ki. Minek? Azért, hogy telepítés után eltávolítsam? Erről beszélek. Mondjuk a mai hardveren igaz, hogy elfér, de szinte minden program telepítéssel működik. Azért a sok "nagy" sokra megy.
-
pmonitor
aktív tag
válasz
Livius
#15313
üzenetére
a gcc-nek nem az a feladata hogy a te C nyelvedet alakítsa alternatív jobbra
Sztem az lenne a feladata, hogy amit az alkotó C-ben ír, azt hajtsa végre a megfelelő beállítás mellett. Tehát, ha az alkotó arra utasítja pl. a -Ofast-al, hogy optimális kódot állítson elő, akkor azt kellene csinálnia. Nem véletlenül írta kovisoft:
Ez a gyakorlatban úgy szokott történni, hogy megnézed, milyen kódot generált a sebességre optimalizált fordító, átírod olyanra, ahogy szerinted gyorsabb lenne, kipróbálod, majd nyugtázod, hogy a te verziód lassabb lett, és mégis a fordító tudta jobban.
Ő is a sebességre optimalizált fordítóra hivatkozik. Akkor szted mit jelent a sebességre optimalizálás, ha semmit nem alakíthat át? Tehát úgy optimalizáljon, hogy közben mégsem optimalizál? Ilyen alapon 2 darab XOR utasításnak kellene lennie, mert szted nem "nyúlhatna" hozzá a C-ben írt kódhoz? Ugye ezt nem gondolod komolyan? Sztem meg kötelező hozzányúlnia a sebesség érdekében, ha a sebességre optimalizálást adták meg neki.
-
pmonitor
aktív tag
válasz
Livius
#15310
üzenetére
Sztem félreértetted a kérdésem. Az első formulát írod forráskódba. Ebből kellene észrevennie a fordítónak, hogy a második formulára alakítható a forráskód. Tehát az első kódból is ugyanazt kellene generálnia, mint a másodikból. Ezt nem ismerte fel.
szerk.: az összeadás-kivonás lassabb, mint a XOR.
-
Livius
őstag
válasz
Livius
#15307
üzenetére
Igazad van, túl okos a gcc, és a hülye fv-re látta hogy nem fog felesleges lényegtelen asm műveleteket generálni. Raktam bele érdemben egy return-öt, és valóban az optimalizálás a két kódra nem ugyan az, láthatóan az XOR változat jobban tetszik neki, az optimalizáció során, nem véletlen persze.
első: https://godbolt.org/z/crMWsM
második: https://godbolt.org/z/brz64Y -
-
#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. -
#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. ;-) -
#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 -
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.
-
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.
(Mondjuk ő - nagyon helyesen! - nem tiltja a gotot - már egyébként csak emiatt is javasolnám, hogy olvasd át.)
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Bomba ár! HP EliteBook 840 G4 - i5-7GEN I 16GB I 256GB SSD I 14" FHD Touch I Cam I W10 I Garancia!
- Azonnali készpénzes nVidia RTX 3000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- Bomba ár! Dell Latitude E7250 - i7-5GEN I 8GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- Új MSI 17 Raider GE78 QHD 240Hz i9-13980HX 24mag 32GB 2TB SSD Nvidia RTX 4090 16GB 175W W11 Garancia
- AKCIÓ! Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
Állásajánlatok
Cég: FOTC
Város: Budapest