-
IT café
Új hozzászólás Aktív témák
-
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.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
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[ Szerkesztve ]
DRM is theft
-
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.Én kérek elnézést!
-
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);
}[ Szerkesztve ]
DRM is theft
-
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.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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.
-
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.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
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ó.JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
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.Én kérek elnézést!
-
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.[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
pmonitor
aktív tag
válasz pmonitor #16616 üzenetére
Ja nem. Csak valamit néztem(a 2-es számrendszert), és így az itoa() 10-esben, míg az int_ToStringC() 2-esben futott. Tehát Code:: blocks-ban is megvan a nagyságrendi különbség az itoa() hátrányára.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
sztanozs
veterán
válasz pmonitor #16616 üzenetére
Egy kis matek. Hányszor kell ezt a konverziót elvégezni, hogy ez a felhasználó szempontjából észrevehető különbséget produkáljon (0.5 sec)?
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
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).Én kérek elnézést!
-
sztanozs
veterán
-
dqdb
nagyúr
válasz pmonitor #16632 üzenetére
Már megint almát körtével: a C library belül bufferelt írást használ alapértelmezetten. A
fopen
után dobd be asetbuf(fp, NULL);
sort a korrekt összehasonlításhoz, vagy a Win32 API-t használó kódba tegyél be implementációt 4096 byte-os írási buffer használatára.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
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
[ Szerkesztve ]
-
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ó.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
MODERÁTOR
válasz pmonitor #16708 üzenetére
Azt már látatlanban kizárom, hogy zseni lennél.
Szerk.: gyanítom, hogy a gyári atoi implementáció van olyan idős, hogy kizárt, hogy ne lenne optimalizált.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
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... -
MODERÁTOR
válasz pmonitor #16723 üzenetére
Engedd el. Első implementációd sem lett jó és utána gyorsabb sem. Okkal van. Nem fogod feltalálni a spanyol viaszt. Ezek jól bevállt régi dolgok amiket elfogadunk és használunk. Ennyi.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
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 #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.
-
MODERÁTOR
válasz pmonitor #16771 üzenetére
Látszik, hogy nem vagy szakmabeli. Olcsóbb a tárhely mint az ilyen alacsony szintű optimalizációra szánt idő. Amit nem tudsz szavatolni, hogy jól is és hibamentesen működik.
Egyébként ez egy csak egy általánosítás a részedről ami nem is igaz.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
K1nG HuNp
őstag
válasz pmonitor #16775 üzenetére
ember ne általánosíts már..
van az szitu amikor a legfossáoptimalizáltabb kód kell és van a maradék 99% ahová csak haladni kell azzal ami előre viszi a businesst.
(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()
-
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.[ Szerkesztve ]
DRM is theft
-
#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
-
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.I am having fun staying poor.
-
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
Én kérek elnézést!
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- -65% Dell Latitude 7310 2in1: i7 10610U,16GB,256GB,13.3" Touch 100%sRGB 350nit,WWAN eSIM,Win11
- Samsung Galaxy S22 - Fekete - Független - 2025.03.05-ig garancia - Tökéletes állapot
- Endorfy Fortis 5 ARGB CPU hűtő áron alul! (3 db)
- Forradalmasítsd a digitális világodat a HoloLens 2-vel!
- ÚJ Dell Inspiron 7430 2-in-1 - 14" FHD+ IPS TOUCH 360 / i5-1335U / 16Gb DDR5 / 512Gb PCIe 4.0 / 3 ÉV