NetAcademia

A legjobbakat tanítjuk!

Mondom is, miért C#

2018. május 19. 18:11 - Plesz Gábor

Tehát, szóval. Miért is érdemes C#-ban programozni?

Csak nagyon röviden: mert szinte minden területen, kis belépési kültséggel, azonnal működő prototípust tudunk építeni, és a határ majdnem a csillagos ég. Ráadásul a tudáshoz való hozzáférés gyakorlatilag korlátlan.

Persze, hogy mindjárt mondok példákat is, de előbb megismétlem az eddigieket kicsit hosszabban:

Tegyük fel, hogy programozni szeretnél, és azt a nyelvet keresed, amin

a.) Windows-ra,
b.) Linuxra,
c.) iOS-re,
d.) Androidra,
e.) OSX-re

1. ) szerver
2. ) desktop
3. ) kliens
4. ) mobil
5. ) 2D/3D játék

alkalmazásokat írhatsz akár évtizedekig egy irányba haladva, nagy törések nélkül. Majd miután beletanultál dolgozni is szeretnél vele.

Akkor az a helyzet, hogy egyről beszélünk, hát ezért CSharp.

A nyelvet 2000-ben mutatták be, eleve úgy indult, hogy a Java-hoz hasonlóan mindenhol fog majd futni, de az MS Windows környzeten kívül nagyon lassan haladt a fejlődése, mivel a Microsoft a Windows-ra koncentrálta erőit. Óriási áttörés történt viszont ebben az elmúlt években, a Xamarin megvásárlásával és a házon belüli ASP.NET "lázadással" a nyílt forráskód irányába. Immár a felsorolt esetekben teljes értékű, első osztályú polgára a fejlesztési világnak.

Tényleg, mielőtt belevágunk: mi van a teljesítménnyel?

Tudod, Microsoft..., meg a Windows... Hát, hogy is mondjam.

Ebből a legújabb TechEmpower Framework Benchmarkból egyértelműen kiderül, az ASP.NET Core környezet, amivel a szerveroldalon dolgozunk, másodpercenként majdnem 7 millió kérést szolgált ki a plain text versenyben, a verseny szabvány futtatókörnyezetében. Erre mondják, hogy a teljesítménymérések alfájában.

Ezzel a leggyorsabb versenyző 98.1%-os teljesítményét hozta. Vegyük észre, hogy előtte az eredménylistán hiába keressük a nagy frameworköket. Tényleg, aki a listán hallott ebben a kategóriában az ASP.NET Core előtt végző versenyzőkről, és látott már valamelyik használatával rendes fejlesztést, NetAcademia bögrét kap.

A teljesítmény tehát köszöni szépen, alakul, alakulgat.

Akkor nézzük ezt a sok környezetet, mondjuk manapság egy kikerülhetetlen dolog az IoT, és ennek egyik kiváló csillaga, a Raspberry PI. Jó. Akkor mondjuk ezzel mi van?

Az van, hogy az elmúlt napokban kétszer is belefutottam, egyszer Hanselmann írt egy szívhezszóló cikket arról, hogy is lehet Docker segítségével Raspberry PI (ARM) architektúrán C# huszárkodni.

Aztán pedig jelezte, hogy most lesz nemsokára (azóta már volt) a Twitch-en egy 9 órás igyenes demonstráció/kódolási maraton/bemutató workshop, ahol egyebek mellett Docker segítségével C# nyelven Raspberry PI-t is programoznak.

Na, ugye.

De miért mondtam mindezt itt el?

Mert az a helyzet, hogy mi itt Magyarországon olyan nagyon nem vagyunk lemaradva.

Mivel ezek előtt, 2018. április 23-án 15:00-18:00 között az előző NetAcademia meetup-on ki nem találnád,
de C# nyelven Docker segítségével a Raspberry PI ledjét villogtattuk. Az eseményről készített videók ingyenesen elérhetőek mindenkinek, regisztráció után.

A jegyzőkönyv kedvéért:

  • A következő alkalom 2018. június 04-én lesz, amikoris a saját gépünkön futó csevegőrobotból fogjuk ezt a kódot használni.
  • Aztán pedig 2018. június 25-én kitesszük az egészet az Internetre, és akár Facebook Messengerből vagy Skype-ból is élvezhetjük munkánk gyümölcsét.

Azt pedig már el sem mondom, hogy a hónap elején elindult a NetAcademia Certified Junior C# fejlesztő útvonal, ha valaki hivatásszerűen szeretné megismerni a C# világát.

Régebbi C# motorosoknak pedig a szintén most indult NetAcademia Certified Unity Developer 
útvonalról nem beszélek bővebben, ami akár az előző után is elvégezhető mivel a tanfolyamokról szokásosan visszanézhető videó készül, a könnyebb elmélyülés érdekében.

Szóval tényleg csak elhatározás kérdése most rendes C# programozóvá válni:)

Azzal szeretném megköszönni, hogy idáig olvastál, hogy ha van valami ötleted, hogy mit lenne jó megvalósítani a következő NetAcademia meetup-on/meetup sorozaton, akkor vagy kommentben, vagy e-mail-en (plesz.gabor@netacademia.hu) küldd el nekem.

Ajándékként azt tudom felajánlani, hogy ha nyersz, akkor -egy bögre mellett- a soron következő meetup-on -akár együtt is, ha van hozzá kedved- megcsináljuk.

46 komment

A bejegyzés trackback címe:

https://netacademia.blog.hu/api/trackback/id/tr9713983664

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

cog3981 2018.05.21. 17:10:51

Inkabb ajanlom a pythont, akkor siman fel lehet huzni egy Ubuntu/Debian szervert egyik cloud szolgaltatonal (5 USD havonta pl digitalocean), ahova MQTT-n keresztul fel lehet loni a homerseklet szenzor adatait a Raspberry Pi-rol :) ahol python flask webserveren keresztul megjelenited.
Igy barhol vagy, lathatod hogy a telefonodon hany fok van otthon :)

Az MS felismerhetne hogy kellene egy ingyenes Win Core Server tanulni.

valaki23 2018.05.22. 09:47:55

A havi 5 dollárt erre én sokallom, akkor már C#-ban ingyen tenném fel az Azure-ba. Mondom: ingyen.

2018.05.22. 10:58:41

@cog3981: C#-t még nem teszteltem, nem is használtam soha, de pythonnal van némi tapasztalatom. Mondjuk azonos gépen sokmindent tennék egy teljesítményigényes szerver alá, csak pythont nem. A 3-asnak mintha megnőttek volna az igényei...

-----
C# linuxon azért nekem még mindig elég kísértetiesen hangzik. Valami rémlik, hogy mono, meg hogy megy-megy, de azért mégsem az igazi... :)

Plesz Gábor · https://www.netacademia.hu/Oktato/PleszGabor 2018.05.22. 12:13:56

Mindenkivel egyetértek, csak két megjegyzés:

1. Azon az Ubuntu/Debian szerveren, amin a python megy simán elketyeg az ASP.NET Core alkalmazásom is (bár valóban, 10 db ingyenes webalkalmazást az Azure-ra is fel tudok lőni). És bizony a C# a különböző linuxokon teljes értékű polgár, példa rá a cikkben hivatkozott teljesítményteszt, ahol az alkalmazás linuxon fut éppen.

2. Azt nem tudom, hogy a python hogy teljesít windows környezetben, viszont ezek mellett mobilra is (Android-ra és iOS-re) és desktopra is tudok C#-ban fejleszteni - a pythonról nem hallottam hasonlót.

2018.05.22. 13:36:35

@Plesz Gábor: androidra elvileg lehet pythonban. Egyébként van linuxra ingyenes, teljesértékű IDE amiben C# fejlesztés is megy?
Tudásban kb. a Pycharm lenne az alap.
Az a visualizé szerintem elég kevés. Vagy nem néztem meg eléggé.

2018.05.22. 20:39:33

@valaki23: "Az a visualizé szerintem elég kevés" - az imént megnéztem kicsit alaposabban, ez csak egy advanced editor, igen messze van attól, amit én IDE-nek nevezek. (free változatról van szó természetesen)

cog3981 2018.05.22. 21:44:34

@valaki23: "A havi 5 dollárt erre én sokallom, akkor már C#-ban ingyen tenném fel az Azure-ba. Mondom: ingyen. "
Ingyen? Marmint 12 havi proba ido utan is ingyenes? Ha nem, akkor mennyibe kerul egy komplett legolcsobb szerver? Es speciel soha nem szerettem a beetetos idoszakokat. 12 honap utan is akarnam hasznalni a cuccot, lehetoleg nem 100 dollart fizetve havonta. Ha csak 5 akkor oke.

Nem tudok kiigazodni a price kalkulatoron :) Amugy az azure.microsoft.com iszonyu lassu mikozben 100Mb/s a sebessegem mashova.. csak nem azure-on fut? :D na jo, vicc volt.. meg a nagyokkal is megesik a lassusag.

Egy webalkalmazas vagy egy komplett szerver nem ugyanaz. Szerverre akarhany szolgaltatast, fel tudsz huzni akarhany retegben.
VPN-ben futnak a szenzorok/controllerek publisherjei, DB-ben tarolodnak el realtime adatok, View szinten el van valasztva a DB-tol. Python fogadja az adatokat, javascript/webgl jeleniti meg 3D-ben a terkepen merge-ve az adatokat. Mivel rengeteg felhasznalo, van ezert load balancerek is segitik a szolgaltatast. Ez van a cegnel. Meg lehet csinalni pythonban is :)
Az osszes komponens es technologia ingyenes, kiveve termeszetesen a szerverek es a savszel berleset.

Siman le tudod szimulalni egy olcso cloud-ban levo "tanulos" szerverrel+RPi-vel az _egesz_ infrastrukturat.

valaki23 2018.05.23. 06:24:23

@cog3981: Azure-ban teljesítményért kell fizetni, egy darab Raspberry Pi adatainak megjelenítése nem kíván különösebb teljesítményt, ezért arra az ingyenes bőven elegendő, ami természetesen örökre az, de azért nem kell csodákat várni. Ha bővülni kell, akkor lehet nagyobb csomagok felé lépni különösebb problémák nélkül. A lényeg az, hogy az ingyenes csomagban tudsz próbálgatni, nem kell a gatyádat ráfizetni a tanulásért.

@hullajelölt88: nem hiszem, hogy ez ennyiből megállapítható, ugyanis a lényeg a plugin-okban van. Bár én sem ezt használom egyelőre napi munkára, de erős a gyanú, hogy ez nem fog sokáig tartani. Mondjuk ezért: github.com/Microsoft/vscode

2018.05.23. 08:01:57

@valaki23: szerintem per pillanat esélye sincs, hogy a közelébe érjen egy pycharm/intellij vagy akár egy eclipse környezetnek.
Ubuntun: snap install vscode ; snap install pycharm aztán hasonlítsd össze őket. A vscode valahol a geany vagy a kdevelop környékén tart. Ahogy látom, a project is ismeretlen fogalom számára. A java update-ek fizetős irányba terelése miatt elgondolkodtam, hogy akkor irány a C#, úgyis csak hobbiból szórakozok ilyenekkel, de valahogy nem akar összeállni a kép. Tudtommal C#=.NET, az meg linuxon csak korlátozottan van támogatva, ha a nagyja hiányzik, akkor ezzel is úgy járok, mint a python2-3 váltással, hogy sok dolog nem érhető el vagy csak nagyobb energiabefektetéssel, mint egy apt install. (Forrásból telepíteni stb.) Ahhoz meg már öreg vagyok.

Plesz Gábor · https://www.netacademia.hu/Oktato/PleszGabor 2018.05.23. 08:45:33

Ez egy kicsit hosszú lett, @hullajelölt88: hobbiból a C# remek ötlet, csak nézz bele a cikkben hivatkozott meetup videókba:)

TL;DR

Én az ingyenes tanfolyamainkon a VSCode-ot használom, már csak azért is, mert volt már olyan, hogy a meetupra valaki macbook-kal érkezett, és egyszerűen nem lehetek windows-ba bezárva. Ezért aztán ahol lehet használom is, és azt mondom, hogy _még_nem éri el a Visual Studio Community (ami szintén ingyenes) szolgáltatásait és főleg a stabilitását, de _rettenetesen gyorsan fejlődik_.

Nekem a legtöbb hiba abból szokott adódni, hogy van, amikor az Intellisense elveszíti a fonalat, ilyenkor csak kilépés/belépés segít, de az a helyzet, hogy ilyenbe azért futottam már Eclipse-ben is, amikor hirtelen minden pirossal alá lett húzva.

Vannak hibái, nem olyan hatékony, mint a visual studio, vagy pedig a fizetős editorok (pl.: a JetBrains rider, ami nyilván jóval többet tud, ha már pénzt kér :) bár leginkább a refactoring tool-okkal jár előrébb, ahogy hallottam).

Viszont ismeri a projekt fogalmát, rettenetesen sok beépülő modulja van, és hihetetlen tempóban fejlődik. Pair programminghoz például most a BUILD-en tették nyilvános preview-ba a Live Share-t (code.visualstudio.com/blogs/2017/11/15/live-share), együttműködik nem csak VS CODE-dal hanem Visual Studio-val is ilyen sharing session-ökben. Azt például nem tudom, hogy milyen editor támogat még ilyesmit, ingyen, Windows-on, OSX-en vagy linuxon. A beépülőkkel van Docker támogatása, teljes értékű degub felülete van, és még sorolhatnám.

Ami pedig a C# és a linux viszonyát illeti, ez egy létező frigy, probléma akkor jöhet elő, amikor valaki pl. olyan (nuget) csomagot használ, aminek még nincs .NET Core támogatása. De ez egyre ritkább, ahogy telik az idő, legalábbis ahogy én tapasztalom.

Amióta pedig a Docker for Windows pedig megjelent és használható, Windows-on is választhatok több futtatókörnyezet közül, amit tesztelni is tudok akár Windows-os gépemen is. Ezért választottam a Raspberry PI programozást Dockerrel, mint bemutatót, mert látszik, hogy milyen hihetetlenül egyszerű egy fejlesztést indítani C#/.NET/VS Code segítségével. Érdemes belenézni a videókba, nem csalás, nem ámítás.

Én például az Azure-on egy Dockeres masinát 7USD-ért futtatok, amin most éppen négy ASP.NET Core alkalmazás fut tesztelési célokból. De mivel Docker konténerek, _akárhova tehetem őket_, épp ez a szép benne.

És tényleg nem beszéltünk még OSX/iOS/Android mobil appokról, illetve Windows Desktop appokról, amiben szerintem a python nem tud a C# ellenfele lenni egyelőre, de szerintem nem is akar.

Valamint, mindaz, amit eddig írtam, ingyenesen hozzáférhető, használható, csak a tanulási görbe a gátja.

Én egyébként nem azt mondom, hogy a C# jobb, mint bármi, hanem azt, hogyha most valakinek választania kell egy nyelvet, nézzen rá, mert per pillanat úgy néz ki, hogy a C# az a nyelv, amit most a legnehezebb "kinőni":)

Sealka 2018.05.23. 09:01:37

Na most C# 2D/3D és erre példa a Unity? A Unity egy game engine, amit C++ ban írtak és ott a C# csak egy script réteg. Akkor inkább legyen már példa a Xenko, amit C# 7-ben(!) fejlesztenek, teljes értékű 3D game engine!

Plesz Gábor · https://www.netacademia.hu/Oktato/PleszGabor 2018.05.23. 09:11:11

@Sealka: köszi a Xenko tippet, nagyon király!!!

A C# a Unity-vel inkább azért példa, mert egyrészt most épp van egy ilyen tanfolyam sorozatunk: Unity C#-ból (app.netacademia.hu/unity-developer), másrészt, ha jól tudom, akkor két nyelven lehet a Unity-t most scriptelni: JavaScript és C# a választék. Ádám (az oktatónk) mondta, hogy JS-el kezdett, mert annak kezdetben jobb volt a támogatása, de mostanra egyértelműen C#-ot használja a munkában, mert számára egyértelműen jobb.

De sem python, sem java, sem go és még sorolhatnám, nincs a lehetőségek között. Engem inkább ezért fogott meg:)

Sealka 2018.05.23. 09:22:19

@Plesz Gábor: A Unity tetszőlegesen scriptelhető és többek között Lua is használható, ami elég népszerű a játékoknál lásd WoW, Crysis stb. (en.wikipedia.org/wiki/Category:Lua-scripted_video_games).
Nem tudom mennyire érdemes egy ilyen összetett nyelvet, mint a C# scriptelésre használni, bár, ha az engine-hez nincs hozzáférés, akkor kénytelen a fejlesztő scriptben megírni sok olyat, aminek igazából nem ott lenne a helye. A Script szerintem egyszerű pár soros modulokból álló event alapú hot realoading-ra épülő gyors prototipizálásra való cucc, nem több 100, vagy ezer soros architektúrák írására, mint, amire a C# is való eredetileg.

Plesz Gábor · https://www.netacademia.hu/Oktato/PleszGabor 2018.05.23. 09:31:01

@Sealka: ehhez sajnos nem értek, de biztosan így van, köszönöm a kiegészítést! Viszont az Ádámék a Unity segítségével egy olyan kesztyűt csináltak (GlovEye), ami vakoknak BREI írással megmutat egy könyvet, ha a kesztyűvel végig simítanak a lapokon, és ehhez a Unity VR eszközei nagyon jól használhatóak, ahogy megmutatta. És ez már egy komoly alkalmazás, erről is van egy ingyenes bemutatónk: app.netacademia.hu/Tanfolyam/2017gloveye-gloveye---hogyan-keszult

2018.05.23. 10:17:47

@Plesz Gábor: mi az a BREI írás? (Braille)

Plesz Gábor · https://www.netacademia.hu/Oktato/PleszGabor 2018.05.23. 11:21:03

@hullajelölt88: jogos, köszönöm szépen a kiigazítást!

midnightcoder2 2018.05.23. 15:25:41

@cog3981: A python ezer sebböl vérzik, pedig van pár dolga amit én is szeretek. Script nyelvnek szerintem teljesen Ok, de komolyabb appot nemigen csinálnék benne. Ennek több oka is van:
1. A default implementáció (CPython) nagyon-nagyon lassú. A sebességteszteken általában masszívan az utolsó helyek környékén található.
2. Vannak ugyan halvány próbálkozások a statikus típuskezelés irányába, de alapvetöen dinamikus, ráadásul a nyelv is értelmezett. Ami nagyobb projektek esetén bizony elég nagy szívás. Nincs rendes intellisense, refactoring, egy függvényröl igazán soha nem tudod biztosan hogy futáskor mit kapott paraméterként, egy, stb.
Ez pár ezer sornál még nem fáj, pár milliónál már igen.
3. A mai napig nem tudtak átállni a 3-as verzióra.

midnightcoder2 2018.05.23. 15:30:11

@Sealka: Attól függ. Ha a 10000. FPS-t vagy Angry Birds-t akarod megírni, akkor valóban. Komolyabb játéknál viszont elég szívás a primitív scriptnyelv és a mögötte lévö primitív logika. Lásd az amúgy gyönyörü, hatalmas Skyrim ahol még a legfontosabb szereplök is ugyanazt a 3-4 elöre scriptelt mondatot tudják mondani, ráadásul meglehetösen függetlenül a történtektöl. Hiába a tonnányi belepakolt content, hiába a jó 3D és fizikai motor, az élményt nagyon-nagyon lerontja az AI.

2018.05.23. 15:36:04

@midnightcoder2: az 1. pont eleve értelmetlen. A többi implementáció még lassúbb (jython és tsai). És mindezek ellenére vannak elég nagy python alapú rendszerek is.

midnightcoder2 2018.05.23. 17:03:45

@hullajelölt88: dBaseIII-as rendszerek is voltak 4Mhz-es IBM PC-ken, söt dBaseII-esek CP/M-en Z80 procival.
Nem mindenhez kell kerítésszaggató performancia.

2018.05.24. 08:19:36

@midnightcoder2: meg is nézted a linket? Google, youtube, dropbox... csupa apró site-ok... :D
A google nem tudom, azon fut-e, a youtube-ról voltak ilyen emlékeim.

2018.05.24. 08:29:22

@midnightcoder2: ja, meg talán nem árt a pythont, ha ugyan van ebből 3-as is, pypy használatával futtatni. Az is tud izgalmas dolgokat. Ezen túl meg a benchmarkok... néha, konkrét esetben jelenthetnek valamit, de messzemenő következtetéseket nem vonnék le belőlük.
Csak egy példa: évekkel ezelőtt valami regex feladvánnyal szarakodtam. Elégedetlen voltam az akkori python2.7 teljesítményével, kipróbáltam ugyanazt javaban és C+(talán )pcre lib környezetben. Messze a python volt a leggyorsabb. Ja... persze... egy konkrét regex esetében. :D A többi próbáknál már a várható eredmény jött ki: a C volt gyorsabb. Hogy pont azzal a kifejezéssel miért tudott a python ennyire gyors lenni...

2018.05.24. 17:35:11

@midnightcoder2: csak a performanciára reagálnék. Néhány hónapja kitaláltam, hogy feltalálom a kereket, mert az elérhető monitoring programok nem feleltek meg az igényeimnek és akartam írni egy primitív monitor programot, ami kb. CPU, I/O terhelést és néhány fizikai paramétert mér. A program megírására nem került sor, de gyártottam egy kis performancia tesztnek indult valamit, amit akár keretrendszernek is lehet nevezni. Ha valakit érdekel, a githubon elérhető: github.com/haa-zee/proc_speedtest
Ez elég specifikus teszteket futtatott, de az elég jól látszik, hogy a python3-nak nem erőssége a sebesség, amire korrekt magyarázatot a mai napig nem kaptam. Sajnos a C# kimaradt a tesztekből, ha valaki ír egy olyat, ami ugyanazt csinálja, mint a többi, szívesen kipróbálom linuxon.

midnightcoder2 2018.05.25. 12:44:44

@hullajelölt88: Ez olyan dolog, hogy egy dolog hogy használok valamit, és egy másik hogy erre alapozok.
Pl. anno nagy hír volt (na jó, föleg a prog.hu vidékén), hogy a PayPal javascriptre és nodejes-re épül, lám a pénzügyi területen is jó a javascript. Aztán ha picit megnézed az álláshirdetéseiket, azt látod hogy több javás embert keresnek mint javascripteset, ergo finoman szólva nem teljesen javascriptre épül az egész...

midnightcoder2 2018.05.25. 12:46:15

@444Hz: Az a benchmark games amit belinkeltem ilyesmiröl szól. Régen be lehetett állítani hogy milyen nyelvet mihez hasonlítasz, és mindent ugyanolyan vason hasonlított össze.

2018.05.25. 14:23:57

@midnightcoder2: nem akarod megírni hozzá a C# tesztet? ;) De ha jól megnézed, amit teszteltem, az egy elég korlátozott dolog, nem biztos, hogy például különböző webes keretrendszerek benchmarkja is hasonló eredményeket hozna. Weben nem vagyok otthon, csak felhasználóként, de úgy láttam, amiben gyengélkedik a Python, az csupa olyasmi, ami webes alkalmazásoknál kevésbé jelent gondot. Sajnos ennek tesztelése meghaladja a tudásomat, hinni viszont csak annak a tesztnek hiszek, amit magam hamisítottam. :)

midnightcoder2 2018.05.27. 10:37:47

Amit te tesztelsz itt ebben, az leginkább a fájlrendszer és a körülötte lévő libek, sebességtesztje, ráadásul a linuxos proc fájlrendszeré ami önmagában is érdekes állatfajta.

Ha jól értettem hogy mit csinálsz, akkor te valami ilyen lovat akarsz:

static void Main (string[] args)
{
int n=0,e=0;
for (int i = 0; i < 1; i++)
{
foreach (var s in Directory.GetDirectories (@"C:\proc").Where (w => char.IsDigit (Path.GetFileName (w) [0])))
try
{
using (var f = new StreamReader (Path.Combine (s, "stat")))
{
string str = f.ReadLine ();
n++;
}
}
catch
{
e++;
}
}
Console.WriteLine ($"count: {n}, error:{e}");
}

2018.05.27. 11:12:35

@midnightcoder2: köszi, legalább kipróbálom a VS Code-t. :) Ahogy elnézem, azért ez nem olyan triviális, mint egy C program fordítása. De majd megküzdök vele. :)

midnightcoder2 2018.05.27. 11:57:44

Elég triviális. Felteszed a .net core-t, csinálsz egy könytárat, belépsz, azt mondod dotnet new console, a program.cs-be beteszed a kódot, majd azt mondod hogy dotnet run

midnightcoder2 2018.05.27. 11:59:14

A kód elejére azért kell olyan, hogy

using System;
using System.IO;
using System.Linq;

2018.05.27. 12:08:03

@midnightcoder2: triviális nálam úgy néz ki egy ilyen helloworld színvonalú kódnál, hogy <fordító> <forrás> :)
Ezért mondtam, hogy nem annyira triviális a dolog.

2018.05.27. 12:40:43

@midnightcoder2: hát ezzel még dolgozni kell, mert nem pont úgy működik a dolog, ahogy elképzeltem, pl. a dotnet pythonból indítva nem igazán akar működni. :)
Parancssorból O.K., de ha beírom a paraméterfájlba és indítanám a saját keretemmel, akkor már csak egy helpet dob.

2018.05.27. 12:42:29

@444Hz: ez legalább gyorsan megoldva. Kicsit (nagyon) rosszul látok, nem tűnt fel, hogy hiányzik a run a paraméterek közül.

2018.05.27. 12:54:13

@444Hz: elkészült a nagy mű, azért én jóval többet vártam tőle. :(

Test: C#
User: 16.466179 System: 23.702187
User: 16.070435 System: 24.058626
U.avg: 16.268307 S.avg: 23.8804065 Total avg: 40.1487135

Test: C2
User: 2.295852 System: 14.594102
User: 2.239189 System: 14.7084
U.avg: 2.2675205 S.avg: 14.651250999999998 Total avg: 16.9187715

Test: Python3
User: 48.672912 System: 25.718156
User: 47.647527 System: 26.004727
U.avg: 48.1602195 S.avg: 25.861441499999998 Total avg: 74.021661

Test: Python2
User: 15.005631 System: 19.443078
User: 16.223801 System: 22.943473
U.avg: 15.614716000000001 S.avg: 21.1932755 Total avg: 36.8079915

A C2 azért 2, mert egy optimalizált, az én verziómnál gyorsabb kódot futtat. A python2 és 3 azonos kód, azon nagyon látszik, hogy mennyivel gyengébb e téren a 3-as. Viszont az, hogy a C# kb. a python2-vel van egy szinten, cseppet elkeserít. Valahogy arra számítottam, hogy közelebb lesz a natív C-hez.

midnightcoder2 2018.05.27. 17:06:38

Igazából mint mondtam, ez a teszt nagyjából csak a fájlrendszer elérésének a sebességét méri.
A fenti link amit beküldtem ennél picit szofisztikáltabb, de már nem annyira jó mint régebben amikor még tudott nyelveket hasonlítani azonos környezetekben.

A valósághoz kb. szerintem ez áll a legközelebb:
www.bioinformatics.org/benchmark/results.html

Vagy ez:
jaxenter.com/energy-efficient-programming-languages-137264.html

De ezek a tesztek mindig elég szubjektívek. Ha egy adott nyelvben egy adott művelet mögött egy, az adott dologra tökig optimalizált assembly kód áll, azt nyilván elég gyorsan fogja végrehajtani. Ha a teszt erre az egy dologra van kihegyezve, akkor az adott nyelv lesz a hegyek királya. Ugyanakkor a valós életben lehet, hogy ezt az adott műveletet 10 évente egyszer hívja meg a programod, és az adott nyelv minden másban viszont rohadt lassú.

2018.05.27. 20:09:15

@midnightcoder2: még csak nem is igazán a fájlrendszert. Jól sejtem, hogy a linux nem a te világod? :) Csak a 'C:\proc' miatt... A /proc egy virtuális fs, ahonnan a futó processzek adatait, meg pár egyéb, a rendszerhez kapcsolódó infót lehet lekérdezni I/O műveletekkel (ami többnyire kimerül az open/read/close trióban)
Ha a keretrendszer-kezdeményt nem számolom, akkor esetemben épp qz volt a cél, hogy felmérjem, a procfs kezelése elfogadható sebességgel megy-e pythonban, aztán jött mellé pár, más nyelven megírt teszt, előbb csak azok, amikkel én is boldogulok, később meg néhány öncélú, a közönség reklamációjára :)
Az általános célú benchmarkokban meg csökönyösen nem hiszek.

midnightcoder2 2018.05.28. 09:51:11

@444Hz: De, tudom mi az a proc fájlrendszer, lásd 2018.05.27. 10:37:47-as hsz-em.
De a nyelvek szempontjából ez kb. mindegy, az alján jó eséllyel kb. ugyanaz a glibc-s függvényhívás lesz, mert hogy fájlként kezeljük. Ami különbség itt lehet az max. az ami e fölött van.

2018.05.28. 11:38:33

@midnightcoder2: akkor bocs, csak a C:\ valahogy nem jellemző linuxon/unixon ;)

Ami különbség itt van, az pont a lényeg számomra. Épp az volt a fontos, hogy a használt nyelv mennyivel lassítja a dolgokat és ez elég jól kijött. Bár az érdekes, hogy a System idők is elég eltérőek. (a User lenne amit a program önmagában művel)

midnightcoder2 2018.05.30. 08:17:10

@444Hz: Ja, az igazság az, hogy jelenleg Linux csak virtualboxban van a gépemen.

444Hz (törölt) 2018.05.30. 09:37:47

@midnightcoder2: az előtő laptopomon nekem is csak virtualboxban volt. De csak azért, mert a hardver nagy részéhez csak windows driver volt. :)

Ha már ilyen kedélyesen elbeszélgetünk itt: nincs tipped, hogy ha szövegfájlokban hasonló sorok kiválogatása lenne a cél, akkor milyen eszközt keressek? Úgy értem, szövegfeldolgozáson belül mit?
Életből vett példa: linux logok, amiből ki akarom szűrni az rendszeresen előforduló sorokat, hogy csak a ritkán megjelenő, esetleg fontos sorok maradjanak. Amíg azonosságra kell keresni, addig nincs gond, de itt ugye van olyan, hogy "... DROP IN=eth0 ..." ebből van rengeteg és az esetek nagy részében érdektelenek, de a sorban a többi paraméter változik. Milyen eszköz kell az ilyen jellegű feladatokra? Általánosságban érdekel, nem konkrét framework vagy kész rendszer. Nincs valami tipped?

midnightcoder2 2018.05.30. 12:20:00

Ez azért már elég egyedi probéma. Valahogy definiálni kell, hogy mi az ami érdektelen és mi az ami nem. Én valahogy definiálnám az érdektelen részeket mondjuk regexp-pel, és a maradékot vizsgálnám.

444Hz (törölt) 2018.05.31. 01:58:20

@midnightcoder2: mondom, a log az csak egy példa volt, magát az elméletét keresem ennek az egésznek, nem a konkrét megvalósítást. Erősen feltételes módban talán a szövegbányászat keretein belül láthattam ilyet, talán valami statisztikai algoritmusok alkalmazásáról cikkben vagy valami más hasonló helyen, csak rácsodálkoztam, hogy "jé, hol tart már a tudomány", de akkoriban csak annyira érdekelt a téma, hogy átfutottam pár cikket, anélkül, hogy mélyebb nyomot hagyott volna bennem. Mindegy, nagy jelentősége nincs a dolognak, inkább csak a kíváncsiság hajt most is.

444Hz (törölt) 2018.05.31. 02:25:23

@midnightcoder2: úgy tűnik, jobb ha éjjel keresgélek. Azt hiszem, valami ilyesmi volt, amit nem találtam már napok óta: en.wikipedia.org/wiki/Levenshtein_distance - és azért nem jegyeztem meg, mert a matematikai részletek már meghaladják a képzettségemet. :)