Új hozzászólás Aktív témák
-
persil
nagyúr
Sziasztok!
Rohadtul nem ertek a programozashoz, szoval nem kell a flame, csak egy szimpla kerdesem van.(ezt azert irtam, mert elolvastam a hsz-eket es latom, hogy paran mar meg akartak olni egymast
)Azt tartom furcsanak, hogy barmit telepitek, akkor nem fogja fel, hogy mar fent van a friss .net, hanem siman felteszi meg egyszer. Tehat igy mar vagy 10 peldanyban van a gepen.
Ha letorlom a regieket es marad a legfrissebb, akkor fog rendesen mukodni ugye?
-
pakesz
aktív tag
válasz
SirRasor
#146
üzenetére
.net es java mint platform kozott azt mondjak sok kulonbseg nincsen, sokkal inkabb az dont, hogy windozes gepre vagy linuxos gepre akarod felpakolni a szervert
amugy nem csak ez a ketto van, jo webes keretrendszernek van a ruby on rails meg a pythonos django meg meg valami phps cucc
ha penzt akarsz keresni akkor az uccso bekezdesemet feletsd el mert az ugymond komoly helyekre meg jelenleg nem a gyors szep jo megoldast hanem a nyogvenyelos dinoszauruszokat keresik
-
#155
stevve
veterán
killerjohn
#154
válasz
killerjohn
#154
üzenetére
Már írtam, a baromság az már a végére érve nem volt releváns, csak már nem javíthattam.
Ebben a furcsa irányok a furcsák. Pont a LINQ-val jösz? Nézted már, mit generál pontosan reflectorban? A LINQ nálam épp a megváltás, mint ahogy az expression-ök is. Olyan extend metódusokat írok, amiket eddig nehéz volt és mindent generikusan. Vagy ott a "régi" jó type inference Ha ezek furcsák, akkor nem tudom, mi nem az.
Szerintem épp az a jó az újabb verziókban, hogy lassan tényleg úgy lehet olvasni a kódot már, mintha egy könyvet olvasnánk. Nem kell agyonbonyolítani. A példádnál maradva: a 2 if helyett 1 sorban lerendezek egy iterálást és nincs gond. A fejlesztési idő bizony aranyat ér sokszor.
Az meg egyáltalán nem zavar, mekkora a .NET vagy a kód. Érdekes ez bárhol is? Szerintem nem. Rengeteg helyn tettünk már ki ezer éves gépekre cuccot és ez sosem volt akadály...
Persze, vannak hiányosságai, amiket sorolsz, de azért nem megoldhatatlan egyik sem. Office (telepített Office nélkül) és PDF is megoldható viszonylag fájdalommentesen.
A legnagyobb baj mégis az, hogy míg C++-ban halandó nem kezd el összerakni egy alkalmazást, ez Silverlight-ban, WPf-ben vagy C#-ban alap szinten gyorsan megy, ezért sokan azt asszociálják ehhez, hogy ez egy igen gagyi nyelv lehet, ha már Pistike is tud benne alkotni, holott ez távolról sem igaz. Ha igaz lenne, a Win7 és a WP7 sem létezne.
"Mindezek mellett teljes vállszélességgel a .NET mellett vagyok, az írásoddal egyet értek, csak azzal nem hogy amit írtam, az "baromság" lenne. "
Megértelek, a baromság erős szó volt, amit most írtál, azzal együtt meg vissza is vontam...
-
#154
killerjohn
addikt
stevve
#119
killerjohn
addikt
"A .NET-ben pl pont azt nem szeretem, hogy lassan fejlődik (habár cserébe stabil 1-2 pici bugtól eltekintve), és amiben gyorsan, abban is "furcsa" irányokat erőltet a Microsft..."
Ebben mit tartasz baromságnak?
Igenis, baromi ritkán jön ki új verzió, miközben egyes fejlesztéseket külön dll-ekben kell használni, ami a végső verzióval nem kompatibilis (ld: TPL a 4-esben). Mindemellett hatalmas nagy kutatási projektekben terveznek olyan programozási nyelveket amikre szükség csak 10 év múlva lesz, miközben tonna számra állnak HASZNOS, hétköznapban szükséges fejlesztési munkák. Teszem azt, miért nincs SEMMILYEN excel, word támogatás (mármint natív, telepítés nélkül, ami megy szerver oldalon). Miért nincs PDF támogatás? Miért nincs rendes kép-manipuláló API? 100 dolog van, amivel telenyomhatnák a keretrendszert, és mindenki letojná hogy 40MB helyett 100MB a Client Profile.És igen, nagyon furcsa irányokba terel az MS. A .net 4 egyik legnagyobb újítása a TPL, hogy többszálú kódot írjunk. A másik legnagyobb a LINQ tovább-robosztusítása. Naná basszus hogy kell a többszálú procikat kezeló kód C# alá, ha LINQ-val megyünk végig listákból generált enumerátorok listájának enumerátorain mindenféle delegate-ek hívásával, ahelyett hogy megírnánk azt a kurva for ciklust kézzel meg 2 db if feltétellel...
Egyik irányból (szerintem) tök felesleges kényelmi cuccokat tesznek bele, amitől a kezdő programozok maradnak kezdő programozók, az optimalizálásról nem tudnak semmit, csak írják a szar párhuzamosított kódokat, amiből kihagynak 1-2 sync-et, aztán a megrendelő meg persze hogy anyázik, hogy mi ez a f*s a .NET...
Mindezek mellett teljes vállszélességgel a .NET mellett vagyok, az írásoddal egyet értek, csak azzal nem hogy amit írtam, az "baromság" lenne.
-
#152
Vico87
tag
Realradical
#150
Vico87
tag
válasz
Realradical
#150
üzenetére
Ugyanannyi koffeintől több kódot írnak és kevesebb pizzát fogyasztanak kilométerenként.
-
#150
Realradical
őstag
bocs
#145
Realradical
őstag
Azt meg tudnád nekem indokolni, hogy mire alapozod, hogy a C# fejlesztők olcsóbbak és gyorsabbak, mint a C++ fejlesztők?
Szerintem 3-5% eltérés sincs az átlagfizu között. A project finanszírozását az üzlet meg úgysem a nyelv alapján dönti el, mert ez nagy százalékban IT belső döntés. -
Tudom, a baromság szó erős volt...
Vannak érveim. Mégpedig arról, hogy melyik fejlesztő ér többet. Szerintem az, aki szakember, sokat ér. Hogy melyik területen, nyelvben és többet az ember, az nagyjából lényegtelen, mert nyilván arra a területre fog menni, ami érdekli. C#-ban sem csak a "gyorsan kell valamit összedobni" lehet a csúcs. Nem hinném, hogy olcsóbb (= degradálni kell) az, aki C#-ban programozó a C++-hoz képest.
C# pozícióra is van több körös felvételi, ez sem jelent semmit önmagában. Szóval azért, mert neked előítéleteid vannak a C# nyelvvel kapcsolatban, nem lesz kevésbé értékes az, aki abban dolgozik és nem C++-ban.
Egyetértesz?
A C# teljesítményét csak azért tartottam meg, mert kellett, hogy mire írtad, hogy olcsóbb. Itt én erre tettem a hangsúlyt.
SirRasor:
Mindegyikben van jövő (Java, C#, C++), úgyhogy szabadon választhatsz. Van átfedés, de más-más területen jók ezek. -
#148
Realradical
őstag
caizzz
#147
Realradical
őstag
Miért? Megmondta mindenki a tuti!
Azt is megtudtuk mennyi fps-ben a C# és a C++ közötti konstans különbség!@SirRasor
Igazából az a jó, ha mindenhez értesz kicsit és tudod mi mire való. (szvsz, ha kódolni tudsz akkor mindegy milyen nyelven kell programozni, megtanulod a szintaktikát és nyomod neki) Az úgyis változik cégenként, hogy milyen nyelven, milyen hagyományú fejlesztés megy így később részleteiben is utána tudsz járni az adott területnek. Egy junior posztra kb. ez is az elvárás, nem az , hogy leülsz és végigviszel egy projectet csuklóból. -
SirRasor
addikt
Ha már belementünk ennyire a dolgokba, akkor mint kezdő programozó szeretném megkérdezni, hogy miben érdemes tanulni, ha majd pénzt szeretnék belőle csinálni, vagy akár csak hobbi szinten csinálni ezt-azt? Konkrét elképzelés? Az nincs
Pascalt tanultam 1000 éve, azóta Delphi, azt imádtam, csináltam is benne fizetős progit, de nem mondanám, hogy annyira értek hozzá. C#-ot kipróbáltam, és nagyon tetszik, mert lényegében olyan, mint a Delphi, de szeretnék a tökéletesség felé menni. A fentiek függvényében mit ajánlotok? Érdemes a C#-ot folytatni, vagy inkább hasaljak rá a JAVA-ra, mert esetleg abban van a jövő? Bármit megtanulok! De tényleg nem tudom, hogy milyen vonalon, mert nem tudom mire van szükség. Egyáltalán mihez jobb a JAVA meg a C#? Sárdobálás helyett inkább ezekre válaszoljatok ![;]](//cdn.rios.hu/dl/s/v1.gif)
-
bocs
csendes tag
"legszebb baromságokat kiemelném...
>>ahol nagy teljesítmény kell, ott c# nem olyan jó választás.
>>Inkább ott, ahol olcsóbb emberekkel kell gyorsan összerakni valamit.
"A beidézett részt én írtam, és mint mondtam, kb. 30 fős fejlesztőcsapat van a cégnél.
A céghez ezek az embereket kifejezetten szigorú, többkörös felvételi után, hosszú válogatás után vették fel, és az átlagosnál jobb szakemberek.
A legtöbben, leggyakrabban c#-ban dolgoznak, mert a cégnél abban szokás és pont.
Az ő véleményüket fogalmaztam meg, amikor a c# teljesítményéről írtam, hogy nem a legjobb.Neked esetleg érveid is vannak, vagy csak kinyilatkoztatsz?
-
Alwares
aktív tag
XNA keretrendszer tényleg egy mocsok lassú dolog, de hát mikor van egy indie developernek ideje a mobilos kis játékához C++ engine-t fejleszteni. Majd talán ha nagyobb pénz lesz benne, akkor az MS kiadhatna hozzá valami native libary-t, mint a Google tette az Androidnál. De ezt nem tartom valószínűnek (Ms-t ismerve), meg a droidnál nagyobb szükség volt rá, mert a java és a 3D kínos egy dolog
De nem ugatok bele, nekem kevés tapasztalatom volt eddig a C++-al, amik nem feltétlen voltak jók, de ez nem is a c hibája. A C#-ot viszont annál jobban szeretem, fősuli alatt nagyon megszerettem. A Visual Studio pedig egy eszméletlen király dolog. Nyamnyam. -
Egyszerűbben fogalmazva : használjunk mindent arra, amire való!
-
bambano
titán
Mind a kettő "kinek a nagyobb az e-perója" hangulatban íródott.
Mind a kettő arról szólt, hogy kinek fontosabb/nagyobb/drágább/stb. a kódja, amely osztályozásnak semmi értelme.
Mind a kettőben volt egy halom ki tud nagyobbat mondani elem. pl. több, mint 15 éve használok postgrest, de még sosem láttam memória típusú táblákat, és amióta megjelent az a hsz, azóta folyamatosan túrom a guglit és nem találok róla semmi kézzelfoghatót. Ez felveti azt a jelen pillanatban nem bizonyított gyanút, hogy az elődeik által faragott programot annak ismerete nélkül köpködi.
Kérdés: ha látsz két, egymásnak nyilvánvalóan ellentmondó hozzászólást, azt miért nem vetted bele a baromságlistádba? Csak mert haver mondta?
-
-
Aztaqrv... bolondok háza.
Elnézést mindenkitől, de e legszebb baromságokat kiemelném név nélkül azok kedvéért, akik nem akarnak hosszasan visszaolvasni (no meg azoknak, akik értelmet keresnek a topikban - ne tegyétek):
"ahol nagy teljesítmény kell, ott c# nem olyan jó választás. Inkább ott, ahol olcsóbb emberekkel kell gyorsan összerakni valamit."
"A .net, azon kívül, hogy könnyen lehet rá fejleszteni, kiválóan megoldja, a "hogyan lassítsuk be a programokat" feladatot is, ebben is hasonlít a Java-ra
És ez már minimális mennyiségű programozás után feltűnt.""ha letöröltem az összes .NET-et a gépről (még mindig a régi gépről van szó), a rendszer látványosan flottabbul működött, a memóriaétvágy csökkent."
"A .NET-ben pl pont azt nem szeretem, hogy lassan fejlődik (habár cserébe stabil 1-2 pici bugtól eltekintve), és amiben gyorsan, abban is "furcsa" irányokat erőltet a Microsft..."
"Pikari továbbá nem érti, miért kell a dotnet fanoknak állandóan görcsösen védelmezniük a kedvenc nyelvüket. Úgy se tudják. "
"mi mindig rilizt fordítunk."
"Azt ne is említsük meg, hogy szinte minden változatot telepíteni kell, mert visszafelé nem kompatibilisek, de ez ősi windóz szokás, már megszoktuk. "
"A dotNET keretrendszer az egyik legrosszabb keretrendszer, amivel valaha találkoztam"
"A dotNET keretrendszer azonban azért különösen veszélyes, mert terjesztéséhez a Microsoft agresszív, felsővezetést megnyerő, hazugságokra és propagandára építő politikát folytat, továbbá a dotNET keretrendszer előtérbe szorításával a Microsoft agresszívan a saját rendszereire kényszeríti a fejlesztőket, különösen azokat, akik kevésbé értenek az iparhoz, hisz a dotNET látszólagos egyszerűsége számukra csábító lehet. A dotNET tehát valójában egy káros, monopolizációs folymat egy állomása, ráadásul a dotNETben írt szoftverek összességében pocsékabb élményt nyújtanak mint a konkurens natív programok."
"Hát persze, többszázezer forintot érő kódokat szoktam gamer fórumokra bepostolgatni unalmamban"
"Eszemben sincs lealacsonyítani a fórumot, de ide főleg gamerek járnak, akik nagyrészt érdeklődnek kicsit más témák iránt is. "
Azt hiszem, nem nagyon van több hozzáfűznivalóm. A tulajdonosok élhetnek panasszal, de az elég nyilvánvaló, hogy többen itt vagy kicsiben nyomják a programozást és úgy magát a .NET-et is vagy már láttak olyat, aki írt számológépet. Nyilván nem minden nyelv, rendszer jó mindenre, de aki még ezt sem látja (elvből írogat), azzal nem lehet vitázni.
-
#118
bambano
titán
killerjohn
#13
bambano
titán
válasz
killerjohn
#13
üzenetére
pebkac.
1. nincs hetente java frissítés, előre meghatározott ütemterv szerint van update.
2. az, hogy újabb jávával nem megy az ipmid, csak annyit mutat, hogy az ipmi meg az adott jáva verzió nem kompatibilis, arról semmit nem mond, hogy valójában az ipmi vagy a jáva a hibás.
3. ha nem tudtál feltenni különböző jáva verziókat egyszerre, akkor vagy az oprendszered hibás, vagy te nem értesz hozzá. Nekem simán ment, azzal az apró és szerintem elhanyagolható különbséggel, hogy nem ipmihez, hanem rsa2-höz akartam használni. -
#117
Ł-IceRocK-Ł
veterán
Ł-IceRocK-Ł
veterán
Nagyjából eddig is tudtam mire jó ez a .net rendszer. Most meg már elég is amit tudok róla.
-
acsa77
tag
Ha az én példámra gondoltál, persze hogy buherálás. De a legkisebb időigénnyel, viszonylag egyszerű kódszerkesztéssel ezt találták megoldásnak, hogy gyors legyen. És tudtommal ez is kliens-szerver. Pár százezer szülő néha egyszerre megrohanja...
Biztos gyönyörű lett volna valamilyen modern megoldás, amit később könnyű beintegrálni bármilyen Nagytestvérbe, de erre nem volt sem igény sem pénz. És ugye ha azt is meg kell fizetni, hogy beletanuljanak egy másik rendszerbe, hogy miként lehet azt a teljesítményszintet elérni, ami kell, akkor az is pénz.
-
bocs
csendes tag
Mi beágyazott rendszerek + PCs világra fejlesztünk, vegyesen használunk c#-ot, c++ -t és c-t.
Kb 30 fős fejlesztőcsapat van, de igen kevesen mernék azt mondani közülünk, hogy teljesítményben a c# megközelíti a c - c++ párost.
TCP/IP, I/O műveletek, nagy byte-stream-ek feldolgozása, parsolása, stringkezelés megy szépen, rövid fejlesztési idővel, de azért ha komoly mennyiségű adatról van szó, akkor egy 2-es 3-as sebességfaktor simán van a c++ javára.
Nem kell azért bedőlni a marketing gépezetnek: ahol nagy teljesítmény kell, ott c# nem olyan jó választás. Inkább ott, ahol olcsóbb emberekkel kell gyorsan összerakni valamit.
Adatfeldolgozás:
A c++ -os fejlesztést Qt-ben javaslom, ennek képességei, összeszedettsége igencsak megközelítik a c#-ot, teljesítményben pedig verik: képfeldolgozást csináltunk OpenCL-el, SIMD-vel, CUDA-val, de még a sima natív kódos adatdarálást sem közelíted meg c#-al.GUI:
WPF: az egyetlen c#-os GUI, ami elég szép. Fejlesztőeszköz támogatás hozzá: siralmas. Teljesítmény: felzabál minden erőforrást, amit talál.WinForms: a jó öreg WinAPI-ra húzott vékony réteg, témázás: keservesen, külső eszközökkel.
Itt pl egy esettanulmány: egy WPF-es c# alkalmazás áítrva c++-ra ötöd annyi idő alatt indul, fele annyi memóriát zabál.
-
Ez a topic teljesen a megdöbbentő kategóriába tartozik.
Azért én a megkérdezném itt a nagy hangemberektől, hogy hány olyan projekt lapul a gépükön aminek a fejlesztése, valamelyik szoftverfejlesztési módszertannal készült, jól dokumentált. Ezenkívül még az első kész kódhoz képest még optimalizálásra is futotta az idő/energia/esetleg pénz hármasból. Valamint ez a projekt implementálva lett C# és JAVA és C/C++ nyelveken.(Esetleg ha pluszba megcsinálta más nyelven jöhet az is) Majd volt olyan szorgalmas és az adott évszám/hó/nap -nak megfelelő legújabb verziók mellett csinált többféle teljesítmény tesztet. Kiváltképp I/O igény,Memóriahasználat, Processzoridő....stb.
Na akkor most kérem, hogy jelentkezzen aki eleget tesz ezen minimális követelményeknek.
...zZz...zZz...
Gondoltam.
Az a legrosszabb, hogy tudom pár embernek a reakcióját: "Mé neked van?"
Hát nincs. De miért is kéne?! Igazolja a véleményét az aki tette nagy bejelentéseit.Nagyon jó lenne, ha úgy általában az emberek levennék a szemükről a két bazi nagy csövet, és kicsit nyitottabban és objektívebben vizsgálnának meg egy adott problémakört.(Sőt mások véleményét is, még ha tudjuk, hogy azzal nem teljesen értünk egyet.)
Úgy gondolom, hogy aki szoftverfejlesztéssel foglalkozik, az nem engedheti meg magának azt a luxust, hogy "háháá....a 2.0 verzió szar volt....akkor biztos a 4.0 is az, mer má akkoriban is szar volt meg különben is MS az fos" típusú viselkedést mutasson.Egy tanárom mesélte, aki adatbázist tanított. Amikor szakdolgozatokat készítették néhányan tipikusan PHP+MySql meg valamilyen adatbázis alapú desktop alkalmazásnál fordult elő. Az egyén megpróbált újraírni mindenféle rendezéseket, sok energia, idő, és nem kevés nyugtató árán de sikerült...Azonban azt elfelejti, hogy fölösleges volt ezt megtennie, ha ismerte volna az SQL nyelvet normálisan.
Ezzel csak azt akarom mondani, hogy egy szoftverfejlesztési eszköz nagyon alapos ismeret nélkül kár ugrálni, mert csak hülyét csinál magából az ember. -
A .net, azon kívül, hogy könnyen lehet rá fejleszteni, kiválóan megoldja, a "hogyan lassítsuk be a programokat" feladatot is, ebben is hasonlít a Java-ra
És ez már minimális mennyiségű programozás után feltűnt.
-
oO7
őstag
azért az XNA kicsit több mint egy .net-es DirectX wrapper...
plusz ezt a "majdnem teljesen C# -os 3D hang library" dolgot sem egészen értem, hogy úgy mégis minek, amikor van benne alapból is ami meg szintén DirectX -es API -val működik...a 3.5 telepítés pedig azért tarthatott olyan sokáig és foglalhat olyan sok helyet mert az felrakja az összes többit is visszamenőleg illetve azok még teljes .net -ek voltak... ez a client profile -s megoldás a 4-essel jött be (ha jól emlékszem)
-
hohoo
senior tag
windows/assembly, ellégé .net-es libek neveire emlékeztetnek a benne lévő dolgok. Na meg mikor utóljára telepítettem egy net 3.5-t az 20 percig tartott, és kereken 1,2 gigával kevesebb hely maradt a vinyón.
Az xna pedig natív apit hívogat grafikánál (directx), szóval annak a grafikai része inkább csak egy natív api-t eltakaró api, úgyhogy azért olyan jó mint a mert tényleg nagyrészt natív, viszont a ténylegesen c#-ban írt játéklogika ha van olyan bonyolult akkor már eszeget. Ismerek is egy komolyabb készülő 3d-s játékot xna és net alapon. A grafikát egész jól bírja, de egy majdnem teljesen c#-os 3d hang library elég keményen beakasztja, mert szemetel (cserélik is le a készítők nagyobb százalékban natív openAL-os megoldásra).
-
oO7
őstag
nemtudom, hogy milyen mappát nézel, de pl a .NET 4 Client Profile (amiben benne van minden ami egy klienshez kellhet) 40MB -t foglal összesen...
vagy hogy említsek még erősebb példát, ottvan a Silverlight ami meg foglal kőkemény 6MB -t...
a több tízezer assembly is erős túlzás, főleg ha egy adott program által valóban használt assemblyk számát vesszük...de amúgy ez már nem annyira neked szól hanem a többieknek mert látom azért megy rendesen a "szarlassúfos" -ozás... ottvan pl az XNA ami egy játékfejlesztői platform .NET alapokon... és hát 99."sokkilenc" -es teljesítményt produkál egy natív kódhoz képest... vagy épp azon is el lehetne gondolkodni, hogyha olyan nagyon lassú lenne akkor valóban ez lenne e a kizárólagos fejlesztői környezet a WP7 -re... és az valóban ilyen gördülékeny lenne e egy ilyen állítólagosan hihetetlen kuka lassú rendszerrel...
(#107) Realradical ezek a hasonlatok
-
#107
Realradical
őstag
hohoo
#106
Realradical
őstag
Öcsém amellett ami itt megy nem csoda. Itt a normális fejlesztők szemét kihugyozzák a Pikari jellegű "mer' én megmontamm" típusú albán hekkerek!
Nekem úgy tűnik itt hiába érvelsz logikusan valami mellett.Na sorry, gyorsan átmegyek read-onlyba mert kiraknak pihenni a modik!
-
hohoo
senior tag
Innen is látszik hogy egy ms troll vagy mint moonman, akinek érvei soha sincsenek, csak "lol" meg "nem is úgy van"
(én itt látok az assembly mappában 1103 fájlt, 1,4 giga tárhelyen, de biztos kamu, meg az órát is látom ahogy néha 10 sec eltelik mire egy .net-es program elindul elsőre) -
hohoo
senior tag
a .net tényleg szar lassú az első program indulásakor. Köszönhetően a ms a "jól bevált" dll hellről mintázott 4543534534544 millió assembly fájl, és a nem éppen kis méretű keretrendszer miatt. Ez is furcsa hogy az egyébként az eredeti "szar lassúnak" 2000 környékén kikiáltott és azóta is laikusok közt megmaradt nézetű, javanál a jre befér 20 megába és néhány tíz fájlba(ezért jóval gyorsabban is indulnak a javas programok elsőre), netnél meg több tízezer fájl, és több száz megányi cuccot jelent, amit a vinyók nem igazán szeretnek.
-
#101
TBG
senior tag
huskydog17
#98
TBG
senior tag
válasz
huskydog17
#98
üzenetére
Az említett jelenségek a .NET telepítést követően jöttek elő.
Egy tudós fog egy legyet és kitépi a lábát, majd így szól: Ugorj!
A légy ugrik. A tudós kitépi a légy összes lábát, majd így szól: Ugorj!
A légy meg sem mozdul, mire a tudós ezt írja le: Ha a légynek kitépjük az összes lábát, a légy megsüketül.Félretéve a viccet, a .net feltehetőleg beépül a windowsba ( betölt egy csomó dll-t, elindít sevice-ket), mivel ebben az esetben kvázi a windows az alkalmazásszerver. Egy java alkalmazás meg pl. csak akkor fut, ha elindítod, mivel a jvm nem oprendszer szintű valami.
Tehát az észrevételed szerintem jogos.
-
#99
h_143570
addikt
killerjohn
#13
h_143570
addikt
válasz
killerjohn
#13
üzenetére
Ez nekem elege alaplap gyartoi fa@sagnak tunik.
-
#98
huskydog17
addikt
voronoi
#96
huskydog17
addikt
Miért is?
Az említett jelenségek a .NET telepítést követően jöttek elő. Mondok még jobbat: ha letöröltem az összes .NET-et a gépről (még mindig a régi gépről van szó), a rendszer látványosan flottabbul működött, a memóriaétvágy csökkent.
Akkor mégis mi lehetett? Nekem ez elég egyértelműnek tűnik.eziskamu: amint írtam a boot-idő szenvedte el a legkisebb mértékű lassulást, az még elhanyagolható.
Úgy is nézhetjük a dolgot, hogy: miért ne lassíthatna a .NET egy régi konfigot?
-
#97
eziskamu
addikt
huskydog17
#94
eziskamu
addikt
válasz
huskydog17
#94
üzenetére
Jaja, se a JRE se a . Net nem vagy alig változtat a boot időn. Az megint más, hogy egy .NET-es vagy Java-s progi milyen gyorsan indul, de itt is sok múlhat a kódon.
-
#96
voronoi
tag
huskydog17
#91
voronoi
tag
válasz
huskydog17
#91
üzenetére
Annak amit irtal, alig van koze a .nethez.
-
#94
huskydog17
addikt
oO7
#92
huskydog17
addikt
Nem, szerintem félreértettél. Az összehasonlítás nem single vs. multicore CPU alapú volt, hanem csak az Athlon XP-n, hogy a .NET milyen hatással van arra a rendszerre. Az evidens, hogy egy modern multicore CPU jóval könnyebben bánik el vele, mint nagyon régi single-core proci.
Nézd, én csak a tapasztalatomat írtam le, hogy az Athlon XP-s gépemen - ha nem is sokkal - valamelyest nőtt a boot idő is mivel több dolgot pakol alapból a memóriába mint nélküle.
Habár a 2.0 még gyors volt, de a 3.5 már jóval több erőforrást igényel. -
floatr
veterán
Nem értem mi ez a dilettáns hozzáállás a témához. Teljesen más a célterülete a két platformnak. Ha hardverközeli fejlesztésre van szükség teljesítményre optimalizált kóddal, akkor nyilván a c/c++ jön szóba, ha meg szerver-kliens architektúra, akkor java/.net (a php-s buherálást meg sztem hagyjuk). Esetleg még játszik a dolog olyan esetekben, ahol nem elsődleges a teljesítmény, viszont a produkciós tempó annál inkább.
Ettől függetlenül sok esetben a JIT elég nagy cache-el rendelkező hw esetében tud gyorsabb kódot generálni, de ahhoz nagyon ismerni kell a JIT lelkivilágát, hogy ki tudja ezt használni a jómunkás.
A 16 magos kiszolgáló meg reális egy ekkora rendszernél. A fejlesztés/support/üzemeltetés mellett a hw ára eltörpül, akkor meg miért ne legyen használható gép.
-
#92
oO7
őstag
huskydog17
#91
oO7
őstag
válasz
huskydog17
#91
üzenetére
nem hinném, hogy a .net -nek bármi köze lehetne a bootolási időhöz... és az sem feltétlenül a .net erénye, hogy egy multicore -s gépen gyorsabban fut a rendszer mint egy ősrégi AthlonXP -n... memóriaigény csökkenés multicore processzor miatt ?
annyi igazság van ebben, hogy tényleg akad benne bőven szálkezelés és nyilván egy multicore -s gépnél ahol a szálak fizikailag más magon futhatnak párhuzamosan, ott ez tudhat is akár látványos sebességnövekedést is okozni
-
#91
huskydog17
addikt
huskydog17
addikt
Én még csak véletlen se szeretnék bármiféle vitába keveredni főleg azért nem, mert nem vagyok programozó. Csak egy "átlagos" felhasználóként szeretném közölni kevéske tapasztalatomat a .NET keretrendszerről.
Én úgy veszem/vettem észre, hogy a .NET kifejezetten multicore processzorokra van kihegyezve, ugyanis a régi gépemet, melyben egy AthlonXP van, látható mértékben lassít. A lassulás alatt az operációs rendszer reszponzivitásának csökkenését a bootolás idejének hosszabbodását, a memóriaigény növekedését, valamint az arra íródott szoftverek lassúságát értem.
A notimon viszont - melyben már multi-core CPU dolgozik - nem vagy csak nagyon minimálisan lehet érezni ezeket a dolgokat, de itt már nem zavaró mértékű. Egyszerűen itt lassít látható mértékben a rendszeren.
Azt azért aláírom, hogy még a régi gépen is sokkal jobb, mint a JAVA sebesség szempontjából. -
#90
TBG
senior tag
killerjohn
#13
TBG
senior tag
válasz
killerjohn
#13
üzenetére
Egy java frissítés (amiből kb hetente van...... no comment) után simán elérhetetlenné váltak a szervereim IPMI felületei.
Ne haragudj, de ez nem a Java hibája. Először is, a frissítések hibajavítások, tehát gond nem nagyon lehet vele, de ha mégis, akkor, meg produktív környezetben ha nincs semmi baj az adott update-val, akkor nagy ostobaság vm-t frissíteni.
A teljesítménye meg max. attól lehet gyenge, hogy hitvány a kód.
-
acsa77
tag
Egy rokonom ált. iskolai naplórendszert csinált egy teljes országnak, ahol inkább a rohamokra kellett felkészülni. Ebben és más projektekben is arra jutottak, hogy php -> c++ a megoldás fejlesztési ktsg+teljesítményben. Mert nem lehetett csak olyan lazán hardverre meg licenszekre költeni, miközben mindenki maximális teljesítményt akart minimális költséggel. És pár hét volt összerakni - bár igaz, nem olyan bonyolult. Még amiatt is szenvedtek, hogy igazából csak egy tűzfal létezett, ami teljesítményigényüknek megfelelt, de az meg nem fért be a keretbe. (Nem hiába került annyiba.) Szóval azt akartam mondani, hogy ott, ahol korábban igen pazarló rendszer volt, ott van egy kis mozgástér utána, de egyébként rendkívül takarékosan kell dolgozni, mint amikor anno C64-re csináltak csodabogarak egy bonyolult szervert.
-
#88
killerjohn
addikt
Alec
#87
killerjohn
addikt
szerintem sem használahatatlan, elnézés ha ezt sugalltam. Csak nálam elkaszűálta magát és nem szeretem. A .NET-ben pl pont azt nem szeretem, hogy lassan fejlődik (habár cserébe stabil 1-2 pici bugtól eltekintve), és amiben gyorsan, abban is "furcsa" irányokat erőltet a Microsft...
-
#87
Alec
tag
killerjohn
#13
Alec
tag
válasz
killerjohn
#13
üzenetére
az a vicc ha ebből kiindulva skatulyázol be egy nyelvet
aki foglalkozott komolyabban fejlesztéssel az nagyon jól tudja, hogy ezek a nagyobb platformok többé kevésbé ugyanazt tudják. Az egyik ebben gyengébb vagy erősebb kicsit a másik abban de olyan nincs, hogy az egyik brutálisan szar és használhatatlan lenne. -
Vico87
tag
Miért van az, hogy a Windows blog cikkei között vannak a legrosszabbak a portálon?
Ennek elolvasása után az az érzésem, hogy az író még életében nem látott .NET-et közelről (de valószínűleg távolról sem).Amúgy a .NET szép és jó, és, mint minden eszköz a világon, nem univerzális. Ha valami gyorsan kell Windowsra vagy másik Microsoft platformra, akkor tökéletes. Ráadásul nem érezhetően lassabb, mint más platform. Akik látványosan lassabb kódot írnak .NET-re, mint más platformra, azok egyszerűen nem értenek hozzá, nem ismerik a rendszert.
-
DRB
senior tag
De az nem a mostani .NET volt, hát ha másnak nem, neked tudni kéne miről szól egy szoftver fejlesztés, vagy inkább továbbfejlesztés. Már leírtam, de még egyszer megteszem, hátha nem olvastad el, a 2.0 óta legalább 4 fő verzió jött ki(SPx-eket is beleértve), nem tudom mit változtattak(ha változtattak), nem tudom miben jobb(ha jobb), nem tudom mennyivel gyorsabb(ha gyorsabb), semmit nem tudok semmiről
, csak azt, hogy valaki állít valamit, valamiről, annak ellenére, hogy semmilyen tapasztalata nincs róla(de ezt is leírtam már). Viszont azt még nem írtam, hogy elfáradtam(hosszú volt az éjszaka), úgyhogy részemről "flick off the switch".
-
DRB
senior tag
Ezt már megbeszéltük, de hogy pontosan megértsd mire akarok kilyukadni: azt tartom furcsának, hogy valamiről állítasz valamit, úgy, hogy semmilyen tapasztalatod( a saját elmondásod alapján) nincs az adott dologgal kapcsolatban. És nem is nagyon hajlasz, hogy megszerezd ezeket(bár ezt természetesen nem is erőltetném, hiszen semmi közöm nincs hozzá). Talán azért is jöttem egy autós példával az előbb, hogy rámutassak, itt nem a .NET-ről szólnak a kérdéseim, hanem arról, hogy semmilyen saját tapasztalatod nincs egy adott dologról(legyen az .NET, autó vagy akár mondjuk a főzés), de ennek ellenére tényeket, konkrét dolgokat állítasz róla.
-
LordX
veterán
Meg tudom erősíteni azt, hogy a managed kód NEM szignifikánsan lassabb, saját méréseink szerint is +-10% a különbség - igen, lehet a managed akár gyorsabb is, mert standard C/C++ esetben a fordítónak "általánosan" optimális kódot kell csinálnia, a JIT meg az aktuális adatokkal való futásra optimalizál, ezáltal jobb eredményt is elérhet, mint a natív.
Azért alakult ki az a nézet, hogy a .NET szar, lassú, mert jóval egyszerűbb benne programozni (vitathatatlanul a legjobb programkönyvtárak vannak hozzá), ezáltal retardált idióták is "sikeres" programokat tudnak benne csinálni. Ugyanazt a programot nagy tapasztalatú ember készítette volna, ugyanolyan sebességű lett volna, mint a natív verzió.
-
DRB
senior tag
-
Pikari
veterán
,,Pikari pedig nem'' így van, pikari nem szereti, és el is mondta hogy miért. Pikari továbbá nem érti, miért kell a dotnet fanoknak állandóan görcsösen védelmezniük a kedvenc nyelvüket. Úgy se tudják. Ez olyan mint amikor a csernobili párttitkárok kiterelték a népet a május 1. felvonulásra merthogy NINCSSUGÁRZÁS NINCS NINCS. Hát ha nincs, akkor csak meneteljél benne, de ne vidd már bele a szerencsétlen gyerekeket a cézium izótópokba tapicskolni. Felesleges ehhez ragaszkodni, ez nem családtag, hanem egy ,,platform'', tanuljatok meg értelmes programnyelveket inkább.
,,Apropó: a 4-es .NET JIT képes SIMD (vagy esetleg CUDA) optimalizációra?''
Az autómatikus CUDA érzésem szerint kizárt. SIMD-et biztos hogy tud, legalábbis SSE2-ig bezárólag tuti. -
Alchemist
addikt
Szerintem azért beszéltek el egymás mellett, mert ha a .NET keretrendszert intenzíven használó, elosztott erőforrásos rendszert fejlesztek, akkor többnyire nem a saját kódom JIT fordításának hatékonysága lesz a szűk keresztmetszet.
Viszont ha a .NET ficsörök nélkül sokat számolgató optimalizált algoritmusról van szó, az architektúrára optimalizált unmanaged kód (pl. Intel Compiler, SIMD használattal, stb.) sebességben agyonveri a .NET kódot.
Apropó: a 4-es .NET JIT képes SIMD (vagy esetleg CUDA) optimalizációra?
-
-
#72
zola8van8
tag
killerjohn
#69
zola8van8
tag
válasz
killerjohn
#69
üzenetére
Te szereted a .NET-et
, Pikari pedig nem -
#71
Pikari
veterán
killerjohn
#69
Pikari
veterán
válasz
killerjohn
#69
üzenetére
a-a. mi mindig rilizt fordítunk.
-
#69
killerjohn
addikt
Pikari
#49
killerjohn
addikt
Felhívom a figyelmet rá, hogy az tényleg igaz, hogy natív C kód debuggerből futtatva tényleg (sajnos) 10x gyorsabb mint C# debuggerből (sima F5-ös indítással). Normálisan, debugger nélkül futtatva ez megszűnik (Ctrl+F5). És tényleg, valami nagyon elnéztetek a C# kódban
Javasolt profiler (ANTS) használata, és mindenre fény derül! Rögtön rájöttetek volna, hogy hol a gond (nem a .NET-ben van hidd el).
-
Pikari
veterán
nem. az én álláspontom az az, hogyha én lennék a magyar népköztásaság autóipari biztosa, és rendelkeznék két hasonló tervvel, az egyik autó a Trágyeszku 4500 ami 80 kmh-s sebességgel 100 kilóméteren megeszik 8 litert, és 10 ezerből lehet gyártani, a másik pedig a Nyomottpevics Vaszilij, ami 60 kmhval tud csak menni és megeszik 100 kilóméteren 20 litert, akkor a Trágyeszku 4500 kerül gyártásba, a Nyomottpevics Vaszilij tervei meg eladásra kerülnek valami lúzer afrikai gyarmatország számára mint AAA osztályú autómobil.
-
DRB
senior tag
Bocs, hogy ezt írom, de egy kissé fafejű vagy, de nincs harag ugye?
Autós példa: Szóval a Te álláspontod szerint, ha az 1.3-as porlasztós VW Golf II-es szar, akkor Golf VI-os 1.4 TSi is az Szerk: Lövésem nincs, hogy jött ez az autós példa, ne is kérdezd, maradjunk annyiban, hogy ezt dobta ki az agyam.
(hosszú volt a péntek éjszaka) -
Pikari
veterán
-
nyunyu
félisten
de lehet 12 magos szerverprocesszorokat is kapni az AMDtől a cucchoz képest viszonylag olcsón, következő hardverlépcsőnek talán megteszi majd.
Gatyad is ramenne.
10 magos (+HT) Xeon E7-nek 4600$ darabja.
Hozza megfelelo alaplap az mar olcso, ~150k HUFbol megvan.(BI kollega eppen most szamolgatta, hogy megeri ilyet venni SQL Server Enterprise ala, olcsobban jon ki, mint ket 4 magos szerver+hozza 2 szoftverlicensz.
) -
-
joeshow
csendes tag
Egyetértek azért ez így eléggé fekete/fehér lenne.
Az sem állja meg a helyét hogy a .net minden helyzetben mindenre jó mert nagyon nem, de az sem hogy mindenre rossz lenne van amit eszembe sem jutna másban csinálni mert egyszerűen a legmegfelelőbb az adott környezetbe(ha adott egy windows/mssql környezet nem fogok javával bohóckodni, ha pedig cross platform alkalmazás kell csakis javát használok). És sajnos egy régi DOS-os projektet C-ben de nem nehéz kitalálni melyikkel van legjobban tele a tököm.
-
Pikari
veterán
-
Ne viccelj már...most tényleg egyetlen egy konkrét feladatban volt problémád/problémátok a C#-al és akkor az már szar?!
Valószínűleg az a szoftverfejlesztési "jótanács" miszerint: Meg kell vizsgálni, hogy az adott feladat megoldására mi a legmegfelelőbb eszköz. Nos szerinted ez hülyeség, és használjunk mindenre C/C++-t????
-
#49
Pikari
veterán
killerjohn
#47
Pikari
veterán
válasz
killerjohn
#47
üzenetére
Akkor elmondok egy másik példát is, ezt ismerősömmel közösen csináltuk, kellett mindkettőnknek gyakoraltilag ugyanaz a kód egy grafikai szimulációjához, ezért összeálltunk picit. Ez a projekt lényegében arról szólt hogy érdemes lenne -e ezzel a fajta grafikával realtime produktumokban foglalkozni (legalábbis az én fő motivációm ez volt, hogy megkapjak egy ilyen alapkódot). Ő c#-ban utazott, én inkább a C-ben szerettem volna írni a kódot, de végülis kb egyszerre írtuk a kódot, gyakoraltilag folyamatosan láttuk a másik kódját. Pár napnyi gondolkozás után megterveztünk egy nagyon gyors ray tracer algoritmust, amire pár (90) órajelet saccoltunk, aztán hamar összeraktuk az alapkódot, természetesen ő c#-ban én pedig C-ben, amikor simán üresjáratban hívtuk ezt a kódrészletet akkor olyan túl sok különbség nem volt (a C kód kb 3x volt gyorsabb). Aztán köréhúztuk a frame buffer kezelést, kerestünk egy geometriát, írtunk egy textúracímzőt meg magát a globális bevilágítást lehetővé tevő algoritmust (ezek már saját fejlesztésű algoritmusok voltak amibe további 2 szakmbabélit bevontunk) és végülis pár hét alatt amikor épp ráértünk, 4en megterveztük ezt a rendszert, és mindenki megkapta a saját forrás-forkját korlátlan használatra. Aztán a C és a c# szimulációjának összehasonlítása mellett döntöttünk, kb egy jó 3x-es sebességkülönbségre számítottunk (mivel maga cutting code ennyi eltérést produkált) Felnyomtuk a frame buffert 1024x1024ra, 27x-es AA, és az egész alá egy nagyon MINIMÁLIS geometriát raktunk be (tehát csak párszázast, szépen elhelyezbe, benyomtuk rá az effektek egy részét, ugyanúgy, mindkét nyelvben) aztán compile, és run.
A C alapú kód az egész művelettel egy 2000+os Athlonnal (1 szálú volt akkormég) 18 másodperc alatt végzett. A c# kódnak ugyanehhez a képhez kellett 38 PERC. Először azt hittem, hogy valami zavar van az erőben, de nem. Mind a 4en ráugrottunk a c# kódra, kb 2 napig bűvöltük az amúgy nem túl hosszú forrást, hogy hát ennyire csak nem lehet crap, biztos valahol valami hiba van. Nem volt. Számomra ez volt az utolsó csepp a pohárban, a de c#-s emberke is nagyon elgondolkozott az eddigi életén. Végülis aztán rá fél évre feladta az egészet és c++-ra váltott. Nekem több bizonyíték a c# csodálatos erejéről már nem kell. -
#47
killerjohn
addikt
Pikari
#44
killerjohn
addikt
Ez már így is két éves vas. Arcom meg nincs magasan, mert még soha nem spammeltem a fórumokban programozásról, de felment a pumpám amiatt hogy
1) már a blog bejegyzés is szánalmas, pontatlan
2) elmebeteg hsz-ekkel lehúzták a .NET-et irrálisan. Senki nem vitatja, hogy a natív kód, vagy akár a gépi kód ne lenne gyorsabb. De az 50-es szorzó kicsit kihozott a sodrombólszerk: 1 magon fut le 0.8 mp alatt!! nem 16 magon. Direkt nem lett többszálúsítva, hiszen minek?
-
#44
Pikari
veterán
killerjohn
#41
Pikari
veterán
válasz
killerjohn
#41
üzenetére
Nyugi, nem akarlak bántani, csak picit birizgáltam a bajszod, hogy egy kicsit lejjebb tekerjem az ,,arc'' fokozatodat, és ez utóbbi hozzászólásod hangvételéből úgy látszik hogy sikerült is
Azzal meg hogy milyen hardverkiszerelésben vannak ezek a procik, tisztában vagyok, amúgy offtopic, de lehet 12 magos szerverprocesszorokat is kapni az AMDtől a cucchoz képest viszonylag olcsón, következő hardverlépcsőnek talán megteszi majd.
-
#43
killerjohn
addikt
WonderCSabo
#37
killerjohn
addikt
válasz
WonderCSabo
#37
üzenetére
Nem igazán. 200-300 tábla, iszonyat bonyolult relációk, kb 8000 normatíva cím van. Mindegyiket teljes tanuló bontásban kell hozni. Ahogy eredetileg megírták, SQL-ek futottak le memory típusú táblákon (postgres). Ahogy mi írtuk meg, az olyasmi mint egy "neurális háló" (jujj ez fellengzősen hangzik, de nem tudom jobban leírni) a memóriában. Csak ez 4 hónap fejlesztés volt. Meg tudtunk volna csinálni mi is SQL-ben 1 hónap alatt... de egy csöppet hálásabbak az iskolák hogy egy normatíva adatszolgáltatásnál 10-15 generálás esetén nem kell 30-70 perceket várni (nagyon kis iskoláknál meg volt 30 perc alatt...)
-
rt06
veterán
megkerdezhetem, hogy mivel foglalkozol, es mennyi idos vagy?
csak mert miutan igy lehuztad az egesz forumot, annak minden tagjaval, s melle olyan dolgokat irsz, amiket nem igazan tudok hova tenni, jelenleg a hozzaszoalsaid korulbelul a lefosomabokamataorhogestol kategoriaba esnek -
#41
killerjohn
addikt
Pikari
#36
killerjohn
addikt
16 magos te értetlen
az 4 processzor. A Budapest Főváros önkormányzatának összes közoktatási intézménye ezen fut. Elektronikus Naplóval, amit a szülők nézhetnek otthon. Normatíva generálással, amivel kb 130 ember 1 havi munkáját csinálja meg a rendszer 1 kattintással, 2 perc alatt. Okoska. Ha meg bármi rálátásod lenne a világra, akkor tudnád, hogy ezek nyilvános szerződések, és az iskola fizet érte, mint a Windowsért meg a wc papírért. -
Gregorius
őstag
Ha nincs egy lebutított példád, ami beazonosítja, hogy hol van a performance bottleneck, akkor nyilvánvalóan nem is foglalkoztál mélyrehatóan a kód optimalizálásával. Akkor pedig miről beszélünk?
Linkelhetsz jól dokumentált (forráskód, mérési metodika, stb.) teszteket másoktól is, ha találsz.A többszázezer forintot érő kód az nudli. Az pár emberhónapból is csak szűkösen jön ki. Majd tízmillió fölött esetleg komolyan fognak venni.
-
#37
WonderCSabo
félisten
killerjohn
#18
WonderCSabo
félisten
válasz
killerjohn
#18
üzenetére
egy normatíva generálás az Államkincstárnak 70 percig futott / iskola.
Most egy darab 16 magos szerveren fut, ~15% processzorhasználattal, ASP.NET-es frontendekkel. A normatíva generálás pedig 0.8 másodperc / iskola.Az az első program akkor eléggé el lett cseszve.
-
#36
Pikari
veterán
killerjohn
#33
Pikari
veterán
válasz
killerjohn
#33
üzenetére
Értem, tehát arról van szó, hogy van egy 16 processzoros szerver, amelyre írtak egy oktatásüggyel kapcsolatos egyszerű központi nyilvántartó programot 2 év alatt, valószínűleg brutális mennyiségű közpénzből. Attól tartok, hogy ezt kötelességem jelenteni a korrupcióellenes hivatalnak.
-
Arhquis
aktív tag
Szerintem ezt a gondolatmenetedet már ne eröltesd tovább. Azért mert 5-szörösére fog nőni az ország lakossága, még ugyanúgy elég lesz az a 6 mag. Főleg, hogy szokták a db-ket mentegetni is, és az adatokat memóriában, és nem cache-ben mentik a dbserverek feldolgozásra.
Továbbá le a kalappal azelőtt, hogy ilyen komoly progit írtál. De mint te is mondtad, sosem volt tapasztalatod nagy rendszerekkel. A fejlesztési idő leosztásából következően egyszemélyes fejlesztőcég az, amiben te ténykedtél eddig. Megkockáztatom még tanuló vagy. Rossz hírem van, rengeteg időbe telik egy project elkészítése, főleg ha belevesszük az előmunkálatokat, a kollegák összedolgozásából fakadó problémákat, hibák felderítését/kijavítását, és természetesen a biztonságot.
Egy alap appot én is megírok neked egy hét, de megkockáztatom egy délután is, csilli villi GUI-val ráadásul. De mint killerjohn is írta, ők nem a sarki hentesnek írtak raktár rendszert.
-
#34
Pikari
veterán
robotjatek
#32
Pikari
veterán
válasz
robotjatek
#32
üzenetére
Eszemben sincs lealacsonyítani a fórumot, de ide főleg gamerek járnak, akik nagyrészt érdeklődnek kicsit más témák iránt is. Nyilván egy 1992ben született személy, aki Comradenak hívja magát, és fontosnak tartja hogy az aláírásába a rendszermemóriájának a vércsoportját is beírja, közelebb áll a gamer definícióhoz, mint például a hálózati mérnök definícióhoz
-
#33
killerjohn
addikt
Pikari
#30
killerjohn
addikt
neked elment az eszed
DD ezen már csak röhögni tudok. ember...
szerintem még az órarend tervező részét sem tudnád megcsinálni 2 hét alatt
És a generálót? ha megcsinálod, megveszem. Két milla. Eskü. Most.
Kb 700 szabály van, ami szerint valaki valakinek valamit valamikor taníthat.Tudod te milyen szabályok vannak a közoktatásban? Öcsém, mert nálad "osztaly", "tanulo", meg "join_tanulo_osztaly" tábla egy iskola...
DD kész, azóta röhögök hogy elolvastam amit írtál -
#30
Pikari
veterán
killerjohn
#24
Pikari
veterán
válasz
killerjohn
#24
üzenetére
ha szerinted 130*2 = 16, akkor rossz híreim vannak. Bár ha 2 évig fejlesztetted ezt a szoftvert, akkor a hardver ára tulképp teljesen mindegy a szoftver árához képest. Mondjuk nem tudom elképzelni hogy egy egyszerű nyilvántartó szoftveren mit kell 2 évig fejleszteni, én egy ehhez hasonló projektet 2 hét alatt fejlesztettem ki egyszer GUI-val, igaz, abban nem volt kliens-szerver comm.
,,Így simán elleszünk még 3-4 évig''
Igen, tényleg, ekkora születésszám mellett simán 5x ekkora lesz az ország lakossága 4 év múlva, kell a sok iskola, fő a józan paraszti ész, elvtársak -
Én csak azokból az adatokból következtettem amiket fent megadott...Korábban 1 szerver/iskola ment 70 percig.(Összesen 130 szerver) Simán el tudom képzelni, hogy addig senki nem tudta érdemben használni a rendszert amíg a feladat tartott...Láttam már ilyet. Az új rendszer számadatait figyelembe véve(0.8s) programnyelvtől függetlenül van eredménye a vasnak. Mondjuk elvileg korábban 130 gép volt egyenként....tehát itt már egyéb körülményeket is figyelembe kell venni pl fogyasztás... Mondjuk én valószerűtlennek tartom, hogy ugyanezen igényeket egy 4 magos szerverrel ki tudnál szolgálni.
-
Arhquis
aktív tag
Habár nem írtam olyan kódot, mint amiről te beszélsz, de valszóníűnek tartom azt, hogy nem maga a számoló algoritmus okozott ekkora lassulást. Gyanítom, használtál valamit a megjelenítésre, hiszem fps-ről írsz, ami már önmagában torzítja az értékeket.
Ami a lényege lenne a .net-nek, az nem a gyorsaság. Természetes ilyen jellegű technológiánál (amilyen a Java is), hogy lassabb mint a natív kódok. A .net ereje abban van, hogy relatív rövid idő alatt biztonságos kódot írhatsz, akár nagy rendszereket, és minderre olyan eszközkészleted van, ami egészen klienstől szerverig terjed. A komponensek jól dolgoznak együtt, támogatják egymást.
Például pont a php+sql példádra ott van az Entity Framework.
-
#26
killerjohn
addikt
joeshow
#22
killerjohn
addikt
a fejlesztőknek meg kellene tanulniuk pl hogy mi hogy működik, és nem csak kibattyogni a műegyetemről kb 0 programozási tudással. Aztán ha már tudja, hogy mi mit csinál, akkor rögtön látja, hogy hol, mit, mire kell használni.
Igenis, a .NET van olyan gyors, mint a natív (5-10% eltérés mutatkozik). Ha valaki mást állít, az csak tudatlanságból fakad. Az hogy vannak benne Eszközök, melyeket megfelelően meg kell választani a Célok eléréséhez, igen, Tudást igényel. Akinek nincs, az meg jöhet a fórumokba sírni, hogy milyen szar, hogy az XML lista lassabb mint az int[]
-
#22
joeshow
csendes tag
killerjohn
#18
joeshow
csendes tag
válasz
killerjohn
#18
üzenetére
Csakhogy az első bekezdésed az nem arról szól, hogy mennyire rohadtul gyors a .net 4 de milyen lassú a java hanem, hogy ti zsenikként ilyen rohadt jót csináltatok az előző cég meg egy szart java-ban."Ha a hal nem tud úszni, nem a víz a hülye."
És a .net 4.0 tényleg sokat javult, de hogy még a 3.5 is hihetetlenül erőforrás igényes volt azt nem lehet vitatni(és nem minden cég fog 4.0-ra frissíteni csak azért mert a fejlesztő azt mondja hogy optimalizáltak).
Van olyan hely ahol .net 2.0 MSSQL 2008-al futkározik, és nem fognak frissíteni mert ki kéne fizetnie az upgradeket. Úgyhogy én azért nem fogom a .net tökét pont a teljesítménye miatt nyalogatni.(De persze tudom a .net alap, hogy gyors csak hülyék a fejlesztők, de hát nem lehet mindenki olyan nagy sztár hogy mindenféle minisztériumoknak írogasson teszteket for ciklusokról vannak sajnos ilyen buta programozók is).
-
-
Nagyon nem akarok beleszólni, de gondolom nem azért van 16 magos szerver a szolgáltatás alatt, mert most éppen pont ennyi kell a kiszolgálásához...Nyilván az időközben felmerült plusz igények miatt ne kelljen vasat cserélni. Azért valamennyire időtálló kell legyen a vas, mert nagyon hamar belassulhat a fejlődés...
-
#19
Pikari
veterán
killerjohn
#18
Pikari
veterán
válasz
killerjohn
#18
üzenetére
Ha neked 35ezer felhasználóhóz 16 magos szerver kell, akkor te valamit nagyon elrontottál. Ennyit még egy egyszerű php + sql-es fórum is elbír sokkal gyengébb gépen. Én egy egyszerű fizikai szimulációt írtam C-ben és c#-ban, bounding box alapút. Ez lényegében pár igen egyszerű összeadó/összahasonlító algoritmus egymásba épített sorozata. Ezt követően párszáz ilyen bounding boxot elhelyeztem, és lemértem a sebességet, a C-ben (s, o3) írt kód 55, a c#ben írt kód pedig 3 fps-en futott. A dotNET és a C# lassú. A hozzászólásod többi része pedig konkrétum nélküli humbug.
-
#18
killerjohn
addikt
Pikari
#12
killerjohn
addikt
nálad elmentek otthonról, már bocs
.NET-ben 2 év alatt írtunk egy iskolaadminisztrációs rendszert, amiben 60000+ gyerek adatai vannak, kb 35000 rendszeres felhasználóval.
Előtte java-ban írta meg az előd cég. 130 szerveren (minden iskolának 1db) futott a cucc, és egy normatíva generálás az Államkincstárnak 70 percig futott / iskola.
Most egy darab 16 magos szerveren fut, ~15% processzorhasználattal, ASP.NET-es frontendekkel. A normatíva generálás pedig 0.8 másodperc / iskola.C#-ban.
írjál kérlek 1-2 teszt programot natív C-ben meg .Net 4 C#-ban...
Arról hallottál már, hogy van egy izé kütyü valami amit JIT compilernek hívnak?
Imádom amikor tapasztalat nélkül teletrollkodják az emberek a fórumot. Ja, persze hogy tapasztalat nélkül, hiszen ha lenne, akkor nem írnál ilyet le.
Mi 2 hónapon keresztül írtunk tanulmányt és tesztprogramokat az Informatikai Ügyosztálynak a különböző fejlesztői keretrendszerek és programozási technikák ("best practices") teljesítményéről, előnyeiről, hátrányairól. Olyan szintig, hogy vajon a következő 2 kód közül melyik a gyorsabb:
int i;
for (i = 0; i < 100; i++) { do something };vs
for (int i = 0; i < 100; i++) { do something };És ebből 1000 ilyet csináltunk. SOHA sem mértünk 5%-nál nagyobb eltérést a managed és unmanaged kódok között.
Aztán nehogy azzal gyere hogy a foreach bezzeg 5x lassabb, mint asm-ben egy loop, mert ha sebességre optimalizálsz, akkor a foreach nem opció, ha viszont 10 elemű listán kell végigmenni, akkor leszarod a 0.0000000000000000001 mp CPU időt, és foreach-el írod, mert úgy kompaktabb a kód...
Amíg fel sem merül az emberek többségében, hogy vajon miért 60x lassabb 4 egymásba ágyazott foreach mint ugyanez for ciklussal, addig mindig tele lesznek a fórumok ilyen "okos" benyögésekkel, minthogy a .NET lassú
Simán csak beírják hogy "szar és kész". -
zola8van8
tag
A rákényszerítésbe még nem gondoltam bele, de igazad lehet!
Minden nyelvnek megvan az előnye hátrány. A .NET kód első használatkor tényleg nagyon lassú, de ha többször kell használni ugyan azt a kódrészlétett, akkor elenyésző a különbség ( én így tanultam )szerk.: (#14) Arhquis: AMS-ben milyen szép és gyors programok lennének, csak soha nem készülnének el
-
-
#13
killerjohn
addikt
zola8van8
#11
killerjohn
addikt
válasz
zola8van8
#11
üzenetére
ott a pont (és egyel feljebb)!
Ez az amit a java baromira nem tud...
Egy java frissítés (amiből kb hetente van...... no comment) után simán elérhetetlenné váltak a szervereim IPMI felületei.
Alaplap support válasza: bocs, a legutolsó Java frissítésben valamit nagyon elkúrtak, ezért az IPMI bukta...
Kérdem: megoldás?
Válasz: java update uninstall, X verzió install, mert azzal megy.Meg is csináltam, csakhogy nem volt hajlandó menni, mert mindenképp (tudjátok, amikor 1 db OK gomb van a felületen) frissíteni akart a legutolsóra. Na azóta a java csak egy vicc a szememben (előtte is az volt a teljesítménye és egyebek miatt, de ez feltette az i-re a pontot).
-
Pikari
veterán
A dotNET keretrendszer az egyik legrosszabb keretrendszer, amivel valaha találkoztam.A c# sebessége a natív kódhoz képest valódi felhasználás során huszada az elvárhatónak, a környezet alapkompatibilitása pocsék és nevetséges, a crossplatformság csak a microsoft platformjaira létezik hivatalosan, másra csak silány minőségű nemhivatalos klónok vannak.
A dotNET keretrendszer azonban azért különösen veszélyes, mert terjesztéséhez a Microsoft agresszív, felsővezetést megnyerő, hazugságokra és propagandára építő politikát folytat, továbbá a dotNET keretrendszer előtérbe szorításával a Microsoft agresszívan a saját rendszereire kényszeríti a fejlesztőket, különösen azokat, akik kevésbé értenek az iparhoz, hisz a dotNET látszólagos egyszerűsége számukra csábító lehet. A dotNET tehát valójában egy káros, monopolizációs folymat egy állomása, ráadásul a dotNETben írt szoftverek összességében pocsékabb élményt nyújtanak mint a konkurens natív programok.
-
zola8van8
tag
Kicsit pongyolán megfogalmazva, azért van fent a korább .NET mert amit arra írtak programokat az fusson rendesen. Szóval azért van pl . NET 3 a gépeden, mert amit arra írtak kódot az úgy fusson mit akkor és pont úgy fog menni 5 év múlva is, hiába tartunk majd a .NET 3000-nél
-
Gregorius
őstag
A .Net a Microsoft szoftverfejlesztői keretrendszere, mely egyfajta válaszlépésnek tekinthető a Sun platformfüggetlenként deklarált Java csomagjára. Fejlesztése a kilencvenes évek végén indult meg, az akkoriban használt Microsoft-féle Java implementáció felváltásának céljából
Tudtommal a COM+/ASP leváltásának és egy egységes, biztonságos web platform kialakításának a céljából indult meg a fejlesztés. Aztán egy Javához nagyon hasonló vázlat alakult ki a tervezéskor, amit felismerve két legyet lehetett ütni egy csapásra. De szó nincs arról, hogy a projekt alapkoncepciója az lett volna, hogy üssünk jól oda a Sunnak.azt mondjuk nem tudom, hogy a 4-esben benne van-e a 2, 3 is, feltételezem, hogy igen
Nincs. Valamennyi átjárás van a kettő között: 2.0-3.5-re írt alkalmazást tud futtatni a 4.0, ha a 3.5-ös framework nincs fent (app.configban beállítható programmódosítás nélkül), de a kompatibilitás nem 100%. -
#9
joeshow
csendes tag
killerjohn
#7
joeshow
csendes tag
válasz
killerjohn
#7
üzenetére
"Mivel az új verziók a korábban feltelepített verziókba nem pofáznak bele (teljesen másik könyvtárban vannak), ezért az kizárt, hogy a .NET 4 telepítése után visszamenőleg, korábbi verziókra fordított programok ne működjenek"
Kár hogy az említett probléma éppen az, hogy egy szűz gépre "csak" a 4.0 kerül fel akkor ott nem igazán van már korábban telepített amibe beleszólna és ilyenről amúgy sem volt szó de én kérek elnézést.
-
#7
killerjohn
addikt
killerjohn
addikt
úristen, írtok itt összevissza mindent
popcorn elő 
egyébként a cikk alapból nem tudom mikor íródott, mert hogy nem idén áprilisban jelent meg a 4
egyébként minden .NET-ben írt program fordításánál bekerül hogy pontosan melyik verziójú .NET reference (értsd: assembly-t, DLL-t...) használ a program. Mivel az új verziók a korábban feltelepített verziókba nem pofáznak bele (teljesen másik könyvtárban vannak), ezért az kizárt, hogy a .NET 4 telepítése után visszamenőleg, korábbi verziókra fordított programok ne működjenek (ezzel ellentétes tapasztalat kizárólag programozói hanyagság, hozzánemértés, eszetlen barmolás a configokban, stb miatt lehet).
-
joeshow
csendes tag
Hát igen mindenhol ez a reklám hogy 2.0 óta kompatibilisek.
.net 3.0-ban fejlesztett alkalmazásom ami SQLCE adatbázist használ tisztán .net 4.0-t telepített gép a CF 3.5-el runtime- al már száll is el. És egy .net 3.5 feltelepítése után gyönyörűen fut úgyhogy szerintem hogy kompatibilisek erősen idézőjeles.
no offense én egy jó dolognak tartom a .netet de nagyon sok a felesleges marketing ami sajnos nem igaz.sorry később láttam az új hozzászólásod tehát nem a 4.0-ben nincsenek benne a régiek és ezért azt is mondom hogy visszafele a 4.0 nem kompatibilis
-
moonman
titán
-
#2
WonderCSabo
félisten
WonderCSabo
félisten
Managed C#
Managed C++ lesz az.
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Nekem úgy tűnik itt hiába érvelsz logikusan valami mellett.
Új hozzászólás Aktív témák
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Okos konnektor: tényleg spórol az áramon, vagy csak pénzkidobás?
- Linux kezdőknek
- Google Pixel 10 és 10 Pro összehasonlító gyorsteszt
- Xiaomi 14T Pro - teljes a család?
- A fociról könnyedén, egy baráti társaságban
- Mégis marad a Windows 10 ingyenes frissítése
- Diablo IV
- Milyen házat vegyek?
- További aktív témák...
- AKCIÓ! Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával - Nint.hu
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- PC Game Pass előfizetés
- Játékkulcsok a legjobb áron: Steam
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- ÚJ Lenovo ThinkPad X13 Gen 5 - 13.3" WUXGA IPS - Ultra 5 135U - 16GB - 512GB - Win11 - 2,5 év gari
- HIBÁTLAN iPhone 14 Pro 256GB Gold -1 ÉV GARANCIA - Kártyafüggetlen, MS3519
- Samsung Galaxy S24 Ultra 256GB, Kártyafüggetlen, 1 Év Garanciával
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest