-
Fototrend
Új hozzászólás Aktív témák
-
nagyúr
> Tehát a havonta változtatást vezették be, az összes többi volt eddig is.
Ezt mondom, uber faszsag.
> és körbe van vastagon tűzfalazva meg VPN-ezve
Ja, es ez is so kétezres évek. Merthogy a tűzfal majd megvéd. Ja. Ezert van az, hogy a világ legjobban vedett rendszereinek egyike (Google belso szolgáltatásai) kint van az interneten, tűzfal nélkül.
https://en.wikipedia.org/wiki/Zero_trust_security_model
"The once traditional approach of trusting devices within a notional corporate perimeter, or devices connected to it via a VPN, makes less sense in such highly diverse and distributed environments. Instead, the zero trust approach advocates mutual authentication, including checking the identity and integrity of devices without respect to location, and providing access to applications and services based on the confidence of device identity and device health in combination with user authentication.[1]"
while (!sleep) sheep++;
-
addikt
40 éves mainframe-en szerintem ezt nem tudják megcsinálni, szóval ettől én megmenekülök. Az ügyfeleknél már most is ez van, sírnak is miatta.
#16851emvy
Hja, ezt már linkelted korábban, én is magyaráztam a kollégáknak, hogy a VPN egy faszság, csak kényelmetlenséget szül. Persze ezt nem mi fogjuk eldönteni itt a gyarmatokon.[ Szerkesztve ]
-
martonx
veterán
dolgoztam bankoknak, OTP-nél egy időben még külsős IT tanácsadó is voltam pont ilyen esetekre (mert én is csak egy nick vagyok aki ugatja a szakmát, mert nem atoi-t optimalizálok hehehe).
De mindegy is, semmi értelme egy ilyen fórum keretein belül mélyebbre mennünk. Írtál egy problémát, páran írtunk lehetséges megoldási javaslatokat, aztán ebből mindenki azt hoz ki, amit a lehetőségei, képességei (bankokat ismerve és pár kivételt mélyen tisztelve de a többség inkompetens, kezdve a menedzsmenttől, a programozókig) és a projekt scope-ja engednek.
Számomra az egészből egyedül az volt a lényeg, és amiért nagyon hálás is vagyok neked, hogy @pmonitorral ellentétben hoztál egy valós életbeli programozói problémát, szemléltetve, hogy nem az atoi-val kell szórakozni, hanem olyan robosztus rendszereket írni, tervezni, amik valós ügyfél problémákra reagálnak.Én kérek elnézést!
-
addikt
válasz martonx #16854 üzenetére
Hja, nehogy személyesre vedd, nem az volt a célom. Csak megmutatni azt, hogy tényleg mekkora jelentősége van a tervezésnek. És itt rohadtul nem kódminőségről van szó, hanem architektúráról. És tényleg sokan vannak, akik nem láttak ekkora rendszereket, és könnyen mondanak triviálisnak tűnő, de használhatatlan megoldásokat.
-
martonx
veterán
Előző, nem banki munkahelyemen, meg rendszeresek voltak a több milliárd soros DB táblák. Ott is észnél kellett lenni, minden egyes SQL lekérdezésnél, és nyilván egy 2 TB-os DB táblát cachelni se lehet vagy legalábbis észnél kell lenni, hogy mit, mikor, milyen aggregáltsági szinten cachel az ember.
Azaz amikor cachelésről beszélünk, ne arra gondolj, hogy oké lerántom a táblát memóriába, és probléma megoldva. Ennél a valóság az esetek többségében nyilván bonyolultabb (bár kis rendszereknél, ez nyilván egy könnyű járható út).Én kérek elnézést!
-
pmonitor
aktív tag
válasz martonx #16854 üzenetére
>mert nem atoi-t optimalizálok hehehe).
Azért próbáld optimalizálni a C# Convert.Tostring(int value, int tobase) metódusát. Ha megszakadsz sem tudod jelentősen optimalizálni, mert a C#(és mögötte a robosztus .Net) nem ad megfelelő eszközt a kezedbe. Pedig lehetne rajt mit optimalizálni, mert a C itoa(...) függvénye ~21 sec alatt megoldja, amit a C# említett metódusa ~51 sec alatt. És C-ben még van eszközöd optimalizálni, mert le lehet vinni 10 sec. alá a futásidőt.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
sztanozs
veterán
Zerotrust csak ott működik, ahol nincsenek legacy rendszerek. Nem hiszem , hogy ezt rúl sok nagy cég elmondhatná magáról. Ráadásul a teljes nyitottság jelentős logolási probléma is. Bár a hálózat szegregációja okozhat plusz problémákat, nyomozati szempontból (ha beüt a sz@r) sokkal kellemesebb, hogy nem a telhes internet a gyanúsított.
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...
-
Ispy
veterán
válasz pmonitor #16859 üzenetére
De mi a tosznak kéne egy ilyen százhuszadrangú függvényt optimalizálni, tényleg nem értem....az ilyen függvényeket az ember jellemzően nagyon kis mennyiségben használja kevés adatra, akkor meg tizedmásodperc alatt megvan.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
pmonitor
aktív tag
Ezt elsősorban azért írtam, hogy pl. a C#-ban vannak olyan metódusok, amik hiába lassúak, nincs mód rá optimalizálni. Eszed/nem eszed, nem kapsz mást. Tehát itt most nem a konkrét metódus volt a lényeg. De a "sima/mezei"
ToString()
metódus is ilyen lassú.
De ha jól tévedek, akkor pl. az IP címeket is konvertálják oda-vissza a feldolgozás során(a router-ek és egyebek). Na most ha jól tudtam ezt, akkor elég csak abba bele gondolni, hogy akár csak 1 óra alatt is mennyi IP cím kering a hálózatokon. Ha rosszul tudtam, akkor sorry.http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
pmonitor
aktív tag
Akkor sorry...
De mennyien használnak olyan programot, ami IP címeket jelenít meg? Vagy pl. a tőzsdéken hányszor és mennyi számot kell konvertálni a valuta árfolyamoknál? Vagy akár az áru tőzsdéken? Vagy amikor a banki számlakivonatokat küldik ki? Meg amilyen felhasználásra az ember még csak nem is gondol..[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
nagyúr
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.
while (!sleep) sheep++;
-
pmonitor
aktív tag
-
-
nagyúr
válasz Netszemete #16869 üzenetére
Nagysebessegu de/szerializasal nem perszolunk, pont. Jo eséllyel annyit történik, hogy a hálózaton bejövő adatot egy-az-egyben írjuk a memóriába (es fordítva: a memóriában levő adatot egy-az-egyben toljuk ki a hálózatra).
while (!sleep) sheep++;
-
cattus
őstag
válasz Netszemete #16872 üzenetére
Mondjuk JSON esetén pont van külön string és number típus, szóval abban az esetben pont nem kell konvertálni egyikből a másikba. De általánosságban szerializálás / deszerializálás során nincs konvertálás típusok között.
Do the thing!
-
Drizzt
nagyúr
válasz Netszemete #16872 üzenetére
De, és a JSON nem kimondottan kis erőforrásigénnyel parse-olható formátum. Ellenben remekül olvasható. Valamint WEB API-knál megintcsak fontosabban az egyéb előnyök, mint az azokhoz elhanyagolható mértékű sebességnövelés. Könnyű olvashatóság, mindenféle architektúra könnyen tudja értelmezni.
Ha pl. MQ-n küldesz adatot és nem akarsz parsingot alkalmazni, akkor mindkét végén a queuenak pontosan ismernie kell az adott adatstruktúrát.
Webes APIknál általában nincsen olyan latency requirement, amiben egy +/- JSON serdes ne férne bele.
#16873: JSON parsingnál a fő problémát az okozza, hogy nem lehet tudni az üzenet végigolvasása nélkül, hogy melyik mező hol kezdődik, így nem elég csinálni egy pár offsetről való közvetlen betöltést, ha egy mező értékét meg akarod tudni, hanem kénytelen vagy végigolvasni az eredeti JSONt(legalább addig, ahol a keresett mező(k) és annak értéke(i) van(nak)). Illetve az, hogy van szöveg, szám, meg boolean önmagában még nem segít semmit, mert a számot mindegyik oldal önkényesen értelmezheti különböző számtípusonként. Szóval általános JSON parsingnál valamiféle objektumba nem lehet megúszni a konverziót a számok esetén. Eleve a JSON sorrendfüggetlen, ugyanaz az objektum lehet a {"a": 1, "b": 2}, mint a {"b": 2, "a": 1}. Tehát nem tudsz olyat monda, hogy az Integer b mindig a 4. offseten keresendő. De még csak azt sem tudod megmondani, hogy a b Integer, Float, Double, BigInteger, BigDecimal. Szabadon értelmezhető.
De ahol a konverzió sebessége szűk keresztmetszet, ott nem is JSONt használnak.I am having fun staying poor.
-
nagyúr
válasz Netszemete #16872 üzenetére
Böngészők felé történő kommunikáció során a szerializacio nem szuk keresztmetszet. (Drizzt is ezt mondja, csak igényesebben )
L
while (!sleep) sheep++;
-
Ispy
veterán
válasz Netszemete #16877 üzenetére
Szerintem meg a lényeg, hogy nem a gombhoz veszünk kabátot. Van egy feladat, van egy igény lista, mit kell tudnia, egy specifikáció és utána ahhoz ki kell választani a megfelelő eszközöket, ha JSON, akkor JSON, ha XML, akkor XML, ha binárisan kell áttolni, akkor meg úgy. Mi az API-khoz JSON használunk, mert olvasható, natívan támogatja a JS, az SQL szerver, és mert univerzálisan elterjedt formátum. De nálunk nem a sebesség a mérvadó és hát inkább JSON, mint XML. Rengeted féle feladat van, mindhez megvannak a bevett gyakorlatok, hogyan és mivel kell csinálni, ennyi.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
dabadab
titán
válasz Netszemete #16877 üzenetére
Épeszű(!) programozó nem kezdi újraírni a glibc-t, ha nincs rá nagyon jó oka. ;) De előfordulhat, hogy van rá ok.
És azért előfordul, hogy van rá ok. Épp a múltkor csodálkoztam rá arra, hogy hányféle hashmap implementáció van C++-hoz, pedig ott van az std::unordered_map: [link]
[ Szerkesztve ]
DRM is theft
-
pmonitor
aktív tag
válasz Netszemete #16877 üzenetére
>de én úgy érzem, hogy ez pont az extrém esetekről szóló téma.
Igen, az. Bár ha belegondolunk mennyi szám konvertálás történik csak ebben a kis országban is, akkor lehet, hogy kiderülne, hogy még a nem szélsőséges helyzetben is lenne létjogosultsága az optimalizálásnak. Amennyivel kevesebbet kellene használni a vasakat, az elég nagy energiamegtakarítást is jelentene sztem.
>Épeszű(!) programozó nem kezdi újraírni a glibc-t,
Ha rám gondoltál, én nem vagyok programozó. de ez a könyv is tele van az STL megvalósítás kezdeményekkel. Mondjuk az egész elég sok rizsát tartalmaz. Én mondjuk megbántam, hogy megvettem annak idején. Nem regényt szerettem volna olvasni. De most már mind1.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
nagyúr
válasz Netszemete #16877 üzenetére
Nem, webes API-t sokminden használhat, de ha pl. óriási ateresztokepessegre van szükség, akkor nem feltétlenül a JSON a legjobb megoldás. Vagy ha gyors JSON de/szerializaciora van szükség, akkor nem a toString-et használunk. Jelenleg a C#-ban elérhető Utf8Json implementáció például egy 3-4 property-vel rendelkező osztályt kb. 100 nanosec (!) alatt szerializal JSON formátumra, ami kb. 100 bajtot eredményez egyébként. Azaz másodpercenként 1 CPU mag kb. 1e7*1e2 =>1e9 bajtnyi adatot tud kitolni JSON-ban, azaz 1 GB/sec sebességgel tudna kiküldeni a JSON streamet, ami gyakorlatilag szaturálna egy 10 Gbe linket.
while (!sleep) sheep++;
-
pmonitor
aktív tag
válasz martonx #16885 ü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 az alap típusok konvertálásai alapvetőek(legalábbis sztem.). Mondjuk itt valszeg. a sok függvényhívás is közrejátszik pl. a C "relative" lassúságában.
A másik meg az, hogy ez biztos, hogy egy user programozgatónak a dolga lenne? 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?
-------------------------
Ettől függetlenül nem árt, ha valaki megpróbálja megérteni az általa használt függvények/metódusok működését/algoritmusát. Főleg, ha ugyanazt a funkciót gyorsabban is meg tudja valósítani.
-------------------------
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.http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
pmonitor
aktív tag
válasz Netszemete #16887 üzenetére
>a legtöbb feladatnál a sebesség másodlagos, sokadlagos tényező.
Akkor miért is kell erősebb HW-t venni, ha sokadlagos tényező? Akkor miért nem jó a legolcsóbb, lassabb HW, ha sokadlagos tényező?
Sztem. nem sokadlagos. Csak én az alkalmazások optimalizálását emelem ki, a többiek meg a szuper HW-t emlegetik.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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?DRM is theft
-
Ispy
veterán
válasz pmonitor #16888 üzenetére
Csak én az alkalmazások optimalizálását emelem ki, a többiek meg a szuper HW-t emlegetik.
Persze, addig nagy az arc, amíg nem neked kell fizetni a számlát, utána neked is másodlagos lenne az optimalizálás. De már megint ugyanazokat a köröket futjuk....
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
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.
[ Szerkesztve ]
-
pmonitor
aktív tag
válasz Silεncε #16892 üzenetére
>Sok sikert kívánok hozzá, hogy ezekben megírj egy webappot
Asm-ban vagy C-ben nem. De a C++ megfelelő választás lehet(már aki keni vágja). És gondolom ehhez is vannak eszközök... A C++-ban sztem. a C#-hoz képest 130%-os idővel meg lehet írni ugyanazt az alkalmazást.
[ Szerkesztve ]
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
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.
[ Szerkesztve ]
-
nagyúr
Szerintem ott beszeltek el egymás mellett, hogy a webapp az most a webszerveren HTML-t generáló app, vagy a böngészőben futó program. Webappnak általában az elsőt szokás nevezni, szóval most pmonitornak van igaza.
[ Szerkesztve ]
while (!sleep) sheep++;
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- exHWSW - Értünk mindenhez IS
- Microsoft Excel topic
- Házimozi belépő szinten
- Elektromos autók - motorok
- Koreai autók topic (Kia, Hyundai, stb.)
- Vodafone-ra áttért Digi Mobilosok
- Végre megjelenési dátumot kapott az xDefiant
- Háromféle processzor is része lesz a Core 200 sorozatnak
- Formula-1
- További aktív témák...
- Xiaomi Redmi Buds 3 Lite, Vezeték nélküli fülhallgató, Fekete + szilikon védőtok
- Star Wars - Az eredeti trilógia - DVD kiadás (2022)
- Corsair 110Q ATX Gépház Eladó!
- Dell Latitude 3410 Quad Core i5- i5-10210U 10 generációs laptop 8 GB DDR4 SSD jó akkumulátor
- Star Wars - The Rise of Skywalker - 4K UltraHD Steelbook kiadás
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest