-
Fototrend
Új hozzászólás Aktív témák
-
-
K1nG HuNp
őstag
válasz
pmonitor
#16963
üzenetére
ez pont egy ugyanolyan kib*szott szakma mint a többi, mégis mi a t*kömért tenné fel bárki az internetre a személyes adatait? hogy a fórumos vérpistikék egy csúnyább beszólás után még élőben is zaklassák? hát nem kösz
nagyon erős komplexus van benned, mintha te is mindig igazán nagybetüs programozó akartál volna lenni de nem jött össze (bár manapság ez amugy is rámondásos alapon megy kb) és most inkább másokat szapulsz.
szívd fel magad matekból, fizikából és tessék, lehet menni BME-re meg ELTE-re, államilag finanszírozott, az majd kicsit hátha kikupál és utána nyugodtan mutogathatod mindenkinek a diplomád, segítek, a kutyát sem fogja érdekelni de legalább hátha megnyugtatod magad picit hogy na igen mostmár vagy valaki.
---
mindegy amúgy, sztem picit tedd le a gépet menj karácsonyozz a családdal, hátha jobb kedvre derít, ezt a topikot meg rángassuk vissza a te előtti időkbe ahol actually arrol volt szó amit a címe is jelez -
cattus
addikt
válasz
pmonitor
#16960
üzenetére
Lehet én siklottam el felette, de te felvállaltad a teljes neved / munkahelyed / lakcímed / TAJ számodat? Mert enélkül sajnos nem tudok bízni az ide linkelt kódjaidban. Kérlek mihamarabb fedd fel személyazonosságodat, enélkül ugyanis kénytelen leszek feltételezni, hogy vaj van a füled mögött.
-
Silεncε
őstag
válasz
pmonitor
#16955
üzenetére
Ők vajon miért is nem titkolják, hogy hol dolgoznak? Sztem. aki olyan helyen dolgozik/dolgozott, azt nyugodtan felvállalhatnák itt a fórumon is. Vagy vaj van a fülük mögött(rossz úton járnak), hogy nem merik megtenni? Vagy, vagy, vagy...
Na mostmár tényleg elmész a francba, már ne is haragudj
A pénz keresést meg azért hoztam szóba, mert ha vki(k) ebből gazdagodik meg, akkor sztem számon lehet kérni teljesítményt is. Mint ahogy írták:
>Ha fizetsz erte, az mas, akkor szamon kerhetsz teljesitmenytHonnan jössz te ehhez egyébként? Te fizeted itt bárkinek a fizetését?
-
axioma
veterán
válasz
pmonitor
#16952
üzenetére
Mintha mar kertem volna hogy hanyagolj. Szted hol programozo vagyok hol nem, de azert probalsz tovabbra is lejaratni... az amugy a te onkenyes hatarido-kijelolesednek szolt, hogy hany napot, orat teszek bele. Azota is ott van felkeszen de tuti nem nyulok tobbet hozza ahogy viselkedsz.
-
Drizzt
nagyúr
válasz
pmonitor
#16955
üzenetére
"Ők vajon miért is nem titkolják, hogy hol dolgoznak? Sztem. aki olyan helyen dolgozik/dolgozott, azt nyugodtan felvállalhatnák itt a fórumon is. Vagy vaj van a fülük mögött(rossz úton járnak), hogy nem merik megtenni? Vagy, vagy, vagy..."
Ez egy anonim forum, jo reggelt! Es egyebkent az en allasom peldaul rendelkezik arrol eloirasokkal, hogy a munkammal kapcsolatban publikusan milyen szabalyok szerint nyilvanulhatok meg. Beleertve az internetes megjelenest is.
A peldad teljes hulyeseg, nincsen ott az embereknel a PH! nickjuk.![;]](//cdn.rios.hu/dl/s/v1.gif)
Anonym forumokon nem hinnem, hogy reklamoznak kik ok, kulonben mit keresnenek egyaltalan anonim forumon? -
Drizzt
nagyúr
válasz
pmonitor
#16952
üzenetére
"A pénz keresést meg azért hoztam szóba, mert ha vki(k) ebből gazdagodik meg, akkor sztem számon lehet kérni teljesítményt is."
Számon is szokták kérni. És a sikeres projektek jól szoktak teljesíteni. Ahol a jól teljesít nem azt jelenti, hogy nincsen olyan rész, amit ne lehetne gyorsítani rajta. Viszont ezek a gyorsítások nem járnak jelentősen érezhető különbséggel a felhasználó szemszögéből. Ilyetén módon pedig feleslegesek(senki nem akar olyan optimalizálásért fizetni, amiből nem érzékel semmit), pazarlások a megrendelő szemszögéből. -
válasz
pmonitor
#16952
üzenetére
Fel tudsz mutatni olyan munkát amit magyar emberek milliói használnak mindennap. A fórumról több kolléga is olyan dolgokan dolgozik / dolgozott mint valamilyen nagy magyar vállalat webshopja vagy valamelyik mobilbank applikáció és hozzá tartozó backend.
Szerintem erre gondolt a kolléga.
A C Sharp pedig tényleg ingyenes és van hozzá fizetős support, értsd ha nagyon sokat fizetsz a Microsoftnak akkor az expert akár karácsony este felül a repülőre, ideutazik lokálisan és megoldja a gondod.
Tényleg ne kezdjük uj loopba.
-
martonx
veterán
válasz
pmonitor
#16942
üzenetére
"Vagy hogy hogy nem tudja 'kend ezt megcsinálni?" - tekintve az általam linkelt kiindulási alapot, nem a tudással van a bajom, hanem az idővel
Te meg látványosan unatkozni látszol, gondoltam feldobok egy feladatot, amivel végre igazán hasznossá teheted a szabadidődet, és végre olyat programozhatsz, amit nem megmosolyognak a többiek, hanem elismerően csettintenek. Mondjuk nem lep meg, hogy inkább passzolod, jogos, csináld meg inkább még négyszer az itoa-t. -
pmonitor
aktív tag
válasz
pmonitor
#16939
üzenetére
Ért 1 meglepetés! Ha Itt az int.TryParse()-k helyett az itt lévő Int_Parse()-t használom, akkor C#-ban jelentősen javul a sebesség(~22-ről ~18 sec-re). Tehát ~1 sec-el gyorsabb a C++-nál(mondjuk ez 60 misi string konvertálásánál nem eget verő különbség, de azért mégis...). Azért azt hozzá kell tenni, hogy a C# kód a File.ReadAllLines() metódussal olvassa be a file-ból az adatokat. Ez azonban nincs benne az időmérésben. Ha ezt is bele számoljuk, akkor máris az jön ki, hogy a C++ set<>-je és a C# HashSet<>-je sebessége majdnem ugyanaz. Viszont nem tudom, hogy a C# string -> szám konvertáló metódusait hogy szúrhatták el ennyire? Még szerencse, hogy ezt azért lehet optimalizálni. Mert pl a szám -> string konvertáló metódusok optimalizálására esély sincs C#-ban.
Majd ha több időm lesz, akkor ezt módosítom a doc_1.php-ben.
------------------------------------------
@martonx:
Azt is mondhatnám, hogy Csak Ön után!
Vagy hogy hogy nem tudja 'kend ezt megcsinálni?
Még 2012-ben készítettem egy ilyen minta kódot Vb.Net-ben managed-ben! Mondjuk ez nem HTML Rendering, csak példának hoztam fel. Egyébként a managed kódot elfelejtettem az elő hsz-emben. Tehát C#-ban nem csak a .Net áll a kód mögött, hanem a managed környezet is. Szóval managed-ben is lehet viszonylag gyors kódot írni. Bár itt csalós dolog is van. Sok memóriaszemét van, amíg a GC le nem fut. Ez miatt is látszhat gyorsnak 1 C# kód. Mindenesetre nem én fogom megváltani a világot. Bár azért C-ben az itoa() és az atoi() függvényeket sikerült optimalizálnom. C#-ban csak a Parse() metódust. Sztem. ez is valami. Az, hogy nem vagyok programozó, az azt is jelenti, hogy hogy én meg tudom csinálni azt, hogy csak azzal foglalkozom, amivel szeretnék foglalkozni. A programozó meg azzal foglalkozik, amivel muszáj(mert ugye a muszáj nagy úr
). Ezért hiányolom azt, hogy akik programozóknak mondják magukat, nem hozzák nyilvánosságra, amit alkottak(mert olyan nincs, hogy egy programozó úgy lett programozó, hogy nem alkotott semmit). Cattus azt írta, hogy nem érdekli, hogy én mit várok el. Ezzel nincs is gond. De akkor az ilyenek se várják el, hogy elhiggyem/elhiggyék, hogy programozó. -
martonx
veterán
válasz
pmonitor
#16939
üzenetére
Ha ennyire ráérsz, és szeretnél egy igazi való világbeli problémában segíteni, akkor írj egy managed (csak C#-os, azon belül is .Net Standard 2.1-es) HTML to Image konvertert (és nyilván annál jobb, minél optimalizáltabb).
Ez jó kiindulási alap: ArthurHub/HTML-Renderer: Cross framework (WinForms/WPF/PDF/Metro/Mono/etc.), Multipurpose (UI Controls / Image generation / PDF generation / etc.), 100% managed (C#), High performance HTML Rendering library. (github.com)
Végre valami hasznosat programozhatsz!
Garantálom, hogy nem csak én, de több ezer másik C# fejlesztő is használni fogja, amit csinálsz, és nagyon hálásak leszünk érte!
-
martonx
veterán
válasz
pmonitor
#16886
üzenetére
"Ha van egy autóm, amiben nekem nem tetszik valami, akkor tervezzem át, küldjem be a gyártónak, és várjak, hogy elfogadják-e, mi?"
Ez a példa ott megy borzasztóan félre, hogy egy autónál még a garanciát is bukod, ha elkezded buherálni. Ellenben az Open source programnyelvek azért open source-ok, hogy BÁRKI jobbá tehesse, azaz ezeknél szinte elvárás, hogy ha valamit jobban tudsz, akkor már küldöd is a PR-t github-ra. Minden más csak okoskodás.
-
axioma
veterán
válasz
pmonitor
#16908
üzenetére
Akkor ha en letoltottem a programod [tobb valtozatban, sot webkod hibakeresesedhez tobbszor], nyilvan a te ke're'sedre anno mielott hirhedt lett volna a nick-ed, es emiatt me'g honapokra kint volt egy bejegyzesed ugyanott, hogy en milyen szemet vagyok, en ezek utan me'g a beloled kaptam ihletet csoportba is be vagyok szamolva? Hihetetlen vagy.... probaltam kimaradni de ez mar tul sok volt a jobol.
-
válasz
pmonitor
#16908
üzenetére
"Egyébként, ahogy látom, a programjaim töltögetik "lefelé", és nagyon bízom benne, hogy valaki(k)nek megmozgatják a szürkeállományát, és valami eszükbe jut a programjaim nézegetése közben. Valami ihletet adok Nekik. Ezért hálás köszönetem, azoknak, akik letöltötték/letöltik a programjaimat. Őket légyszíves ne s...d már le, ha megkérhetlek."
Ezt nem értem, hogy keverted ide. A loopolásról meg arról beszéltem, hogy Te milyen módon minősíted azt a sok mérnököt aki ezzel foglalkozik, mert a te atoi implementációd gyorsabb csak nem annyira robosztus mint a fordító által adott.Két dologról beszélsz. Én pedig erről, hogy ezt fejezzük be mert ha kérhetem.
-
-
válasz
pmonitor
#16894
üzenetére
Nem vagy szakmabeli és ami itt folyik demagóg, hogy ezen a témán loopolsz. Nincs igazad. No offense, és semmi személyeskedés csak, hozzuk egy szintre a két véleményt.
Mindent fikázni is és saját magad promózni, anélkül, hogy értékelhető dolgot nem tettél le az asztalra (pl. atoi implementációdra egy merge a gcc-ben) - nem jó ötlet. Nem véletlenül vannak ezek a dolgok így. C-t hasonlítani C sharpal pedig nem tudsz.
Kérlek ezt tartsd szem előtt.
-
Silεncε
őstag
válasz
pmonitor
#16896
üzenetére
Na mesélj, hogyan. Okíts, mester
Edit: a CGI jogos, bár nem hiszem, hogy meg tudsz benne írni egy React szintű webalkalmazást (de ha még meg is, mi a francnak ennyit szevedni vele, ha egyébként van rá más megoldás?)
A másiknak a kódjába belenéztem, nekem az úgy tűnik, hogy ott magát az appot összerakod C++-ból, de az a kliensen attól még ugyanúgy JSt fog futtatni.
-
Silεncε
őstag
válasz
pmonitor
#16886
üzenetére
Ha most lennék fiatal, és programozó szeretnék lenni, akkor én 2, esetleg 3 programnyelvet sajátítanék el nagyon. Az asm-ot, a C-t, esetleg a "mezei" C++-t(nem a VC++-t). Ezekkel mindent meg lehet csinálni, és eszközt adnak a kezembe az optimalizálásra is.
Sok sikert kívánok hozzá, hogy ezekben megírj egy webappot vagy egy mobilappot (utóbbit mondjuk még talán meg lehet...). BE fejlesztéshez is kitűnő választás mind. Oh, wait..
Egyébként meg továbbra is ott a lehetőség, hogy elkezdjed beküldözgetni a sokkal gyorsabb kódjaidat és megmutasd a nagy programozóknak, hogy milyen hülyék mindannyian.
-
-
dabadab
titán
válasz
pmonitor
#16886
üzenetére
Elég szomorú, hogy az évtizedek alatt senkinek sem jutott eszébe optimalizálni az alapvető függvényeket/metódusokat sem.
Mert mindenki hülye és csak te vagy helikopter.
Egyébként sikerült már olyan atoi()-t írni, ami megcsinálja azt, amit a szabvány elvár tőle? Nem? Hát akkor meg mire ez a nagy arc? -
-
válasz
pmonitor
#16865
üzenetére
Hányszor kell sztringet szamma konvertálni a tőzsdén?
Deszerializacional (pl. áttolsz a hálózaton egy rakás adatot, es utána a memóriába akarod rakni, mint szám) nyilván nem atoi-t használnak meg parseInt-et.
Amikor meg megjelenitesz egy csomó számot, pl. egy C# GUI-nal, arra pl. az Int32.toString() tökéletes (nagyon gyors). Ha mondjuk egy képernyőn van 2000 szám, amik másodpercenként 2* változnak, az 4000 konverzió / másodperc, az nagyon alacsony szám.
-
-
martonx
veterán
válasz
pmonitor
#16775
üzenetére
"A fejlesztők úgyis elkergetnének, hiszen a programozókat nem érdekli a sebesség, és a méret/helypazarlás(lásd az elején belinkelt sztanozs hozzászólást -- is)."
Tessék egy link, hogy a nyelvek fejlesztőit mennyire nem érdekli a teljesítmény: [link]Mondod ezt úgy, hogy soha nem próbáltál meg PR-t beküldeni. Gratulálok
-
Drizzt
nagyúr
válasz
pmonitor
#16775
üzenetére
Nagyon jol latszik, hogy dolgozni nem dolgoztal proramozokent. Ugyanis ott jellemzoen nem ezek a fontos problemak. Sokkal tobb gondot okoz az allandoan valtozo requirement lekovetese ugy, hogy a meglevo funkcionalitas erintetlen maradjon a bugfixek es uj fejlesztesek kapcsan. Illetve gyakran nagyon fontos, hogy a user minel hamarabb el tudjon kezdeni hasznalni valamit, mert akkor fog tudni rajonni, hogy mit nem gondolt vegig amikor megfogalmazta a korabbi requirementjeit.
Jobbnak gondolt programozok alapelve, hogy "avoid premature optimization". Ennek minden szava fontos. Mert nem arrol van szo, hogy ne optimalizalj, hanem arrol, hogy ne a szerint optimalizalj, hogy mi lesz szerinted gyakran hasznalt es kritikus. Ugyanis sosem tudod elore biztosan kitalalni, hogy a usernek mi lesz a fontos. Altalaban elore o maga sem tudja. Nyilvan van amit muszaj optimalizalni, de jol meg kell valasztani, hogy mit, mert aranytalanul draga.
Ha mondjuk valamit egy csapat szarraoptimalizal 1 ev alatt es amiatt fele annyi hardverkoltseg lesz eves szinten, az a megrendelonek nem igazan deal, mert egy(, nem egy csapat!) programozo eves koltsege legyen mondjuk 250000 dollar, fele akkora vm elofizetese meg mondjuk 300 dollar sporolas/honap, azaz ~4000 dollar/ev.
Sokkal fontosabb az, hogy a programozo meg tudja allapitani, hogy mi az, ami tenyleg lassu(monitoring, profiling) es azt hamar elfogadhatora optimalizalja.
Ami igazan fontos resze a lehetseges teljesitmenynek, az foleg architekturalis kerdes, abba erdemes tobb idot beletenni. Mikrooptimalizalasnak ott van ertelme, ahol az tenyleg bizonyitottan szukseges. -
#25954560
törölt tag
válasz
pmonitor
#16771
üzenetére
mondjuk ennek egy resze az oktatasban is keresendo es/vagy abban h nagyon sok programozonak elkepzelese sincs milyen eroforras-igenye van annak, amit megir. egyaltalan, mi tortenik, amikor lefut a programja. egyaltalan mitol fut
ez nem feltetlenul baj, en sem vagyok tisztaban a kulonfele oktanszamu benzinek kopogasturesevel, attol meg tudok vezetni. viszont nem is tervezem at a kocsim gyujtasat es kompresszioviszonyat -
dabadab
titán
válasz
pmonitor
#16771
üzenetére
Éppen most készítem ezt a dolgot(még nincs teljesen kész). De az látszik, hogy a stringet számmá konvertáló beépített függvények C-ben ~19, míg C#-ban ~68 sec. alatt futnak le, miközben könnyedén lehet ~10 sec. körüli futásidőt elérni ugyanarra a feladatra(inputra).
Ja, gyorsabban lefut, csak nem működik meg baromira nem azt csinálja, amit a C szabvány (ez a draft, a végleges csak fizetős formában elérhető, de abban is ugyanez van) előír. Érdemes megnézni a szabványt meg mondjuk a GNU C lib forráskódját aztán összehasonlítani a tieddel, amiből pl. teljesen hiányzik a locale-kezelés.
Szóval igen, érdemes nem azt gondolni, hogy rajtad kívül mindenki hülye, mert kiderülhet, hogy pont fordítva van. -
-
kovisoft
őstag
válasz
pmonitor
#16744
üzenetére
Ha ellenpélda kell, csak oldjuk meg az 5*x-2^32>x, 2*(5*x-2^32)<2^32 egyenlőtlenségeket, és máris találunk pl. egy x=1073741825 megoldást, aminél az 5*x túlcsordul és 1073741829 lesz, ami nagyobb x-nél, ennek 2-szerese már nem csordul túl. Tehát ha a végére teszünk még egy digitet és az input pl. 10737418250, akkor ennek a túlcsordulását nem fogja detektálni.
-
kovisoft
őstag
válasz
pmonitor
#16733
üzenetére
Ezzel szerintem megint az lesz a baj, mint a korábbiakkal, azaz hogy a túl nagy vagy túl kicsi számokra is visszaad valami látszólag értelmes integert. Persze most megint visszatérhetünk oda, hogy az atoi() mit is kell visszaadjon invalid inputra. De a kódban látom az igyekezetet, hogy észrevegye a túlcsordulást. Ugyanakkor ezt úgy próbálja megtenni, hogy azt nézi, hogy az aktuális részösszeg 10-zel szorozva negatív lesz-e. De mi van pl. a 999999999x esetén? Az utolsó előtti számjegynél a részösszeg 999999999, ez 10-zel szorozva ugyan túlcsordul, de a túlcsordult érték pozitív lesz. Tehát nem veszi észre a túlcsordulást és visszaad valami random integert.
-
kovisoft
őstag
válasz
pmonitor
#16718
üzenetére
Csak gyorsan átfutottam, úgyhogy nem biztos, hogy igazam van, de szerintem INT_MAX-nál nagyobb vagy INT_MIN-nél kisebb számokra továbbra is vissza tud adni valami szemetet. Az i 10-zel szorozgatva ilyenkor egyszercsak túlcsordul, aztán akármi is előállhat a ret-ben.
Az INT_MIN esetet most nem látom teljesen át, gondolom, kipróbáltad. A kódból nekem úgy tűnik, hogy INT_MIN esetén (mivel nemnegatív számokkal dolgozol, ezért) túlcsordul, de lehet, hogy aztán valahogy lekezeled ezt a túlcsordulást.
Azért az az
strcmp(arr, "2147483647")eléggé feltételezi, hogy 32 bites intjeid vannak... -
-
pmonitor
aktív tag
válasz
pmonitor
#16670
üzenetére
>az itoa()-nak a visszatérési értéke lehetne olyan mutató, ami a karakterláncot lezáró '\0' karakter utánra mutat.
Ezt itt meg is valósítottam. A függvény hívása/használata:
int main()
{
char str[128]; //arra figyelni kell, hogy elegendő helyet foglaljunk le
char *str_1 = pitoa(-2138, str, 10); //itt str_1 az str[6]-ra mutat(ha jól számolok)
char *str_2= pitoa(21526, str_1, 10);
char* str_3 = pitoa(568712, str_2, 10);
printf("%s\n%s\n%s\n", str, str_1, str_2);
return 0;
}Sztem. hasznos egy ilyen funkció.
-
Silεncε
őstag
válasz
pmonitor
#16655
üzenetére
Egy programozó is el tud akadni valamivel? Én azt hittem, hogy azért tanultak olyan sokat, hogy a szakterületükön ne akadjanak el semmivel. De lehet, hogy tévedek/tévedtem.
Megint kezdődik? Tök jó lenne, ha nem itt élnéd ki a kisebbségi komplexusodat, mostmár rohadt unalmas
-
dqdb
nagyúr
-
martonx
veterán
válasz
pmonitor
#16616
üzenetére
"De sztem. az elég sokszor előfordul, hogy tömegesen kell számokat szövegre konvertálni." -
Szerinted. A valóságban meg nem legalábbis semmiképpen sem tömegesen. Néha 1-1 logban nyilván szövegesen iratod ki a számokat is, de kb. ennyi (a nyilvánvaló programozói hibákat, helytene adat modellezést leszámítva). -
pmonitor
aktív tag
válasz
pmonitor
#16614
üzenetére
Viszont most megnéztem winen a Code:: Blocks+Mingw kombóval. Itt meg az itoa() minimálisan gyorsabb(de ugyanazzal a kóddal mindegyik 15 és 19 sec. között fut le). Ez azonban a VS középértékének felel meg. A fordítótól is nagyon sokat függ.
@martonx:
Igazából a sebesség akkor számít, ha valamit ciklusban és sokszor hívunk(addig nem érdekes). De sztem. az elég sokszor előfordul, hogy tömegesen kell számokat szövegre konvertálni. -
martonx
veterán
válasz
pmonitor
#16611
üzenetére
Hagy mondjak egy személyes példát.
Megrendelőnek volt egy utazáskereső rendszere, aminek már sok fejlesztő csapat nekifutott, a legjobb aki előttünk volt 2 perces keresés válaszidőket tudott felmutatni, nulla szűrési feltételekkel, hibás listázással stb...
Utána szerződött velünk, és az volt a kikötése, hogy 30 másodperc alatt érkezzenek meg a keresésre a válaszok, működő szűrésekkel, hibátlanul.
Megoldottuk neki C#-al, hogy 40 ms (igen fél perc volt az elvárás, és 40 milisec alatt jönnek a válaszok) alatt érkeznek a válaszok, vicc szerver terheléssel, minden szerződéses határidőt betartottunk. Az ügyfél szuper elégedett volt.
Vajon tényleg ennyire elégedett lett volna, ha tízszer ennyi idő alatt, tízszer ennyi pénzből oldjuk meg a feladatot C-vel / assembly-vel, és cserébe 2 ms alatt jönnek a válaszok?
Nem igazán hinném. -
sztanozs
veterán
válasz
pmonitor
#16611
üzenetére
Nem foglalkoznak. Azaz, ahogy a rendszerszervezés tanárom mondta annó:
Ha egy kónak 0.0001 mp alatt kell végrehajtódnia, de az csak 0.0002 mp alatt fut le, akkor az lassú, de ha az elvárás 3 mp és 2 alatt fut le, akkor az gyors.
Igazából az esetek nagy részében nincs szükség sebességre optimalizálni (se kódméretre - néhány memóriaszegény embedded/mikrokörnyezet kivételével), hiszen a felhasználónak mindegy, hogy a művelet, amit észre sem vesz 0.001 vagy 0.01 mp alatt fut majd le. Ráadásul a felhasználói programok nagy részében a műveletek végrehajtási idejének nagy részét az IO-ra való várakozás tölti ki, nem a kalkuláció. -
dqdb
nagyúr
válasz
pmonitor
#16609
üzenetére
C:\Program Files (x86)\Windows Kits\10\Source\10.0.xxx.0\ucrt\convert\xtoa.cpp
Itt meg tudod nézni a forrást, a mappa neve változhat a telepített SDK verziószámának függvényében. Ha másik implementációra is kíváncsi vagy, akkor a glibc-ben lévőt itt találod.A crt, glibc és hasonló alap C libraryk célja nem az, hogy a végtelenségig optimalizálva legyenek sebességre, hanem az, hogy a végtelenségig optimalizálva legyenek stabilitásra, ne tartalmazzanak hibát, működjenek minden támogatott architektúrán és rendszeren, és mindezt lehetőleg jó sebességgel tegyék.
Te nyújtottál egy implementációt x86-ra, míg a Microsoft megoldása x64, ARM32 és ARM64 esetében is működik, a glibc esetében pedig kilométeres a lista.
-
kovisoft
őstag
válasz
pmonitor
#16597
üzenetére
Nem látom sok értelmét annak, hogy egy általad pontosan nem ismert működésű függvény (legyen ez akár az sprintf, akár az itoa) futásidejét hasonlítgatod egy Assembly kódhoz, ami látszólag ugyanazt csinálja, majd ebből próbálsz meg következtetést levonni a C vs Assembly sebességére. Ha ilyen összehasonlítást akarsz tenni, akkor írj két függvényt (az egyiket C-ben, a másikat Assemblyben), amik ugyanazt csinálják, de úgy, hogy egyikben sincs plusz ismeretlen tartalmú függvényhívás. Például fordítsd vissza az Assembly kódodat C-re, fordítsd le sebességre optimalizálva, és ezeket hasonlítsd össze.
-
pmonitor
aktív tag
válasz
pmonitor
#16585
üzenetére
Az ittenke lévő kódom már tudja a bináris, oktális, és a hexadecimális számrendszer kiírását is. Ugyanakkor még így is jóval gyorsabb, mint az itoa(...)
Hát hiába, az ASM nem hazudik! Főleg, ha egy olyan tud hatékonyabb kódot írni az enyémnél, aki keni-vágja a témát. Mert nekem össze kellett szednem magam, hogy ezt kiizzadjam magamból.
-
dabadab
titán
válasz
pmonitor
#16575
üzenetére
Nálam itt az sprintf(...) stabilan 6 sec felett, az assembly kód stabilan 2 sec. alatt teljesített.
Mert nem ugyanazt csinálták: az sprintf() egy elég nagy tudású, rugalmas függvény, a te assembly kódod meg csak 32 bites inteket tud kiírni mindenféle formázás nélkül. Nyilván ha ugyanezt megírod C-ben, az is gyorsabb lesz, mint az sprintf, vagy ha az sprintf()-et megírod assemblyben, az meg minden bizonnyal lassabb lesz, mint az, ami a gyári stdlibben van (az alapján, hogy a mostani assembly kódod is elég szuboptimális).
Sőt, itt van C-ben egy még gyorsabb megoldás, ami a te assembly kódoddal ellentétben még csak nem is bugos
int int_ToString(int num, char* dest) {
memcpy(dest, "-2138\n", 7);
} -
martonx
veterán
válasz
pmonitor
#16566
üzenetére
Viszonyításképpen nekem Ryzen 7 5800x-en, 1 TB-s X4 m.2-es SSD-n, úgy indul a VS, mint az álom. Hol lassú ez? Szvsz iszonyat gyors. És a build idők is röhejesen alacsonyak. Igaz töbnyire Microservice-ekkel, meg Web API-kkal foglalkozok.
Ja, és a telepítés kevesebb, mint 7 GB-t foglal. -
dabadab
titán
válasz
pmonitor
#16566
üzenetére
Gondolom azért, mert kevés komponenst telepítettél.
Igen, mert nem fejlesztek egyszerre harminc nyelven - ahogy egyébként kb. senki sem.
Amúgy meg azt a 4 GB teljesen érdektelen, maga a forráskód, amivel dolgozok, szintén akkora, ha meg még le is fordítom, akkor meg 60 GB.#16568 Ispy:
Én is csak azért tudom, mert most direkt megnéztem -
dqdb
nagyúr
válasz
pmonitor
#16566
üzenetére
A fejlesztőeszköz munkaeszköz, így annyi helyet foglal, amennyit. A VS helyfoglalása amúgy is elveszik az X darab használt middleware, konténer, temp fájlok, checkoutolt Git repó között.
Így viszont hiába van 1 terrás HDD, azt mégsem lehet csak a VS-nek elfoglalnia. Méghozzá azért, mert így is egy közepes erősségű vason is nagyon lassan indul(főleg, ha töredezett a meghajtó).
Az a fejlesztő, aki HDD-re telepíti a VS-t, nagyon utálja magát, és már 10 évvel ezelőtt is nagyon utálta magát. Szerintem relatíve sosem volt még ilyen olcsó egy átlagos fejlesztésre/virtualizálásra kiválóan alkalmas gépet összeállítani az olcsó SSD és sokmagos processzorok korában. -
-
pmonitor
aktív tag
válasz
pmonitor
#16458
üzenetére
A FindFileC.exe programot frissítettem, valamint a forrása is megtalálható a .rar fájlban. A forráson még bőven lenne mit csiszolni, de működőképes. Ha valaki működést érintő bug-ot talál benne, akkor megköszönném, ha jelezné. Tényleg jó lenne, ha lenne egy ilyen win32-es topik, ami csak ilyenekkel foglalkozna. De ahhoz az kellene, hogy lenne több olyan, aki keni-vágja ezt a témát. Még az is lehet, hogy én is kérdeznék
Pl. hogy miért nem működik az sprintf(...) win32-ben? "Error LNK2001 unresolved external symbol __imp____stdio_common_vsprintf" hibaüzit ad. Mindenesetre suszter módszerrel megoldottam a helyettesítését a FindFileC-ben. ------------------------------------------------------------------------
Egy másik téma egy olyan témakörből, ami lehet, hogy többször előjön nálam, mert engem eléggé irritál a(z) (erőforrás)pazarlás. Szóval a régi szép időben az IDE megvolt pár megából. Most a VS alsóhangon is 5-6 giga, de inkább 10-nél kezdődik(régebben egy egész winchi volt 2 giga körül!). Hová jutunk, ha ez a "fejlődés" így megy tovább? Az oké, hogy a VS többet tud, de azért mégis...
-
pmonitor
aktív tag
válasz
pmonitor
#16549
üzenetére
Ezt nagyon benéztem. Egy következtetésem volt jó: Ki érti ezt'et?
Mert az igaz, hogy gyakorlatilag ahány alkalmazás, annyiféle eredmény. De a részletekbe belebonyolódtam. 
1.: C#-ban find(first/next)file-t használva.
2: C-ben find(first/next)file-t használva.
3.: TC-benHa a C:\windows\system32-t listázom ki, akkor a 2. esetben az "aadcloudap.dll"-t nem találja meg. Az 1. és a 3. esetben megtalálja.
Viszont ha ugyanezt a mappát almappákkal listázom ki, akkor az 1. és a 3. eset is eltérő eredményt ad(a TC több mappát/file-t talál a C#-nál).
De a különbségek nálam csak a c: rendszermeghajtón jönnek ki. Pl. a D:\ meghajtó teljes listázásánál mindegyik ugyanazt az eredményt adja(persze a D: meghajtón nincsenek "különleges attribútumú" mappák/állományok.)
A különleges attribútumú mappák/állományok listázása esetén talán a TC találja meg a legtöbbet. Utána a C#, majd a végén a C.Szóval az összevisszaság megvan. De azért az előző hsz-emben lévő hamis kijelentésemért elnézést kérek.
-
sztanozs
veterán
válasz
pmonitor
#16505
üzenetére
Futtattam pénteken egy tesztet: ~300K process indításból csak kb 3000 egyedi PID volt. HWND egyezést csak egyet sikerült előidéznem, azt közvetlenül a gép újraindítása után.
C# (form) kód:using System;
using System.Windows.Forms;
using System.Runtime.InteropServices;
using System.IO;
namespace pidtest {
public partial class Form1 : Form {
[DllImport("user32.dll", SetLastError = true)]
static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint processId);
public Form1() { InitializeComponent(); }
private void Form1_Load(object sender, EventArgs e) {
try {
uint pid;
IntPtr hwnd = Handle;
GetWindowThreadProcessId(Handle, out pid);
using (StreamWriter w = File.AppendText(@"c:\temp\pidtest.txt")) {
w.WriteLine("{0} {1}", pid.ToString(), hwnd.ToString());
} }
finally { Close(); }
}
}
}
python teszter:import os
a=0
f=open("c:/temp/pidtest.txt","r");A=f.readlines()
while 1:
os.startfile("c:/temp/pidtest.exe")
A+=f.readlines()
if len(A) != len({*A}): break
if a%100==0:
B,C=zip(*[a.split()for a in A])
D,E={*B},{*C}
print(f'Items: {len(B)} - Unique: {len(D)} PID, {len(E)} HWND', end='\r', flush=1)
a+=1
f.close()
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Anonym forumokon nem hinnem, hogy reklamoznak kik ok, kulonben mit keresnenek egyaltalan anonim forumon?
Vagy hogy hogy nem tudja 'kend ezt megcsinálni?
). Ezért hiányolom azt, hogy akik programozóknak mondják magukat, nem hozzák nyilvánosságra, amit alkottak(mert olyan nincs, hogy egy programozó úgy lett programozó, hogy nem alkotott semmit). Cattus azt írta, hogy nem érdekli, hogy én mit várok el. Ezzel nincs is gond. De akkor az ilyenek se várják el, hogy elhiggyem/elhiggyék, hogy programozó.
C esetén például 
Mert az igaz, hogy gyakorlatilag ahány alkalmazás, annyiféle eredmény. De a részletekbe belebonyolódtam. 
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Lenovo ThinkPad T14 3 Gen 16/256GB SSD, Újszerű, 1 Év Garanciával
- Xiaomi 15 Ultra 512GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Odyssey OLED G8! 32"/4k/240hz/0,03ms/10BIT/Freesync-G-sync/HDMI 2.1/Smart Monitor
- Új 512GB WD SN5000S Gen4 x4/ Steam Deck ready/ garancia/ ingyen fox
- i7 8700/ RX6500/ 32GB DDR4/ 512GB m.2/ garancia/ ingyen foxpost
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- LG 27GR95QE - 27" OLED / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- BESZÁMÍTÁS! MSI B450M R5 5500 32GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Chieftec 600W
- Csere-Beszámítás! AMD Ryzen 9 9900X Processzor!
- Bomba ár! Lenovo ThinkPad Yoga 260 - i5-G6 I 8GB I 256SSD I 12,5" Touch I W10 I Cam I Gari!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged