- Xiaomi 15 - kicsi telefon nagy energiával
- 45 wattos vezeték nélküli töltés jön az új iPhone-ba
- iPhone topik
- Google Pixel topik
- Apple iPhone 13 Pro Max - őnagysága
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Ilyen lesz a Fairphone 6
- LG V50 ThinQ Dual Screen - az 5G ára
- Keretmentesít a Galaxy S25 FE
- Középkategóriást mutatott be újra az Oppo
-
Mobilarena
Új hozzászólás Aktív témák
-
Silεncε
őstag
válasz
pmonitor
#15750
üzenetére
Első: hát ő... lelked rajta, bár nem tudom, neked miért jó, ha egy nicknév helyett Kovács Béla ad segítséget (illetve sejtem...)
Második: ezzel a meghatározással akkor egy autoteszter (nem megsértve egyetlen ilyen munkakörben dolgozó személyt) teljeserteku programozonak számít, míg mondjuk egy architekt nem. Azért én itt érzek kis problémát.
Harmadik: ez egy fórum, ahova az emberek a szabadidejükben járnak. Nem gondolom, hogy nekem vagy itt bárkinek kötelessége lenne folyamatosan lesben állni és minden kérdésre azonnal válaszolni, főleg, hogy vannak témák, amikhez nem is értek (pl a C#-os kérdésed, mivel C#ot egyedül az egyetemen láttam egy kurzuson, akkor is csak futólag). De pl a JS topicban szoktam segíteni, ha tudok, de ezt nem várhatod el bárkitől, hogy ingyen és bérmentve azonnal megoldja a problémáidat
Livius: nekem ezt úgy szokta mondogatni a leadunk, hogy KISS. Keep it stupid simple
-
cattus
addikt
válasz
pmonitor
#15750
üzenetére
Egy alapvető dolgot úgy látom még mindig nem veszel figyelembe: ez egy önkéntes fórum, ahova emberek a szabadidejükben járnak hogy másoknak segítsenek / segítséget kérjenek másoktól. Nem egy szolgáltatás, senki sem kap kompenzációt azért mert ide kommenteket ír. Mindezt ennek megfelelően kell kezelni, ezt te jól láthatóan nem érted vagy nem akarod megérteni.
-
Silεncε
őstag
válasz
pmonitor
#15742
üzenetére
Lehet, hogy igazad van. Bár volt aki segített. A permutációk témában pl. 2-en is. Sok kérdésem meg nem is volt azon kívül, mint ez. Sztem inkább arról van szó, hogy lövésük sem volt a megoldáshoz, hiába programozók vannak itt.
Definiáld már légyszives, hogy mikortól hívhatja valaki magát programozónak szerinted. (még mielőtt: én nem hívom magam annak, mégha papírom van is róla)
Korábbi hsz-ed:
Tegnap délelőtt tettem fel ezt a kérdést a fórumban. Még választ sem kaptam rá. Azóta megoldottam ezt is, sőt, az egész feladatot, amit célul tűztem ki magamnak.
Azért egy progos topicban szerintem nem olyan kirívó, hogy egy nap alatt nem érkezik válasz
-
Ispy
nagyúr
válasz
pmonitor
#15742
üzenetére
Mondjuk a játékot annyira nem vágom...a .net alól win32 hívás nekem a hack kategória, akkor látom max. jogosultságát, ha sehogy nem lehet valamit megoldani a keretrendszeren belül. A lényeg szerintem, hogy egyszerűen fogad el, hogy a c gyorsabb, ennyi. És ne fikázd, hogy a c# mekkora egy...játéknyelv, mert nem az, egyáltalán nem. A c# egy gui fejlesztésre készített nyelv, ami hozzáfér a .net teljes libjéhez.
Ebbe a játéknyelvbe nekünk komplett TMS-ünk van, ráadásul nem is c#-ban, hanem vb-ben, tudom mire képes.
-
Livius
őstag
válasz
pmonitor
#15743
üzenetére
Képzeld nem tudom és nem látom értelmét se, mert azt full máshogy fordította le egy fordítóiroda az MS-nek, ahogy én gondolnám azt, és innentől kezdve a Google nem fogja azokat a találtokat hozni ami valójában kéne rá.
Netán ha lenne annyi eszed és angol nyelven használnád a fejlesztőkörnyezetet, akkor bármi ami előjön hiba, a Google-ba csak be kellene írni "... " idézőjelek közé és jönne 100 találat angolul, amiből az első három átlagosan tartalmazza azt ami neked is kéne. Googlezni is meg kell tanulni angolul, ez az első lépés ahhoz hogy valaki zökkenőmentesen tudjon programozni.
Ez meg amúgy elég indokolt eset, mert szakmai nyelv itt az angol, hiába linkelgetsz itt álalános fórum szabályokat, amik nyilván a hétköznapi topikokra lett átgondolva. -
dabadab
titán
válasz
pmonitor
#15734
üzenetére
Szerintem az állandó nyavalygásoddal elérted, hogy senki nem akar neked segíteni.
Eleve úgy jöttel erre a fórumra, hogy a saját oldaladat promóztad, ahol amiatt nyavalyogtál, hogy milyen emberek vannak itt és azóta is úgy viselkedsz, hogy semmi köszönet nincs abban, ha valaki segíteni próbál neked.
Ki mint vet, úgy arat. -
Livius
őstag
válasz
pmonitor
#15732
üzenetére
Ha már linkelsz valamit, legalább az angolul írt hibaüzenetet írd be mert így semmi sem kereshető ezen Google-val, hogy mi ment férre nálad. Amúgy, ha neked az az igényed, hogy beírsz valami problémát, és egyből böfögjék vissza a helyes hibajavtást és választ akkor barátom elég rossz helyen jársz. Erre ott van Stack Overflow oda írd be, jah de bocs igen ahhoz angolul kell tudni írásban, és jól kommunikálni ott, különben nem értenek majd meg. Gyanítom azért vagy állandóan elveszve abban, hogy mi a megoldás, mert nem megy az angol nyelvű keresgélés a neten, már pedig IT-ban angolul kell tudnod kötelezően, különben nem tudsz megoldani semmi komolyabb dolgot egyedül, és neked is angolul kell publikálnod, különben haszontalan az egész.
-
Ispy
nagyúr
válasz
pmonitor
#15734
üzenetére
Mondjuk egyfajta kommunikációs platform, ahol az azonos érdeklődésű emberek egymással gondolatokat tudnak cserélni úgy, hogy egyébként soha sem találkoznának egymással. Ebben benne van a segítség kérése és annak megoldása is, de ezt számonkérni enyhén furcsa. Eddig az ilyen fórumokon eddig 2 fajta kérdést láttam: az egyik max 30 perc guglival megtalálható, a másikért meg emberek fizetést kapnak, nem egy ilyen mond meg hogy kell kérdés, ki kell találni, ki kell taposni az utat, mindenkinek magának. Van egy harmadik is: nincs megoldás rá valamiért.
-
Livius
őstag
válasz
pmonitor
#15723
üzenetére
Kezdésnek például próbálkozz unmanaged tömbbel a C#-ban, és googlez rá, hogy Garbage Collector dolgaival hogy tudsz optimalizálni. VS2019-ben amúgy van performance analyzer, játszani kell vele, és googlezni a megoldásokat. A For loopban és akár if-ben pedig, könyörgöm, használd a { } blokk elválasztásokat és a ; után legyen már minden új sorban, mert így olvashatatlan a kódod. VS2019-ben far auto-formázás a cs fájlra, kezdésnek azt nyomd be.
-
-
Ispy
nagyúr
válasz
pmonitor
#15723
üzenetére
A probléma inkább továbbra is ott van, hogy nem arra akarod hasznáni a c#-ot, amire azt alapvetően kitalálták és mindenféle elméleti matematikai problémák megoldását erőlteted rá.
Google 1. találat a wiki:
C# (C-Sharp) is a programming language developed by Microsoft that runs on the .NET Framework.
C# is used to develop web apps, desktop apps, mobile apps, games and much more.Tehát ha majd c++ akarsz nekiállni egy web app-nak vagy desktop appnak akkor fogod megérteni miért is létezik egyáltalán a c#, azt hogy egyéként ki lehet belőle erőszakolni win32 hívásokkal mindenfélét, az még nem azt jelenti, hogy ez a normális. Ezért van a keretrendszer.
És igen, lassú, mert a c# egy magas szintű programnyelv, azaz az oprendszer felett futtatja a kódokat, amik emiatt mindent a keretrendszeren keresztül intéznek. A c++ meg natívan tud futni cserébe minden 100x bonyolultabb benne megcsinálni.
-
Livius
őstag
válasz
pmonitor
#15721
üzenetére
A C# továbbra sem játékszer, én inkább abban látom a problémát, hogy amikor valamit meg akarsz benne oldani akkor azt a low level szinten akarod, amikor pont azért van a C# hogy ne abban kelljen. A Google tele van olyan C# drive partícionáló és formázó példákkal, amik a windows alap diskpart.exe-ével együttműködve mindent megold, de gondolom ez neked úgyse jó, mert csak azért se.
Ha meg nem tetszik hogy lassú a .Net akkor tanuld meg azokat benne amitől gyors lesz. Általában amikor feltételezzük hogy lassú valami a .Net ben vagy valamiben a végén mindig kiderült hogy a user a hülye, és 10 szer optimálisabban is csinálhatta volna azt hogy már ne látszódjon lassúnak.
-
I02S3F
addikt
válasz
pmonitor
#15669
üzenetére
Sziasztok! Beszéltem dokimmal, hogy a programozás lassan megy. Konkrétan sokat töröm a fejem és ebbe el is fáradok.
Kávé és csokoládé fogyasztását javasolta. Meg ajánlotta, hogy vegyek ginko bilóbát.
Utólag rájöttem, hogy adott keretrendszer szintaxisát nem ismerem. Hiába is törtem volna rajta magam, segítség nélkül nem jövök rá.
Ti mivel serkentitek, frissítitek a gondolkodásotokat?
Szükséges beismernem, hogy nagyon lassan haladok a kódolással (szakdolgozat), de ez az első produktumom is.
-
sztanozs
veterán
válasz
pmonitor
#15663
üzenetére
Amit keresel azokat úgy hívják, hogy nyelvi csomagok. Általában vannak az adott (magasabb szintű) programozási nyelvekhez 'hivatalos' tárolók, ahol elérhetők ilyen kódtárak (vagy már lefordított függvénykönyvtárak.
Természetesen az esetek nagy részében ezek hatékonyságát és/vagy gyorsaságát senki nem fogja ellenőrizni (legfeljebb a kód tényleges felhasználói). Pythonhoz ilyen pypi, de ilyen a github is nyelvfüggetlenül (vagy a github előtti időkben a sourceforge).Amúgy szerinted ki töltené az értékes (és meg nem fizetett) idejét azzal, hogy más kódjait túrja hibák, optimalizálatlanság, memory leak, vagy csak hanyag implementáció után kutatva? Legfeljebb a "biztonsági kutatók", akik ezen hibákon keresztül, ilyen kódot futtató rendszerekbe juthatnak be (de a hibákat javítani ők sem fogják). De pl az, hogy egy sort vagy permutációs algoritmus nincs jól optimalizálva szerintem még az ő érdeklődési szintjüket se üti meg...
-
kovisoft
őstag
válasz
pmonitor
#15666
üzenetére
Mivel angolszász nyelvterületen más a terminológia. Ők - különféle jelzőket ráaggatva - több mindenre használják a permutation elnevezést, mi ezek egy részét szintén permutációnak, más részét (német mintára) variációnak hívjuk.
Ez talán a hivatalos angol elnevezés, de láttam már ezeket másképp is emlegetve:
ismétlés nélküli permutáció = permutations
ismétléses permutáció = permutations with repetitions
ismétlés nélküli variáció = k-permutations
ismétléses variáció = permutations with replacements
ismétlés nélküli kombináció = combinations
ismétléses kombináció = combinations with repetitions -
Ispy
nagyúr
válasz
pmonitor
#15663
üzenetére
Szerintem azért nincsen, mert a programozók munkája, hogy algoritmusokat írnak...meg fogod találni a neked szükséges eljárásokra a mintákat, részproblémákra a megoldást, de a feladatot neked kell megfogalmazni megtalálni a végeredményhez vezető utat, majd ezt kód formájába önteni. Pont ez az a része a programozásnak, ami izgalamas, ami kihívás, amiért én például szeretem csinálni. Sokszor én is refaktorálom a saját kódomat, először megcsinálom, csúnyán, behegesztve fix értékekkel, minél inkább lényegre törő módon, hogy minél gyorsabban eljussak az elejétől a végéig. Majd ha már így megcsináltam mindent, amire szükségem van, kitörlöm és megcsinálom szépen, kultúrált formában, elnevezésekkel, optimálisan, amennyire tudom. Senki nem fogja megmondani mi az ideális kód, mert mindenkinek más, mindenki másképp gondolkodik, jut el A-ból B-be. Így a net nem megoldások forrása, hanem sokkal inkább egy ötletbazár, ahonnan lehet ihletet meríteni.
-
Ispy
nagyúr
válasz
pmonitor
#15655
üzenetére
A programozáshoz az egyik legfontosabb skill a problémamegoldás (leánykori nevén gugli). Ezeken a fórumokon felrakott kérdések 99%-a olyan kérdés amilyenekkel egy programozó naponta találkozik 20 darabbal. Igen, kell kutatni, ki kell próbálni, ki kell gondolni, tehát melós sokszor. Sokan pont a meló részét akarják megspórolni. Én most kezdtem nodejs-ezni, kb percenként jöhettem volna ide a bajaimmal, inkább szoptam vele 1 órát, 2 órát, 1 napot, ha kellett.
A kódadás is olyan dolog, hogy aki napi 12 órát dolgozik, annak nem biztos, hogy van kedve mások helyett megoldani dolgokat. Van akinek ehhez van kedve, de ennek semmi köze ahhoz, hogy az illető tud-e kódolni vagy sem. Szóval ebből következtetéseket levonni elégé fail.
-
Silεncε
őstag
válasz
pmonitor
#15655
üzenetére
Az, hogy nem azzal kódot ad valaki, szerintem nem probléma. Néha eltévedek az említett portálra és beleolvasgatok a kérdésekbe. Egy nagyon nagy része a topikoknak gyakorlatilag házifeladat megoldás, a lusta infós egyetemistáknak. Pont ilyenkor jó, ha nem egyből a megoldást írják le, hanem megpróbálják rávezetni a delikvenst. Hátha szándékozik némi munkát is beletenni, nem csak nulla munkával várja az eredményt
tomko9710: én amikor hasonlót csináltam, a beautifulsoup nevű Python package-et használtam hozzá ([link]).
-
Livius
őstag
válasz
pmonitor
#15639
üzenetére
Igazából mindegy milyen nyelven publikálsz a GitHub-on. A lényeg hogy a GitHubon legyen fent, mert a Google és minden kereső a legjobb találatokat onnan hozza. Tehát ha valaki magyar nyelven keres valami olyat, amiről te csináltál ott valami repot és szép dokumentációt, akkor azt eléggé az első találatokban hozza majd elő, és innentől kezdve igen hasznos lehet az amit oda felraksz. Nyilván ha angol leírásokat írsz, azt világszinten még többen betalálnák a Google-vel. Amúgy minden mappádba rakhatsz egy Readme.md text fájlt, amiben a markdown syntaxissal csinálhatsz elég jó féle dokumentációkat és leírásokat. Ezek a legfontosabbak, hogy valaha valaki rád találjon a neten. Példa: [link]
-
Livius
őstag
válasz
pmonitor
#15628
üzenetére
Már régebben írtam neked hogy erre van a GitHub meg a többi ilyen nyílt repo kezelős közösségi oldal. Ha az utókornak és másoknak akarsz hasznosat alkotni, akkor oda kell felrakni a kódokat, lehetőleg angol leírásokkal. A jelenlegi privát weboldalad az internet süllyesztőjében elvész, nem sokra jó.
-
fatal`
titán
válasz
pmonitor
#15628
üzenetére
Ezek adott esetben ipari titkok (persze nem az általános algoritmusokra gondolok itt), szóval nem csoda.
Sok esetben pedig a gyorsaságnál sokkal fontosabb, hogy másoknak is olvasható maradjon a kód.
Az egyetemi jegyzetben egyszerűbb algok vannak, amiket könnyebb megérteni (vagy legalábbis ez a célja, nem mindig sikerül).
Egyszerű példaként sosem voltam képes megérteni, hogy miért a buborékrendezést tanítják elsőnek, ami lassú is és szerintem abszolút nem egy logikus megközelítés. Teljesen kezdőknek egy maxker/minker rendezés sokkal logikusabb (és gyorsabb is, persze nem a leghatékonyabb), mert szerintem sokkal közelebb áll ahhoz, ahogy az életben is rendez az ember.
-
sztanozs
veterán
válasz
pmonitor
#15626
üzenetére
Amúgy visszatérve az eredeti felvetére - egyetemi jegyzet vs optimalizált kód.
Legtöbbször az egyetemi jegyzetben levő kód az optimalizáció rosszabbik végén van (nem pedig középtájon), hogy a hallgatók jobban megértsék a kód működését és képesek legyenek elsajátítani az alapvető programozási technikákat.
Hacsak nem optimalzációs techikákról szól az adott tantárgy/témakör, szvsz nem fogsz találni még közepesen optimalizált kódot se.
#15628 - szerintem a StackOverflow-n van több olyan bejegyzés is, ami az adott eljárás optimalizációját tárgyalják ki.
Alapvetően ez nem egy programozási fórum, vsz nem fogsz találni túl sok fórumozót, akit ez különösképp megmozgatná (ráadásul úgy, hogy nyelvfüggetlen / nyelvek közötti optimalizációt szeretnél kibeszélni). Egyébként semmi nem akadályoz meg abban, hogy Logouton indíts erről egy sorozatot, és ha lesz rá kereslet a hozzájuk tartozó fórumtémák is aktívak lesznek... -
válasz
pmonitor
#15620
üzenetére
Most az 5 másodpercet így képzeld el:
- indul egy request magyarországon, ami átmászik még 5 microservicen
- az egyik kilő az usába és csak oda vissza kb. 500 ms tart az adat utazása (tegyük fel, hogy megkerüli a földet kb. fénysebeséggel)
- majd a végén még utófeldolgozás következikA való életben az 5 mp, vagy 3 vagy 10 mindig egy olyan meghatározott érték amit a user úgymond "kibír" stressz nélkül. Igen erről vannak kutatások. Nyilván célszerű a lehető leggyorsabb megoldásra törekedni.
A miért C#, Java, Python és nem C vagy ASM kérdésre a válasz pedig egyszerű. Az idő pénz és a felesleges implementációt megúszod. Nem neked kell a sokmindent is leimplementálnod.
Nem véletlenül van Spring és VM is pl.
-
martonx
veterán
válasz
pmonitor
#15620
üzenetére
Egy dolgot felett siklasz el. Te most a saját szórakozásodra programozol pár jópofa ciklust, és ezzel szórakozol, hogy hogyan lehet hatékonyabbá tenni, akár nyelv váltás árán is. Abba ne hagyd, ez egy nagyon hasznos hobbi!
DE ezzel szemben a rideg valóság az, hogy egyrészt a programmal szembeni követelményeket szinte SOHA nem a programozók határozzák meg. Ha az ügyfél már attól is boldog, ha az eddigi 20 másodperces futásideje 5 másodperc lesz, akkor ezt fogja beleírni a követelményei közé. Mert elképzelni sem tudja (hidd el, sokszor a programozók se látják előre a jövőt
), hogy amit szeretne az 40ms alatt is megoldható.A hardvert pedig azért kell fejleszteni, mert képzeld el a következő szitut (direkt kicsit kisarkítva):
Jón egy ügyfél, hogy kellene neki egy program, amit jelenleg 20 párhuzamos user használ, legyen gyors meg minden. Elkezd a csapat kódolni, menet közben jönnek változtatási igények, előjönnek csúszások, néhol kompromisszumos megoldásokkal kell élni stb...
Végül elkészül a kód, mindenki kipróbálja, zokszó nélkül viszi a 20 párhuzamos usert, szép, gyors, határidőre kész lett, mindenki happy.Igen, ám, de mi van akkor, ha visszajön az ügyfél, hogy nyitott még 4 másik telephelyet, ebből kettő már külföldön van, és hát a rendszer lassulgat igaz, hogy már 100 párhuzamos user van rajta. És ekkor az ügyfél választhat, beletol plusz X processzormagot Y összegért a rendszerbe, vagy elkezdi újra íratni a programját, ekkor már 100 párhuzamos userre méretezve mondjuk 5Y összegért (és ez az újraírás el fog tartani mondjuk 2 évig, miközben Y összegért azért a plusz hw erőforrást is bele kell tolnia, mert a rendszernek addig is mennie kell). Szerinted melyik opciót választja az ügyfél? Elárulom: roppant ritka az az ügyfél, aki a másodikat választja, ő is inkább csak azért, mert hardveresen már közelít a falhoz, ahonnan már nincs tovább.
És ekkor te, mint ügyfél, ott állsz az 300-adik párhuzamos user ügyfelessel szemben, és nem érted, hogy miért lett olyan szarul megírva a program, hogy várnia kell az ügyintézőnek, mire valamire reagál a rendszer. És hogy lehetnek ezek a magukat programozóknak mondó kóklerek ennyire faszok, hogy egy ilyen szart tettek le az asztalra. -
martonx
veterán
válasz
pmonitor
#15613
üzenetére
"És szerintetek a webalkalmazás miben íródott/íródik? Ha jól tudom C++-ban." - nem állítom, hogy pl. a C# egyik komponensének sincs köze a C/C++-hoz, de a C# konkrétan úgy működik, hogy megírod a kódodat C# nyelven, amiből a compiler (na, ez a compiler éppen simán lehet, hogy C/C++, de lehet, hogy Rust vagy tudja isten, lusta vagyok github-on kikeresni a Roslyn forráskódját) készít egy köztes nyelven lévő általános kódot (Intermediate Language), és futásidőben (pontosabban első futáskor) ebből készít a JIT egy arra a hw architektúrára optimalizált assembly kódot.
Bővebben: [link]
A C# nagyon sokáig windows only nyelv volt, de ez 2017 óta már nem így van. Így 2021-ben ideje lenne elfelejteni ezeket a rég berögzült paradigmákat (rakás C# rendszerünk fut Linuxon jelenleg is). Java, Javascript, PHP, Go, Python, stb. nyelvek meg soha nem is voltak windows only-k.
A konkrét példám éppen C#-os volt, ezzel nem egy C# vs. más nyelv flame-et akartam kelteni, hanem az mellett érvelni, hogy mennyi aspektusa van annak, hogy egy nyelvre azt mondjuk, hogy jó vagy csak játékszer, és ezek között a nyelv sebessége csak egy (sokszor tök lényegtelen) szempont a kismillió közül.
De látom, te most éppen a C/C++-ba beleszeretőbe vagy, amivel semmi baj nincs, én meggyőzni se akarlak semmiről. A C/C++ is teljesen jó nyelv bizonyos programozási feladatokra. Sőt minden nyelvben meg lehet oldani minden problémát, más kérdés, hogy egyes problémákat egyes nyelvekkel jóval egyszerűbben, gyorsabban meg lehet oldani, más nyelvekkel meg csak nyögvenyelősen.Ahonnan ez az egész thread elindult, hogy a C-ben lévő kódod vs. a C# kódod között futásidőben mértél némi eltérést (50% semmiképp sem drasztikus, majd ha a C-s kódod tizedannyi idő alatt lefut, akkor arra én is azt mondom, hogy na az már sebességkülönbség - és ezzel meg is válaszoltam egy korábbi kérdésed). És ezen eltérés alapján nagy hévvel kijelentetted, hogy a C# (de ide bármelyik nyelvet érthetnénk a kontextusod alapján) csak egy játékszer a C-hez képest. Miközben ez nem igaz, sőt butaság.
-
Livius
őstag
válasz
pmonitor
#15613
üzenetére
Ezért mondom hogy menj el dolgozni, mert látszik hogy nem látod mi a helyzet a jelenlegi technológiákban! C-ben az programozgat aki Linux-ban HW közeli dolgokat csinál, aki ott userspace dolgokat csinál az is már jobban jár a C++-val Linuxon. Vagy C-ben az programozgat, aki mikrokontrollereket használ. Ha nagyon fontos a sebesség desktop gépen, akkor C++ kell, vagy pl Windows 10 driver C++-ban ajánlott, ha még GUI is kell akkor vagy lehet maradni a C++-nál, vagy tovább kell lépni C#-ra (ma már mindenhez kell GUI, konzol alkalmazás nem eladható). A scriptnyelvek pedig gyors kipróbálásokra jók, vagy épp valami webes háttér feladatokra, amik ilyen mappákból másolgatunk ezt azt ide-oda, meg szöveges dolgokban keresünk pl. Ez a mostani trend, fogadd el. Ha a C a mindened, akkor kezdj el nézelődni a Linux kernel programozás terén, vagy mikrokontroller programozás terén, ott tényleg számít minden ms, ez való neked.
És egy C csapat igen is lassú, amint követelménybe kapja hogy legyen GUI, webes interface meg ilyesmi, már +1 év fejlesztés.
Előre megírt dolgok meg nehogy azt hidd hogy nagyon vannak, max a régi dolgokat copy-pastje van általában, de ez is kis mértékben.
-
Silεncε
őstag
válasz
pmonitor
#15613
üzenetére
És szerintetek a webalkalmazás miben íródott/íródik? Ha jól tudom C++-ban
Én itt érteni vélem, mire gondolsz, de akkor ennyi erővel mondhatjuk, hogy minden alkalmazás, ami oprendszer felett fut, C program és készen vagyunk.
(pl. a C# mehet a levesbe linux esetén) Bár ha jól tudom, arra is van C#, de az aztán korántsem olyan elterjedt.
A .Net Core (illetve mostmár csak simán .Net) igen elterjedt cucc, sokan használják productionben is
-
martonx
veterán
válasz
pmonitor
#15603
üzenetére
Nem off topik ez. Csak egyszerűen nem kell butaságokat írni. Annak, hogy egy programnyelv jó-e vagy rossz, egy csomó szempontja lehet, nem csak a futásidőben nyújtott teljesítmény. Hiszen, ha így lenne, akkor nem lenne feljövőben a Python, a PHP már vagy egy évtizede ki kellett volna, hogy haljon, a javascriptről nem is beszélve
Ugyanakkor nyilván azt se lehet kijelenteni, hogy nem számít a futásidejű teljesítmény, mert igenis van sok olyan eset, amikor meg erre kell kihegyezni valamit. De ekkor is több mindent figyelembe kell venni. Pl. van-e értelme natív nyelvben újraírni valamit, csak azért, hogy pár százalék gyorsulást hozzon a konyhára? Vagy inkább egyszerűbb egy szerver alá betolni plusz két processzormagot, és a fejlesztők meg a hónapokig / évekig tartó újraírás (nem is beszélve egy új nyelv megtanulásáról) helyett inkább olyan új feature-ökön dolgozhatnának, amikkel megtöbbszörözik a cég bevételeit?
Vagy említetted, hogy pl. elég csak a teljesítmény kritikus részeket megírni natív kódban, és azokat dll-ként behivatkozni. Ekkor vajon mennyire fog jól működni a közös logolás, monitoring? Mennyire lesz fájdalmas CI/CD rendszert több repository-ból kiindulva felépíteni, és egy sikeres build/deploy/testing fázist végig verni az X féle nyelven készült komponensken? Mekkora szopás van ebben az esetben, ha akár csak egy szerver frissítéskor eltörik valamelyik ilyen "külső" komponens? Netán linuxról windowsra váltanak vagy vissza? Vagy csak 32-ről 64 bitre? És máris cseszhetik a dll komponensüket. Ráadásul mi van, ha az a kolléga már nincs is a cégnél, aki ezt anno készítette?
És még hosszasan lehetne sorolni a kismillió szempontot, amiket fejlesztéskor számításba kell venni. Ahelyett, hogy csak az lebegne a fejlesztők szeme előtt, hogy hú, használjuk pont azt a nyelvet, amivel most éppen 50% teljesítmény növekedést lehetne elérni.Én is dolgoztam olyan projekten, ahol a futásidő kritikus volt. Nálunk C# projektnél az volt a mondás, hogy 5 másodperc alatt kell kiszolgálni egy HTTP requestet (kellemesen bonyolult háttér logikákat futtatva több millió adatsoron), mert az előző PHP-s csapat ezt se tudta felülről még csak megközelíteni se. Nálunk ez végül 40-80ms között szórt. Vajon elégedettebb lett volna-e a megrendelőnk, ha mindezt C-ben oldja meg egy másik csapat mondjuk négyszer ennyi fejlesztési időből, és a végén 30-60ms a requestek válaszideje? Miközben ő csak annyit akart, hogy 5 másodpercen belül menjenek a válaszok.
Szóval a világ korántsem olyan fekete-fehér, mint ahogy te látod.
-
kovisoft
őstag
válasz
pmonitor
#15603
üzenetére
Nem gondolnám off topicnak a témát, bármit meg lehet értelmesen vitatni, de ha valaki úgy kezdi, hogy ez meg az milyen sz@r, ezek meg azok milyen hülyék, stb, akkor azzal óhatatlanul belegázol valaki másnak a lelkébe, aztán nem győznek takarítani a modik.
Az adott feladat és a rendelkezésre álló erőforrások döntik el, hogy elfogadható-e ez a futásidő vagy nem. Sokszor elfogadható, máskor meg nem. Ha nem elfogadható, akkor valahogy gyorsítani kell a programot, és ennek többféle módja is lehetséges, nem csak a váltás egy másik programnyelvre, pláne ha több millió soros kódbázisról van szó. Első körben nyilván az ember az adott programnyelven az adott programrészt próbálja optimalizálni (pl. gyorsabb algoritmusok használata, heurisztikák beépítése, caching, párhuzamosítás, stb). Bizonyos esetekben lehet hardvert bővíteni vagy nagyobb teljesítményűre cserélni. Nyilván szóba jöhet a kódnak vagy egy részének egy másik programnyelvre való átültetése is, de mit csináljon pl. az, aki már eleve C-ben (vagy akár Assemblyben) oldotta meg a feladatot, és még így is lassú?
Aztán meg olyan is van, hogy ugyan tudnánk gyorsítani a kódon, de ez túl nagy munka lenne és sokba kerülne a cégnek vagy a megrendelőnek, és így máris elfogadhatóvá válik a hosszabb futásidő.
-
sztanozs
veterán
válasz
pmonitor
#15594
üzenetére
Igazából senkit sem érdekel, hogy minél gyorsabban fusson valami, az érdekes, hogy az elvárt időn belül lefusson. Ha az elvárt idő 7 mp és lefut 2 mp alatt, akkor nem fogják árírni c-be vagy assy-ba, hogy 0.05 mp alatt lefusson.
Ja és sokkal valószinűbb, hogy ha 10 mp alatt futna le, akkor se keresnek másik programozási nyelvet, hanem csak egy gyorsabb implementációt ugyanarra a problémára (ha van ilyen). -
Livius
őstag
válasz
pmonitor
#15594
üzenetére
Jelenleg az igazi programozók ilyeneket használnak kb (nálunk legalábbis ez ami kell multicégnél): C#, C++, python, Matlab (C-ét pedig defaultból mindenki tudja, de nem ez a fő nyelv, ami kell)
C#-ban igen, tudsz használni C-és dll-t, de javaslom ezen a koncepciódon még alakíthatnál. Azzal, hogy Te magadnak írsz egy C dll-elt és 200 ms-vel lettél gyorsabb a C# eredeti MS-es megoldásához képest azt még igencsak a hajadra kenheted.
Ha még ezen a vonalon akarsz csiszolni, hogy a matematikai eljárások a lehető leggyorsabbak legyenek, úgy hogy adott esetben a C#-ból egy külsös nem .Net-es dll-ből egy sokkal gyorsabb implementációt használsz, akkor ajánlom figyelmedbe a BLAS és LAPACK szintű átportolását az Intel-nek, Intel oneAPI Math Kernel Library.
Előfordulhat hogy ez csak az Inteles gépeken fog működni, kb csak a Core 2 Duo és annál újabb CPU-kon, de jelenleg ennél optimálisabb numerikus lib nincs C/C++-ban szerintem (párhuzamosított vektor/mátrix művelteket alapból tudja), amit egy C# alatt tetszőlegesen használhatnál is. -
kovisoft
őstag
válasz
pmonitor
#15586
üzenetére
Említetted az ismétléses permutációt, az előző kódomat egy kis módosítással alkalmassá tehetjük ezeknek az előállítására is. Csupán ki kell cserélni a < és > jeleket <= ill. >=-re, hogy a megegyező elemeket is átugorják a ciklusok. Valamint a tömb inicializálásakor fel kell sorolni ismétlésekkel együtt növekvő sorrendben az elemeket (ha mindegyik elem különböző, akkor visszakapjuk az ismétlés nélküli permutációt). Valahogy így:
int a[] = {1,1,2,2,2,3};
int n=6;
...
// megkeressuk, hol kezdodik az utolso monoton csokkeno reszsorozat
for (i=n-2; i>=0 && a[i]>=a[i+1]; i--);
...
// a csokkeno reszsorozat elotti elemet ki kell cserelnunk a reszsorozatban nagysag szerint rakovetkezovel
for (j=n-1; a[j]<=a[i]; j--);
...Ennek a sebességét sem teszteltem, nem tudom, hogyan viszonyul más módszerekhez.
-
Ispy
nagyúr
válasz
pmonitor
#15594
üzenetére
Szerintem az egész melyik az igazi meg nem felvetésed egy baromság, mindegyiknek van előnye meg hátránya, a megfelelő feladathoz a megfelelő nyelvet kell választani. Persze más ha az ember csak programozgat, meg más amikor a munkájától függ sok-sok másik cég, ember munkája. Meg persze pénzt is kéne vele keresni, ami kb. azt jelenti, hogy a lehető leggyorsabban tud a legjobb minőséget előállítani, az hogy a user a gép előtt 2 mp-et vár valamire vagy 10-et az nem igazán szempont.
-
martonx
veterán
válasz
pmonitor
#15587
üzenetére
Hm, most jól értem, hogy ez a C# játékszer, és a C mennyire hasít, ezen bődületes nagy eltérések alapján lett kijelentve?
C# C
n=13 23s 14s
n=15 330s 200sAkkor mondanám, hogy a C#-hoz képest a C hasít, és rohanjunk minél több, mindent C-be átrakni, ha tizedannyi idők alatt végezne.
Egyébként az is kérdéses, hogy a C#-ot mennyire mesterien optimalizáltad, minden struct és span<T>-e benne, meg ilyesmik.
A fentiekkel nem azt akarom bizonygatni, hogy a managed kód nem lassabb, mint egy natív kód, mert az butaság lenne, csak arra akartam rávilágítani, hogy a talán helyes eredményeidből, levont következtetésed helytelen: "C# játékszer a C-hez képest". -
Livius
őstag
válasz
pmonitor
#15587
üzenetére
Javaslom kezdj el dolgozni valami szoftveres multicégénél, és akkor egyből rájössz, hogy ha tegnapra kell valamit megcsinálni, akkor manapság az már nem fér bele, hogy C-ben Win32 API-val mindent a legalacsonyabb szinten csináljunk meg 4 év fejlesztés alatt, amikor ugyan az sokkal átláthatóbb kódolással, 3 hónap alatt kész van C# WPF-ben egy Windows 10 cél platformra fejlesztve. És itt most egy korszerű sok-sok magot kihasználó multiprocessinges progira gondolj GUI-val és mindennel, ne a command line szintű használhatatlan user-interfaces DOS korszakos programra.
-
axioma
veterán
válasz
pmonitor
#15582
üzenetére
En egy dolgot megneztem benne: mar amikor nekem tanitottak a "tiszta" rendezesi algoritmusokat, akkor mondtak hogy a valosagban nem ilyet hasznalnak (letezo library-k), hanem egy kevert algot: ha a hossz ma'r <=5, akkor a rekurziv hivas koltsege tobb, mint az nlogn es n^2 kozotti kulonbseg, ezert azokat a darabokat egy sima buborekkal/kivalasztasossal vagy barmi ilyesmivel lerendezik, es csak felette jon a felezes. Ha szeretsz ilyenekkel jatszani, probald ki. Azota lehet hogy van tobb mas trukk is.
Amugy a mar leglevo algoritmusoknal celhoz kototten tudsz jobb algoritmust irni (felteve ha nem annyira altalanos hogy van ra lib ), vagyis ha barmi tobbet tudsz az adataidrol. Peldaul ha csupa 1000 es 10000 kozotti szamok 10ezres nagysagrendben (adatbazisban amcsi iranyitoszamok volt a pelda, az me'g egy kb. 80-as evekben irt konyvben), akkor jobban jarsz ha egy masik tombben megszamolod melyikbol mennyi van/bevodrozod hogy hol (indexek), es utana vegigfutsz rajta vissza-flatten-elni, igy van linearis megoldas. -
kovisoft
őstag
válasz
pmonitor
#15582
üzenetére
Még régebben írtam egy rövid függvényt, ami kiírja a N szám permutációit rendezett formában. Most sehol sem találom, de emlékeim alapján megpróbáltam újra lekódolni C-ben:
int a[50];
int n=5;
int i, j, temp;
// az 1 2 3 ... n sorozatbol indulunk ki
for (i=0; i<n; i++)
a[i] = i+1;
for (;;)
{
// kiirjuk az aktualis permutaciot
for (i=0; i<n; i++)
printf("%d ", a[i]);
printf("\n");
// megkeressuk, hol kezdodik az utolso monoton csokkeno reszsorozat
for (i=n-2; i>=0 && a[i]>a[i+1]; i--);
// ha a teljes sorozat monoton csokkeno, akkor vegeztunk
if (i < 0)
break;
// a csokkeno reszsorozat elotti elemet ki kell cserelnunk a reszsorozatban nagysag szerint rakovetkezovel
for (j=n-1; a[j]<a[i]; j--);
temp=a[i]; a[i]=a[j]; a[j]=temp;
// tovabbra is monoton csokkeno a reszsorozatunk, forditsuk meg, hogy monoton novekedo legyen
for (j=i+1; j<n+i-j; j++)
{
temp=a[j]; a[j]=a[n+i-j]; a[n+i-j]=temp;
}
}Nem teszteltem a sebességét, nem állítom, hogy ez a létező leggyorsabb módszer, de viszonylag rövid és egyszerű. Egyébként most, hogy jobban megnézem, ez majdnem az a módszer, mint amiben a quicksort van. Az igazat megvallva soha nem értettem, hogy miért kell itt meghívni egy quicksortot, hiszen amikor ide érünk, akkor a sorozat vége már rendezve van, csak éppen csökkenő sorrendben, tehát elég szimplán megfordítani.
-
-
pmonitor
aktív tag
válasz
pmonitor
#15512
üzenetére
"Error A2026 constant expected include\winextra.inc 11052"
Ezt a hibát írta ki a 11052 és a 11053 sorra a winextra.inc file-ban.
STD_ALERT struct
alrt_timestamp dd ?
alrt_eventname WCHAR [EVLEN + 1] dup (?)
alrt_servicename WCHAR [SNLEN + 1] dup (?)
STD_ALERT endsha kommentbe teszem a következő 2 sort:
alrt_eventname WCHAR [EVLEN + 1] dup (?)
alrt_servicename WCHAR [SNLEN + 1] dup (?)
akkor működik. Csak azt nem tudom, hogy ezt miért nem fogadja el. De az a lényeg, hogy működőképes lett a program. Már ez is műxik.; We access the MangaEden API and request a list of the first 25 available manga. I used a buffer size of 5000, but feel free to modify it.
; I basically learned ASM today, just felt like posting this somewhere.
.386
.model flat, stdcall
option casemap:none
; Includes
include include\windows.inc
include include\kernel32.inc
includelib lib\kernel32.lib
include include\user32.inc
includelib lib\user32.lib
include include\wininet.inc
includelib lib\wininet.lib
WinMain proto :DWORD,:DWORD,:DWORD,:DWORD
; Initialized data
.data
AppName db "GUI App with Buttons",0
ClassName db "Class of GUI",0
ButtonClass db "button",0
ButtonText db "Kattints rám!",0
strTitle db "Cím",0
strMessage db "Hello world!",0
fhwnd dd 0
hwndButton dd 0
.data?
hInstance HINSTANCE ?
CommandLine LPSTR ?
.const
ButtonID equ 1
.code
start:
invoke GetModuleHandle,0
mov hInstance, eax
invoke GetCommandLine
mov CommandLine, eax
invoke WinMain, hInstance,0, CommandLine, SW_SHOWDEFAULT
;invoke MessageBox, 0, ADDR strMessage, ADDR strTitle, MB_OK
invoke ExitProcess, 0
;end start
WinMain proc hInst:HINSTANCE, hPrevInst:HINSTANCE, CmdLine:LPWSTR, CmdShow:DWORD
local wc:WNDCLASSEX
;local fhwnd:HWND
local msg:MSG
mov wc.cbSize, SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW
mov wc.lpfnWndProc, offset WndProc
mov wc.hbrBackground, COLOR_BTNFACE+1
push hInst
pop wc.hInstance
mov wc.lpszMenuName,0
mov wc.lpszClassName, offset ClassName
invoke LoadIcon, 0, IDI_APPLICATION
mov wc.hIcon, eax
mov wc.hIconSm, eax
invoke LoadCursor, 0, IDC_ARROW
mov wc.hCursor, eax
invoke RegisterClassEx, addr wc
invoke CreateWindowEx, 0, \
addr ClassName, \
addr AppName, \
WS_OVERLAPPEDWINDOW, \
CW_USEDEFAULT, \
CW_USEDEFAULT, \
500, \
500, \
0, \
0, \
hInst, \
0
mov fhwnd, eax
invoke ShowWindow, fhwnd, CmdShow
invoke UpdateWindow, fhwnd
.While 1
invoke GetMessage, addr msg, 0, 0, 0
.BREAK .IF (!eax)
invoke TranslateMessage, addr msg
invoke DispatchMessage, addr msg
.ENDW
mov eax, msg.wParam
RET
WinMain endp
WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
.if uMsg==WM_DESTROY
invoke PostQuitMessage, 0
.elseif uMsg==WM_CREATE
invoke CreateWindowEx, 0, addr ButtonClass, addr ButtonText, \
WS_CHILD or WS_VISIBLE or BS_DEFPUSHBUTTON, \
170, 100, 140, 25, hWnd, ButtonID, hInstance, 0
mov hwndButton, eax
.elseif uMsg==WM_COMMAND
mov eax, wParam
shr eax, 16
.if eax==BN_CLICKED
mov eax, lParam
.if eax==hwndButton
invoke MessageBox, 0, ADDR strMessage, ADDR strTitle, MB_OK
.endif
.endif
.else
invoke DefWindowProc, hWnd, uMsg, wParam, lParam
ret
.endif
xor eax, eax
RET
WndProc endp
end start -
-
dqdb
nagyúr
válasz
pmonitor
#15488
üzenetére
Ez teljesen a futtatott alkalmazástól függ.
A legtöbb MDI és MSDI alkalmazás például úgy működik, hogy egy fő folyamat van csak, és nem ablakonként külön egy-egy. Így amikor például egy újabb Wordöt indítasz úgy, hogy az még nem futott, akkor elindul egy új folyamat. Azonban amikor ismét elindítanád úgy, hogy már fut, akkor az az új folyamat szól a már létezőnek, hogy meg kellene nyitni egy újabb dokumentumot, majd kilép.
A másik végletet a Chromium alapú böngészők képviselik, ahol egyetlen futó alkalmazáshoz X+Y folyamat tartozik, ahol X egy fix érték (jellemzően 3-4, mint UI kiszolgálása, hálózati forgalom intézése, bővítmények kiszolgálása) és Y pedig a megnyitott fülek számával és telepített bővítmények számával arányos.
-
#15487
Fire/SOUL/CD
félisten
pmonitor
#15485
válasz
pmonitor
#15485
üzenetére
Windows 10 alatt vannak az ún. Desktop mode app-ok, meg a Tablet mode app-ok. A számológép az utóbb csoporthoz tartozik, ezért nem tudod beolvasni a PID-t a korábbi módszerrel. Legegyszerűbb megoldás az, ha futtatod a calc-ot (ami egy Calculator.exe process-ként jelenik meg a Feladatkezelőben), majd végigszaladsz az összes futó folyamaton és megkeresed ezt a bizonyos Calculator.exe-t. Abból már ki lehet olvasni a PID-t (meg sok mást is)
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <tlhelp32.h>
#include <stdbool.h>
int main()
{
STARTUPINFO SI;
PROCESS_INFORMATION PI;
ZeroMemory(&SI, sizeof(SI));
SI.cb = sizeof(SI);
ZeroMemory(&PI, sizeof(PI));
if(!CreateProcess(NULL, "calc.exe", NULL, NULL, FALSE, 0, NULL, NULL, &SI, &PI))
{
printf( "CreateProcess failed... Program terminated.");
return -1;
}
WaitForSingleObject(PI.hProcess, INFINITE);
wchar_t * ProcessName = "Calculator.exe";
bool FoundProcess = false;
PROCESSENTRY32 PE32;
PE32.dwSize = sizeof(PE32);
HANDLE PS = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, NULL);
if (PS != INVALID_HANDLE_VALUE)
{
Process32First(PS, &PE32);
while (Process32Next(PS, &PE32))
{
if (strstr(PE32.szExeFile, ProcessName)!=NULL)
{
FoundProcess=true;
break;
}
}
if (FoundProcess)
{
printf( "Process Name = %s\nProcessID = %d", ProcessName, PE32.th32ProcessID);
CloseHandle(PS);
}
else
printf( "%s process not found.", ProcessName);
}
CloseHandle(PI.hProcess);
CloseHandle(PI.hThread);
getch();
} -
-
pmonitor
aktív tag
válasz
pmonitor
#15478
üzenetére
A C# kód, ami invalid értéket ad vissza Az itt található példakód alapján csináltam.
using System;
using System.Diagnostics;
using System.Windows.Forms;
namespace TestProcess
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
void OpenWithStartInfo()
{
ProcessStartInfo startInfo = new ProcessStartInfo(textBox1.Text);
startInfo.WindowStyle = ProcessWindowStyle.Minimized;
Process.Start(startInfo);
Process pr = Process.Start(startInfo);
textBox2.Text = pr.Id.ToString();
}
private void button1_Click(object sender, EventArgs e)
{
OpenWithStartInfo();
}
}
}@kavalkád: nem Neked szólt. A post-odat még nem láttam, amikor írtam. De kipróbáltam az első paraméterbe NULL-al, a másodikban a file-névvel. Úgy sem működik rendesen. Viszont ha Delphiben működik, akkor lehet, hogy tényleg én szúrok el valamit. Csak nem tudom, hogy mit.
-
pmonitor
aktív tag
válasz
pmonitor
#15378
üzenetére
Készítettem Made in Hirtelen egy teszt alkalmazást. FindFirstFile-FindeNextFile felhasználásával. Tesztelhetitek ti is. Nálam ez sokkal gyorsabb a TC-nél(pedig ez C#-ban van, a TC meg gondolom C++-ban lehet). Tehát a TC a kiírással nagyon sok időt pazarol el. Az ad-hook programomban még sok puffer van azáltal, hogy nem írja ki, hogy hol keres éppen.
De érdekes módon, ha a 2 program egyszerre fut, akkor majdnem egyszerre végeznek. Ezt nem értem, hogy miért van? Ha valaki tudja erre a választ, ő megírhatná, hogy mi lehet a magyarázat erre. A program letölthető innen. FindFirstFile.rar.
-
kovisoft
őstag
válasz
pmonitor
#15375
üzenetére
Én örülök neki, hogy kiírja, rengetegszer vettem már hasznát. Általában lehet látni, hogy melyik könyvtárban időzik. Van, hogy az ember rájön, hogy ott nem is akart keresni, és lelövi a keresést. De arra is jó, hogy lássuk, hol jár a keresés, kb. mire számítsunk, meddig fog még tartani. Nem hiszem, hogy érdemben lassítana, nem ír ki minden egyes fájlnevet. Számomra sokkal gyűlöletesebb user interface a szimpla kerregő homokóra és társai, amikor semmi visszajelzésem nincs arról, hogy mit csinál a gép, és az várhatóan meddig fog még tartani.
-
-
axioma
veterán
válasz
pmonitor
#15364
üzenetére
Hat a tc-ben a mappak porgese megmutatja, hogy ha valahol sokat tolt. Valoban, a fel mp alattiak helyett irhatna hogy bejaras, es csak hosszabb idonel hogy kereses az x mappaban vagy ilyesmi.
El vagytok a'm ti mar kenyeztetve, adj ki egy unix find parancsot aztan vagy kapsz vissza valamit ami olvashato uzenet vagy majd kiszamithatatlan ido utan a prompt visszaterese jelzi hogy nincs hiba es nincs talalat sem -
-
Livius
őstag
válasz
pmonitor
#15319
üzenetére
Az a baj hogy te matematikai formulák optimalizációját várod el a gcc-től már magába a C/C++ nyelvben (még csak szimbolikus matematikai szinten), de szerintem a gcc-nek nem ez a feladata, és nem erre találták ki az optimalizációját. Ha ebbe durván bele nyúlna, egy ilyen optimalizációs szint, akkor soha az életben nem lenne biztonságos ahhoz, hogy egy önvezető autó vagy repülőgép szabályzórendszerében használható legyen, de még lehet sokkal kisebb kockázati szinten is csak a bugokat termelné, ezért ilyen irányba gondolom sose fejlesztették ezt.
De ha neked ez nem tetszik, akkor tényleg itt a lehetőség, írd át a gcc forrását hogy ezt tudja, és adj be rá egy pull-requeste-et. https://github.com/gcc-mirror/gcc
Amúgy nem hiszem hogy ez túl easy dolog is lenne. Gyakorlatilag a wolfram alpha szimbolikus egyenlet rendezős és optimalizációs képességével kéne kezdeni ezt az egészet egy C nyelvre alkalmazva. Azért ez nem kicsit overkill és a franc se tudja mi lenne az eredménye ha ez menne automatizáltan egyszer valaha.
-
Livius
őstag
válasz
pmonitor
#15314
üzenetére
Most nem azért, de olyan optimalizálást vársz el, hogy a gcc legyen olyan intelligens, és akár a matematikai eljárásodat is bírálja felül, ami hülyeség. Ez így nem működhet, annak kell ott fordulni amit Te oda leírsz (te vagy a szellemi szerző, nem a gcc), az ilyen szintű dolgokon az alkotónak kell gondolkodni, hogy optimális legyen. Biztos lehetne olyan fordítóprogramokat csinálni, amik ezt a szintet is tudnák, csak onnantól kezdve azok ilyen optimalizációs beállítással, az iparban kb tiltottak lennének rövid időn belül, az akár előre beláthatatlan programbugoktól.
-
Livius
őstag
válasz
pmonitor
#15311
üzenetére
De a gcc-nek nem az a feladata hogy a te C nyelvedet alakítsa alternatív jobbra, az a te dolgod. Így kb azt várod el tőle, hogy már a C nyelvben lásson és keressen optimálisabb megoldást a user hülyeségére, de szerintem a fordító nem ott fogja ezt keresni leginkább, tehát a szerző C-ben írt részébe minimálisan hajlandó csak belenyúlni a problémák elkerülése végett. Az igazán optimális fordítás nem hülye biztos, az alkotónak a C/C++-ban is tudni kell hogy miből lehet optimálisat fordítani.
-
Livius
őstag
válasz
pmonitor
#15304
üzenetére
Észre veszi, csak be kell kapcsolni az optimalizációs kapcsolót is. Ha nincs bekapcsolva vagyis -O0 van a gcc-ben akkor nem csinál rajta semmi okosítást, mivel a szerző azt mondta az -O0-val, hogy ne is csináljon rajta optimalizálást.
első: https://godbolt.org/z/Ydox7q
második: https://godbolt.org/z/3EjYGEMinimum -O1-et, de ha -Ofast-ot írsz akkor még egy kicsit módosít rajta, de mind a két esetben a két kódra ugyan az az asm kód lesz az optimalizálás eredménye, szóval tud már mindent amit kell. Sose becsüld le a gcc erejét, Luke!
-
kovisoft
őstag
-
Livius
őstag
válasz
pmonitor
#15209
üzenetére
Szia!
Szerintem ezt a bferi.hu oldalon történő publikálást felejtsd el és térj át gyorsan GitHub-ra (még verzió kezelt is lesz a kódod) és így ott az angol nyelvű leírást is át kéne venni. Az ilyen privát weboldalakról a random open source közösség soha semmit nem fog megtalálni, főleg ha még magyar is a leírása. Jah és ha a problémának van hivatalos angol kifejezése a matematikai világban vagy numerikus analízisben azt a GitHub-on feltüntetve mindent visz az ilyen, mindenki rá fog találni, és beindulhat az igazán nagy szakmai elmélkedés ott a GitHub-on erről, akár mások javasolt átkódolásaival és ötleteivel a kódban.
Vannak már mások is akik ezzel foglalkoznak ott.
https://github.com/search?q=Cutting+stock+problem
Jah, amúgy validálásnak, hogy mennyire jó amit tud ajánlom a Matlab hivatalos megoldóját erre. A matlabnál azért általában a "state of the art" van implementálva matematikailag, tehát hobbi home office-ban nem igen lehet annál jobban működőt összerakni.
Matlab: Cutting Stock Problem: Solver-Based
), hogy amit szeretne az 40ms alatt is megoldható.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- Simrig eladó PS5/PC kompatibilis. (olvass leírást.)
- Ryzen7 2700X/ RTX2060/ 32GB DDR4/ 512GB m.2 alapú konfig/ garancia / ingyen foxpost
- Eladó Fanatec szimulátor szett - Komplett, kiváló állapotban, azonnal használható!
- Beszámítás! Sony PlayStation 4 PRO 1TB fekete játékkonzol extra játékokkal garanciával hibátlan
- Beszámítás! Sony PlayStation 5 825GB SSD lemezeskonzol extra játékokkal garanciával hibátlan működés
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- Azonnali kézbesítés az év bármely pillanatában
- BESZÁMÍTÁS! 6TB Seagate SkyHawk SATA HDD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! 1TB Kingston KC3000 NVMe SSD meghajtó garanciával hibátlan működéssel
- Telefon felvásárlás!! Samsung Galaxy S24/Samsung Galaxy S24+/Samsung Galaxy S24 Ultra
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest