Kertokaas tiedonpuutteiselle miksi yhä useammat lähinnä Winille ohjelmoivat siirtyvät käyttämään dotNET-Frameworkin C-kieliä ? Useammassa kuin monessa paikassa softan vaatimuksissa on dotNET-Frameworkin 2 tai 3 jos ei ennen ollut.
Pääasiassa PaintDotNETin suorituskyky alkoi pelottamaan faktana että se
1) käyttää Frameworkii
2) on suoraan 64-bittinen
2.2) on ruttotautisen nopea massiivisen skaalan laskennoissa kuten 3200x2675-kuvissa missä 32-bittisessä Winissä tuon skaalan kuvien käsittely kaataa softan puolessa tunnissa.
Eli: onko dotNET-Framework oikeasti niin järeä (ja Win samalla) että sillä kieleen perehtynyt saa aikaan softan joka ei vaadi käyttäjää odottamaan ? PDN:n tekijöiden lyhyt kertomus 8-coreprossujen tehosta heidän softan kanssa jollain Winillä heidän ällistyksellä ei ollut rajaa; tämä siis tarkoittaa että Win on jo tukenut multicoreaivoja ja erittäin hyvin, eli se ei ole ollut NIXien yksinoikeus kokoajan.
Enpä ole kuullut, että kukaan käyttäisi C:tä, mahtaako olla edes järkevästi mahdollista? Käsittääkseni myöskään C++ ei ole tuolla aivan hirmuisen suosittu. Ehkä sekoitat nyt C#:iin, joka taas on aivan oma kielensä.
Muutenkaan en kyllä yhtään ymmärrä kysymystäsi. Kyllä, .NET Frameworkia käytetään nykyään, eikä siinä minusta ole mitään ihmeellistä: onhan se tuhannesti käytännöllisempi kuin perinteiset WinAPI-sotkut. Ei sitä kuitenkaan voi varmasti tehokkaammaksi väittää, vaan eiköhän tuo nopeushyöty tule yksinkertaisesti nykyaikaisemmasta laitteistosta (ja toisaalta nykyaikaisemmista kääntäjistä, kyllähän sielläkin tekniikka kehittyy, mutta kehittyy se muuallakin kuin .NET-puolella). Itsekin mainitsit 8-ytimiset prosessorit, onko muka ihme, jos sellaisella onnistuu jokin nopeammin kuin ikivanhalla yksiytimisellä?
Metabolix kirjoitti:
...
Pointti on Window$in kyvyssä käsitellä sitä tehoa. Olkoon vaikka C# sitten, en ole tarpeeksi tutkinut.
Ainoa .NET frameworkin välitön vaikutus nopeuteen mikä tulee mieleen on, että se käännetään välikielestä konekielelle vasta käyttäjän koneella, jolloin se on optimoitu juuri sille prossulle mikä käyttäjällä on.
Välillisiä vaikutuksia on ehkä, että se voisi kannustaa paremmin tekemään hyvin suunniteltuja ohjelmia. Eli C++:lla täytyy ehkä enemmän aktiivisesti välttää tyhmiä ratkaisuja. Tämä jälkimmäinen on sitten täysin mutua.
Grez kirjoitti:
---
Miten sitten selität PDN:n nopeuden ?
Hyvä algoritmi? Tai siis hyvin koodattu se algoritmi ja optimoitu.
vehkis91 kirjoitti:
Hyvä algoritmi? Tai siis hyvin koodattu se algoritmi ja optimoitu.
Huh, ainakaa ei sitten löydy pätevää syytä. Vielä.
No siis mihin vertasit. Oliko se PDN huiman nopea 64-bittisessä Windowsissa ja täsmälleen sama PDN:n versio huiman hidas ja kaatuileva 32-bittisessä Windowsissa? Jos vertasit eri versioita niin ehkä siinä hitaassa ohjelmassa oli käpyinen tai huonosti toteutettu algoritmi ja bugeja.
3200x2675 on muuten todella pieni kuva vielä - jotain parin vuoden takaisten digikameroiden luokkaa . Itse olen käsitellyt jo yli 5 vuotta sitten 16 kertaa isompia kuvia (skanneja suurkokofilmeistä) senaikaisella Photoshopilla ja senaikaisilla tietokoneilla eikä ole ollut koskaan mitään ongelmaa. Eli ei ole joutunut kohtuuttoman pitkään odottamaan eikä ole koskaan kaatunut Win XP:ssä.
Grez kirjoitti:
3200x2675 on muuten todella pieni kuva vielä - jotain parin vuoden takaisten digikameroiden luokkaa . Itse olen käsitellyt jo yli 5 vuotta sitten 16 kertaa isompia kuvia (skanneja suurkokofilmeistä) senaikaisella Photoshopilla ja senaikaisilla tietokoneilla eikä ole ollut koskaan mitään ongelmaa. Eli ei ole joutunut kohtuuttoman pitkään odottamaan eikä ole koskaan kaatunut Win XP:ssä.
Pessimismisyyteni voitto taas.
Ei mikään framework pysty itse monisäikeistämään ohjelmaa, kyllä se säikeisiin erottelu täytyy koodarin itse tehdä. Mikään framework ei myöskään pysty repimään raudasta yhtään sen enempää tehoja kuin mihin vaikka c++:lla pystyy. Bittisyys - no, itse en ole joutunut välittämään siitä mitään, linuxdistrot kun osaavat tarjota paketit 64-bittisinä, windows onkin sitten eri asia. Tuo kuva mistä puhuit on kyllä erittäin pienikokoinen ja ohjelmassa olisi vakavia perustavan tason virheitä jos sen skaalaaminen nykykoneilla oikeasti kestäisi.
En tiedä liittyykö asiaan mutta välitietoa... Tuollaset kuvakoot vaatii muistia aika runsaasti. Tein pienen kokeilun Gimp:llä (Win32); 4000x3000 kuva vie muistia 108Mt. Piirtäminen ja efektit vaivatonta ja nopeaa, skaalaaminen hitusen pienemmäksi vei pari sekuntia tämmösellä 2-ytimisellä.
8000x6000 kuvan luomisesta alkaa jo ohjelmakin varotella, koko on jo puolen gigatavun luokkaa.
24-bittinen 8000x6000 kuva on (pakkaamattomalta) kooltaan 144 000 000 tavua. Sitä voi olla järkevää käsitellä 32-bittisinä lukuina, jolloin se veisi 192 megatavua. Mitään hirveän paljon suurempaa muistinkulutusta on vaikea perustella. Toki jos kerroksia tulee lisää, niin muistiakin kuluu lisää.
Tuollainen 2,5 -kertainen muistinkulutus kuulostaa epäilyttävältä. Ehkä Gimpillä on jokin järkevä peruste moiselle, mutta muuten kyllä kuulostaa lähinnä huonolta toteutukselta.
Kun mainitsin tuossa aikaisemmin, että käsittelin joskus n. 5 vuotta sitten 12800x10700 kokoluokan kuvia, niin tein sitä 2 gigan muistilla varustetulla koneella ja noi mahtui vielä ihan kivasti muistiin. Selkeästi isommilla kuvilla tai jos noita oli enemmän kuin 2 kerralla auki niin kiintolevykin lauloi jonkin verran, mutta homma ei silti mennyt hirveän hitaaksi (PS osasi ainakin silloin käyttää tosi näppärästi kiintolevyä muistin jatkeena. Nykyiset PS-versiot kuulemma kaatuu (kommentti sarjiksen alla) herkemmin.
Kray kirjoitti:
Ei mikään framework pysty itse monisäikeistämään ohjelmaa, kyllä se säikeisiin erottelu täytyy koodarin itse tehdä. Mikään framework ei myöskään pysty repimään raudasta yhtään sen enempää tehoja kuin mihin vaikka c++:lla pystyy. ...
/inttämistä
No toi ei taida enää kyllä pitää paikkansa. Framevorkki pystyy säikeistämään monoliittistakin koodin pätkää.
Otetaan esim. laskutoimitukset
A=1+2
B=3+4
Näiden laskutoimitusten välillä ei ole riippuvuutta joten ne voidaan suorittaa eri säikeissä samanaikaisesti eri laskentayksiköillä jos koneessa niitä vapaana on.
Framevorkkeihin on taittu kehitellä näitä ominaisuuksia jo pitemmän aikaa. Joten helpoin tapa säikeistää vanha ansi-c koodi on kääntää se .net kääntimellä ja antaa framevorkin hoitaa säikeistys.
Eli kääntäjä voisi optimoida
Säie1: A=3
Säie2: B=7
:D
Ilmeisesti tässä puhutaan jostain kevyemmistä säikeistä kuin mitä normaalisti säikeistettäessä tehdään. Tai ainakin käsittääkseni esim. .net frameworkissä säikeen käynnistäminen on huomaasti raskaampi prosessi kuin luvun sijoittaminen muuttujaan. Tai sitten tuo oli vaan huomattavasti yksinkertaistettu esimerkki.
Grez kirjoitti:
Eli kääntäjä voisi optimoida
... Tai sitten tuo oli vaan huomattavasti yksinkertaistettu esimerkki.
Juu, hiukkasen yksinkertaistettu. Ajattelemalla muuttujia numeroiden tilalle päästään lähemmäs todellisuutta.
Joskus kauan aikaa sitten wintoosa tunsi säietyypin fiber (tai jotain sinnepäin). Nämä oli sellaisia kevyitä säikeitä jotka ei tainnut varata edes omaa muistiavaruutta vaan toimivat pääsäikeen alaisuudessa. Voisi kuvitella .net frameworkin omaavan samanlaisia ominaisuuksia jos ei muuten niin sisään rakennettuna.
Nyt kannattaa kuitenkin muistaa, että säikeistys on eri asia kuin rinnakkaistaminen. Tämän tyyppinen (automaattinen) rinnakkaistaminen
http://en.wikipedia.org/wiki/
http://en.wikipedia.org/wiki/
on nimittäin ikivanha juttu ja ihan "tavallisetkin" C-kääntäjät handlaavat sen vallan mainiosti. Automaattinen säikeistys taas on asia erikseen. Sitä on kyllä tiettävästi yritetty kehittää hyvin pitkään, mutta tulokset taitavat edelleen olla aika heikkoja ja riippuvaisia käsitteen "automaattinen" määritelmästä. Vai ovatko? Näistä .NETin väitetyistä kyvyistä olisi kyllä kiva saada vähän tarkempaa infoa.
os kirjoitti:
Näistä .NETin väitetyistä kyvyistä olisi kyllä kiva saada vähän tarkempaa infoa.
Ei kai tuo nyt ihmeitä itsekseen voi tehdä? Taitaa tuo automaattinen säikeistäminen jäädä lähinnä siihen, että ohjelmassa voi käyttää frameworkin tarjoamia asynkronisia metodeja.
os kirjoitti:
Nyt kannattaa kuitenkin muistaa, että säikeistys on eri asia kuin rinnakkaistaminen. Tämän tyyppinen (automaattinen) rinnakkaistaminen
http://en.wikipedia.org/wiki/
Instruction_level_parallelism
http://en.wikipedia.org/wiki/Instruction_pipelining on nimittäin ikivanha juttu ja ihan "tavallisetkin" C-kääntäjät handlaavat sen vallan mainiosti. Automaattinen säikeistys taas on asia erikseen. Sitä on kyllä tiettävästi yritetty kehittää hyvin pitkään, mutta tulokset taitavat edelleen olla aika heikkoja ja riippuvaisia käsitteen "automaattinen" määritelmästä. Vai ovatko? Näistä .NETin väitetyistä kyvyistä olisi kyllä kiva saada vähän tarkempaa infoa.
Jep, määrittelyt kunniaan. En heti hoksaa mitä eroa haet säikeistyksellä ja rinnakkaistamisella.
Ja joku .net:stä tietävä voisi valottaa sen ominaisuuksia (löytyykö ketään?).
tepokas kirjoitti:
Jep, määrittelyt kunniaan. En heti hoksaa mitä eroa haet säikeistyksellä ja rinnakkaistamisella.
No juuri sitä, että myös tuo useamman käskyn suorittaminen lomittain (yhtä aikaa) samalla prosessoriytimellä prosessorin liukuhihnan avulla on myös rinnakkaistamista (mutta ei säikeistämistä) ja sitä kääntäjät / prosessorit ovat osanneet tehdä automaattisesti iät ja ajat.
tepokas kirjoitti:
Ja joku .net:stä tietävä voisi valottaa sen ominaisuuksia (löytyykö ketään?).
Mihin "frameworkkiin" oikein viittasit, kun juuri väitit, että
tepokas kirjoitti:
Framevorkki pystyy säikeistämään monoliittistakin koodin pätkää.
...
Framevorkkeihin on taittu kehitellä näitä ominaisuuksia jo pitemmän aikaa. Joten helpoin tapa säikeistää vanha ansi-c koodi on kääntää se .net kääntimellä ja antaa framevorkin hoitaa säikeistys.
Tämä nimittäin kaipaisi vähän valottamista.
Pitää toki paikkansa, että modernit virtuaalikoneet (kuten .NETin tai Javan) pystyvät parhaissa tapauksissa parantamaan ohjelman suorituskykyä verrattuna valmiiksi käännettyyn ohjelmaan erilaisten dynaamisten optimointien avulla sekä binäärimuodossa levitettyihin ohjelmiin verrattuna mahdollisesti myös paremman prosessorikohtaisen optimoinnin avulla. Automaattinen säikeistys ei käsittäkseni vielä kuitenkaan kuulu repertuaariin.
os kirjoitti:
tepokas kirjoitti:
Jep, määrittelyt kunniaan. En heti hoksaa mitä eroa haet säikeistyksellä ja rinnakkaistamisella.
No juuri sitä, että myös tuo useamman käskyn suorittaminen lomittain (yhtä aikaa) samalla prosessoriytimellä prosessorin liukuhihnan avulla on myös rinnakkaistamista (mutta ei säikeistämistä) ja sitä kääntäjät / prosessorit ovat osanneet tehdä automaattisesti iät ja ajat.
...
Ok, rinnakkaistaminen tuli jotenkin selväksi, määrittele vielä säikeistäminen. Meitille tuo rinnakkaistaminen ajaa suunnilleen samaa kuin säikeistäminen, eli ohjelman suorituksen jakamista useammalle ytimelle samaan aikaan suoritettavaksi.
no ei se kyllä mitään automaattisesti säikeistä. helpottaa kyllä huomattavasti.
ks. ThreadPool
os kirjoitti:
tepokas kirjoitti:
Jep, määrittelyt kunniaan. En heti hoksaa mitä eroa haet säikeistyksellä ja rinnakkaistamisella.
No juuri sitä, että myös tuo useamman käskyn suorittaminen lomittain (yhtä aikaa) samalla prosessoriytimellä prosessorin liukuhihnan avulla on myös rinnakkaistamista (mutta ei säikeistämistä) ja sitä kääntäjät / prosessorit ovat osanneet tehdä automaattisesti iät ja ajat.
Mutuilisin että .NETin ja Javan virtuaalikoneet voisi toteuttaa tavukoodin rinnakkaistamisen suorittamalla tavukoodia useammassa säikeessä "samaan aikaan". Veikkaisin että tepokas viittasi tähän alunperin. En sitten tiedä, onko vastaavaa systeemiä toteutettu tai nopeentaisiko se edes koodin suorittamista. Prosessorin käskyjen rinnakkaistaminen ja tavukoodin rinnakkaistaminen ovat kuitenkin aika eri juttuja.
Deffi kirjoitti:
Mutuilisin että .NETin ja Javan virtuaalikoneet voisi toteuttaa tavukoodin rinnakkaistamisen suorittamalla tavukoodia useammassa säikeessä "samaan aikaan".
Tavallisilla synkronointitempuilla toki pystyisi säikeistämään automaattisesti "mitä tahansa", mutta liian tiheä synkronointi aiheuttaa kohtuutonta ajanhukkaa. Jotta toteutus olisi tehokas, riippumatonta koodia pitäisi siis olla kerralla suoritettavana melko paljon, mikä taas edellyttäisi usein aika syvällistä koodianalyysia. (Toisaalta ääntä, kuvaa tai muuta taulukkomuotoista dataa voi kyllä olla helppokin käsitellä useassa säikeessä yksinkertaisesti jakamalla data tasan säikeiden kesken.)
Javan ja .NETin kaltaisissa järjestelmissä koodin analysointi on onneksi helpompaa kuin vaikkapa C:ssä, koska ohjelmoija ei pääse esimerkiksi käsittelemään muistia suoraan. Tästä huolimatta ongelmaksi jää, että tietokone ei ymmärrä ohjelman toimintaa käytännössä eikä siis osaa tehdä samanlaisia oletuksia kuin ohjelmoija itse. Siksi on epätodennäköistä, että tietokone pääsisi vielä pitkään aikaan samalle tasolle kuin taitava ohjelmoija.
Tilannetta voidaan helpottaa puoliautomaattisilla ratkaisuilla (esim. OpenMP), joissa ohjelmoija erikseen kirjaa lähdekoodiin omia lisätietojaan, joiden perusteella kääntäjä sitten toteuttaa säikeistyksen.
Tredin aloitusaihe oli kylläkin Micro$oftin dotNET-teknologian joku kieli jolla PDN kirjoitetaan. Tietenkin millä tahansa muulla kielellä kirjoitettu softa pärjää paremmin kuin M$:n teknologiat parhaissakin unissa.
No se framework on hyvin pieni osatekijä nopeudessa suhteessa moniin muihin seikkoihin. Millä vaan kielellä pystyy kirjoittamaan todella hitaan ohjelman.
Sitä paitsi omakohtaisen kokemuksen mukaan hitauden ja Javan välillä on yleensä suurempi korrelaatio kuin hitauden ja .Netin. Eli siinä mielessä en allekirjoittaisi tuota edes yleistävällä tasolla. Voihan toki olla että vika ei ole Javassa, vaan osaamattomissa Java-koodaajissa.
Grez kirjoitti:
... Voihan toki olla että vika ei ole Javassa, vaan osaamattomissa Java-koodaajissa.
Tuon allekirjoitan heti.
Javan suorituskyky on käsittääkseni sinänsä ihan hyvä, mutta pitkä käynnistysaika (mm. virtuaalikoneen käynnistämisestä ja JIT-käännöksestä johtuva) ja roskienkeruusta johtuvat suorituskykynotkahdukset laskevat käyttäjäkokemusta (eritoten peleissä).
Sinänsähän JIT-käännöksellä saadaan ainakin teoriassa suorituskykyetua esikäännettyihin ohjelmiin. .Netissähän paljon Javan ongelmia on korjattu, käynnistäminen on nopeaa, enkä ainakaan itse XNA Game Studiolla koodatessa ole huomannut Javasta ainakin ennen tutuja roskienkeruusta johtuvia pätkimisiä.
Aihe on jo aika vanha, joten et voi enää vastata siihen.