-
IT café
Új hozzászólás Aktív témák
-
opr
veterán
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.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
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.
[ Szerkesztve ]
DRM is theft
-
dabadab
titán
válasz Livius #15273 üzenetére
Jogos, tényleg, a második helyett ezt akartam linkelni: https://oska874.gitbooks.io/process-scheduling-in-linux/content/chapter10.html
DRM is theft
-
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[ Szerkesztve ]
-
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. ;-) -
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.[ Szerkesztve ]
-
válasz Livius #15294 üzenetére
ne engem győzködj, nem én írok asm-ben programot.
én csak írtam egy lehetőséget, amivel az asm programozást egyszerűsíteni lehet.#15287 "Aztan majd fejlesztem tudasom mas prognyelvekkel is, ha az Univerzum ugy akarja": erre alkalmas a javaslatom.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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/brz64YGigabyte GA-Z170-D3H, Intel Core i7-7700K, Corsair Vengeance 2x8GB DDR4-3600MHz, Intel 545s 256GB SSD, EVGA GeForce GTX 1060 GAMING 6GB
-
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.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
dabadab
titán
válasz Livius #15458 üzenetére
Azért szeretném megemlíteni, hogy a windowsos desktopos fejlesztéseken túl is van élet, sőt, tulajdonképpen az ilyen windowsdesktopos dolgok azok, amik egyre jobban szorulnak háttérbe és már most is csak egy elég kicsi szeletét adják a szoftverfejlesztői melóknak.
DRM is theft
-
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.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
pmonitor
aktív tag
válasz Livius #15744 üzenetére
Szted. ezt az oldalt hogy találtam meg(és vettem értelmét), ha nem tudnék angolul googlezni?
Ha annyira indokolt eset, akkor beszélgessetek csak angolul.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
opr
veterán
válasz Livius #15749 üzenetére
Hát, ilyenből univerzálisat nem fogsz találni, mert nem igazán létezik. Talán annyi, hogy amennyire illeszthető C-re, clean code, meg a guglis stílus/nevezéktan [link] egyre népszerűbb, de ez is olyan, hogy van, aki imádja, van, aki meg a haját tépi tőle.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
opr
veterán
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.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
opr
veterán
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.[ Szerkesztve ]
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
dabadab
titán
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).
[ Szerkesztve ]
DRM is theft
-
dabadab
titán
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.
DRM is theft
-
opr
veterán
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.
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
dabadab
titán
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.
DRM is theft
-
dabadab
titán
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.
[ Szerkesztve ]
DRM is theft
-
addikt
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.[ Szerkesztve ]
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Azonnali VGA-s kérdések órája
- Call of Duty: Modern Warfare III (2023)
- Ezek a OnePlus 12 és 12R európai árai
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- LEGO klub
- MG4 menetpróba
- Házimozi haladó szinten
- Mit tehetsz jogilag, ha átvertek, megkárosítottak a Hardveraprón?
- Kerékpárosok, bringások ide!
- Autós topik
- További aktív témák...
- ZOTAC GeForce GTX 1080 AMP Edition 8GB GDDR5X 256bit
- Filmes gép gyűjtemény
- Nikon D5000 + AF-S DX NIKKOR 18-105 mm
- Bontatlan Seagate & Western Digital HDD-k 3TB - 12TB -ig - Számla + Garancia, Ár alatt! BeszámítOK!
- DJI Mini 4 pro FMC drón - 3 akku, RC2 táv, 2 táska, Filterek, 2025. decemberig garancia, DJI Care