.NET on tulevaisuus

Taas aletaan veivaamaan tätä Java vs. NET / Sun vs Microsoft. Pitäisi jo tässä vaiheessa tajuta että molempi parempi. Aiemmin asia oli isompi ongelma kun eri ohjelmistoalustat eivät pystyneet kunnolla keskustelemaan toistensa kanssa, tähänkin on viimeinkin saatu jonkunlainen ratkaisu WebServices -tekniikalla. Loppupeleissä ihan sama mikä kieli tai tekniikka kunhan se sopii itselle.

Totta että Java oli ensin, mutta mikäs virtuaalikone niistä n 1:stä on paras ?

.NET on jo nyt vakiinnuttanut asemansa ohjelmointiympäristönä ja ohjelmoinnin välineenä.

Mitä .NET Passport -kirjautumisjärjestelmään tulee, suosion esteenä ei ollut suinkaan sen toimivuus, vaan suolainen n. $11 500 (minimi) vuosimaksu, joka oli suurimmalle osalle aivan liian korkea. Se oli siis selkeästi tähdätty miljoonavoittoja tahkoaville yrityksille, eikä "nappikauppiaille", joita netti on väärällään.

BVCX kirjoitti:

.NET on jo nyt vakiinnuttanut asemansa ohjelmointiympäristönä ja ohjelmoinnin välineenä.

Mitä .NET Passport -kirjautumisjärjestelmään tulee, suosion esteenä ei ollut suinkaan sen toimivuus, vaan suolainen n. $11 500 (minimi) vuosimaksu, joka oli suurimmalle osalle aivan liian korkea. Se oli siis selkeästi tähdätty miljoonavoittoja tahkoaville yrityksille, eikä "nappikauppiaille", joita netti on väärällään.

Lue lisää

Kukahan sitä tarvii?

Saako sillä jotain etua (missään suhteessa mihinkään) Ne .Net ohjelmat joita olen nähnyt on surkeita (mutta kerro jos jotain hyviä olisi)!

mina kirjoitti:

Kukahan sitä tarvii?

Saako sillä jotain etua (missään suhteessa mihinkään) Ne .Net ohjelmat joita olen nähnyt on surkeita (mutta kerro jos jotain hyviä olisi)!

Sen hienous onkin siinä, että sillä kukin voi tehdä itse juuri sellaiset ja juuri niin hyvät ohjelmat kuin haluaa, niin ettei tarvitse tuskailla "huonojen" valmisohjelmien kanssa.

NBXC kirjoitti:

Sen hienous onkin siinä, että sillä kukin voi tehdä itse juuri sellaiset ja juuri niin hyvät ohjelmat kuin haluaa, niin ettei tarvitse tuskailla "huonojen" valmisohjelmien kanssa.

Lue lisää

Niin mitä hyötyä .Netistä!

Vastaavia ohjelmia voi tehdä myös muilla välineillä
(paremmilla)!

kysyjä_ kirjoitti:

Niin mitä hyötyä .Netistä!

Vastaavia ohjelmia voi tehdä myös muilla välineillä
(paremmilla)!

Millä välineillä ja millä tavoin paremmilla?

kysyjä_ kirjoitti:

Niin mitä hyötyä .Netistä!

Vastaavia ohjelmia voi tehdä myös muilla välineillä
(paremmilla)!

Väärin. Vastaavia ohjelmia ei voi tehdä muilla kääntäjillä, siis perinteisillä. Perinteiset ohjelmakääntäjät tuottavat vain tietylle suoritinperheelle soveltuvaa koodia, esim. i586. Perinteisen kääntäjän koodi ei siis sellaisenaan huomioi uusien prosessorimallien erityispiirteitä. .Net sen sijaan osaa huomioida esim. P4:n erityisominaisuudet ja pystyy hyödyntämään prosessorin tehoa paremmin.

Lisäksi koodi on turvallisempaa koska muistin puskuriylivuodot on estetty. CLR myös tutkii suorittimelle lähetettävän koodin eikä salli turvatonta koodia (oletusarvoisesti) ellei sitä pakoteta.

Muistinhallinta on muutenkin helpompaa koska ohjelmissa on sisäänrakennettu garbage collector joka siivoa tarpeettomat tiedot muistista automaattisesti.

Jos jotakin huonoa haluaa .Net-ohjelmista löytää on periaatteellinen hitaus mikä aiheutuu CLR:n tutkiessa ja tulkitessa IL-välikoodin prosessorille. Ironista kyllä se saattaa myös nopeuttaa ohjelmaa koska CLR osaa hyödyntää suorittimen ominaisuuksia. Sitäpaitsi CLR tulkkaa kunkin metodikutsun vain kerran ja tallentaa sen muistiin prossukoodina josta se tämän jälkeen on suoraan ajettavissa kääntämättä. Myös dynaamista muistia .Net-ohjelmat kuluttavat enemmän koska kaikki tallennetaan dynaamiseen muistiin mutta tämä ei nykykoneissa ole juurikaan ongelma.

Luonnollisesti, huonosti suunnitellulla ja toteutetulla ohjelmoinnilla voidaan pilata mikä tahansa ohjelma kielestä ja alustasta riippumatta.

vielä kirjoitti:

Millä välineillä ja millä tavoin paremmilla?

Esim. jos vertaat Lazarukseen tai muihin graafisiin ohjelmankehitysvälineisiin (jätetään vaikka .Net kehittimet pois)!

En minä ole ainakaan mitään hyvää syytä nähnyt .Netissä (vaikka Haukilehto vai kuka se nyt oli. on paasannut jo vuosikausia)

exergy kirjoitti:

Väärin. Vastaavia ohjelmia ei voi tehdä muilla kääntäjillä, siis perinteisillä. Perinteiset ohjelmakääntäjät tuottavat vain tietylle suoritinperheelle soveltuvaa koodia, esim. i586. Perinteisen kääntäjän koodi ei siis sellaisenaan huomioi uusien prosessorimallien erityispiirteitä. .Net sen sijaan osaa huomioida esim. P4:n erityisominaisuudet ja pystyy hyödyntämään prosessorin tehoa paremmin.

Lisäksi koodi on turvallisempaa koska muistin puskuriylivuodot on estetty. CLR myös tutkii suorittimelle lähetettävän koodin eikä salli turvatonta koodia (oletusarvoisesti) ellei sitä pakoteta.

Muistinhallinta on muutenkin helpompaa koska ohjelmissa on sisäänrakennettu garbage collector joka siivoa tarpeettomat tiedot muistista automaattisesti.

Jos jotakin huonoa haluaa .Net-ohjelmista löytää on periaatteellinen hitaus mikä aiheutuu CLR:n tutkiessa ja tulkitessa IL-välikoodin prosessorille. Ironista kyllä se saattaa myös nopeuttaa ohjelmaa koska CLR osaa hyödyntää suorittimen ominaisuuksia. Sitäpaitsi CLR tulkkaa kunkin metodikutsun vain kerran ja tallentaa sen muistiin prossukoodina josta se tämän jälkeen on suoraan ajettavissa kääntämättä. Myös dynaamista muistia .Net-ohjelmat kuluttavat enemmän koska kaikki tallennetaan dynaamiseen muistiin mutta tämä ei nykykoneissa ole juurikaan ongelma.

Luonnollisesti, huonosti suunnitellulla ja toteutetulla ohjelmoinnilla voidaan pilata mikä tahansa ohjelma kielestä ja alustasta riippumatta.

Lue lisää

Eli se mitä minä muista kielistä / ympäristöistä tiedän eipä tuossa viestissä ole tullut paljon mitään hyvää.

Sinun kannattaisi miettiä ja tutkia muita järjestelmiä (ettei ihan kaikkea ****** "syötetä suuhun").

Muuten montaako eri prosessoria .Net tukee tällä hetkellä? (Voit miettiä montaako eri käyttöjärjestelmää myös?)

exergy kirjoitti:

Väärin. Vastaavia ohjelmia ei voi tehdä muilla kääntäjillä, siis perinteisillä. Perinteiset ohjelmakääntäjät tuottavat vain tietylle suoritinperheelle soveltuvaa koodia, esim. i586. Perinteisen kääntäjän koodi ei siis sellaisenaan huomioi uusien prosessorimallien erityispiirteitä. .Net sen sijaan osaa huomioida esim. P4:n erityisominaisuudet ja pystyy hyödyntämään prosessorin tehoa paremmin.

Lisäksi koodi on turvallisempaa koska muistin puskuriylivuodot on estetty. CLR myös tutkii suorittimelle lähetettävän koodin eikä salli turvatonta koodia (oletusarvoisesti) ellei sitä pakoteta.

Muistinhallinta on muutenkin helpompaa koska ohjelmissa on sisäänrakennettu garbage collector joka siivoa tarpeettomat tiedot muistista automaattisesti.

Jos jotakin huonoa haluaa .Net-ohjelmista löytää on periaatteellinen hitaus mikä aiheutuu CLR:n tutkiessa ja tulkitessa IL-välikoodin prosessorille. Ironista kyllä se saattaa myös nopeuttaa ohjelmaa koska CLR osaa hyödyntää suorittimen ominaisuuksia. Sitäpaitsi CLR tulkkaa kunkin metodikutsun vain kerran ja tallentaa sen muistiin prossukoodina josta se tämän jälkeen on suoraan ajettavissa kääntämättä. Myös dynaamista muistia .Net-ohjelmat kuluttavat enemmän koska kaikki tallennetaan dynaamiseen muistiin mutta tämä ei nykykoneissa ole juurikaan ongelma.

Luonnollisesti, huonosti suunnitellulla ja toteutetulla ohjelmoinnilla voidaan pilata mikä tahansa ohjelma kielestä ja alustasta riippumatta.

Lue lisää

>...sisäänrakennettu garbage collector...

Miksei windowsissa ole ?

Kaikille on kovin tuttu ilmoitus "You are running low on virtual memory" tjsp vaikka taskmanagerin mukaan käynnissä olevien sovellutsten "memory usage" ei ole lähelläkään pagefilen ylärajaa. Eikä auta muu kuin bootti.

Tuosta muistuukin mieleen vanha sanonta:" In Linux: Be root, in Windows: Reboot".

---- kirjoitti:

Eli se mitä minä muista kielistä / ympäristöistä tiedän eipä tuossa viestissä ole tullut paljon mitään hyvää.

Sinun kannattaisi miettiä ja tutkia muita järjestelmiä (ettei ihan kaikkea ****** "syötetä suuhun").

Muuten montaako eri prosessoria .Net tukee tällä hetkellä? (Voit miettiä montaako eri käyttöjärjestelmää myös?)

Lue lisää

Enpä lähtisi .NET:iä hitaaksi väittämään. Kyllä siitä vauhtia löytyy jopa pelikäyttöön. Tuolta esimerkiksi voi ladata Quake II:n .NET -version lähdekoodeineen:

http://www.vertigosoftware.com/Quake2.htm

missä? kirjoitti:

Enpä lähtisi .NET:iä hitaaksi väittämään. Kyllä siitä vauhtia löytyy jopa pelikäyttöön. Tuolta esimerkiksi voi ladata Quake II:n .NET -version lähdekoodeineen:

http://www.vertigosoftware.com/Quake2.htm

Lue lisää

>Enpä lähtisi .NET:iä hitaaksi väittämään.

Jos pikkuisenkin riisut MS-rillejä silmiltäsi voisit ehkä ajatella asiaa ihan tekniseltä kannalta. Tulkattava koodi ei voi periaatteessakaan olla yhtä nopeaa kuin natiivi koodi.

siinä kirjoitti:

>Enpä lähtisi .NET:iä hitaaksi väittämään.

Jos pikkuisenkin riisut MS-rillejä silmiltäsi voisit ehkä ajatella asiaa ihan tekniseltä kannalta. Tulkattava koodi ei voi periaatteessakaan olla yhtä nopeaa kuin natiivi koodi.

Lue lisää

"ulkattava koodi ei voi periaatteessakaan olla yhtä nopeaa kuin natiivi koodi. "

Olet oikeassa!!! vaan Javalla kaikki myös samoin...
ja sitä paskaa tungetaan jo joka kolosta...

parempi hyväksyä se tosiasia että .net on ja tulee jäädäkseen tai sitten tehä niinku minä että koodaa vaan c :lla ja ei sitä vaihda...tjms. =)

siinä kirjoitti:

>Enpä lähtisi .NET:iä hitaaksi väittämään.

Jos pikkuisenkin riisut MS-rillejä silmiltäsi voisit ehkä ajatella asiaa ihan tekniseltä kannalta. Tulkattava koodi ei voi periaatteessakaan olla yhtä nopeaa kuin natiivi koodi.

Lue lisää

Mikäli .NET:n nopeus piisaa Quake II:n kaltaisen 3D-pelin toteutukseen, ei ole epäilystäkään etteikö sen suorituskyky riittäisi myös arkipäiväisempiin sovelluksiin.

mainiosti kirjoitti:

Mikäli .NET:n nopeus piisaa Quake II:n kaltaisen 3D-pelin toteutukseen, ei ole epäilystäkään etteikö sen suorituskyky riittäisi myös arkipäiväisempiin sovelluksiin.

" Mikäli .NET:n nopeus piisaa Quake II:n kaltaisen 3D-pelin toteutukseen, ei ole epäilystäkään etteikö sen suorituskyky riittäisi myös arkipäiväisempiin sovelluksiin. "

kannattaa muistaa että quake 2 on jotain 8v. vanha peli!!!
koitas vääntää doom3 tyylinen .NET:illä =)
nojoo saahan sillä muuta väännettyä nopeesti kuten vaikka joku toimisto-ohjelmisto??? mutta ei sillä kyllä pelejä varmaan kannata mennä vääntämään...
(tai ehkä sittenkin???...saadaan myytyä nopeammat koneet vain koska tehoja tarvitaankin koodin "uudelleen ajamiseen")

TSwiGH kirjoitti:

" Mikäli .NET:n nopeus piisaa Quake II:n kaltaisen 3D-pelin toteutukseen, ei ole epäilystäkään etteikö sen suorituskyky riittäisi myös arkipäiväisempiin sovelluksiin. "

kannattaa muistaa että quake 2 on jotain 8v. vanha peli!!!
koitas vääntää doom3 tyylinen .NET:illä =)
nojoo saahan sillä muuta väännettyä nopeesti kuten vaikka joku toimisto-ohjelmisto??? mutta ei sillä kyllä pelejä varmaan kannata mennä vääntämään...
(tai ehkä sittenkin???...saadaan myytyä nopeammat koneet vain koska tehoja tarvitaankin koodin "uudelleen ajamiseen")

Lue lisää

Tuossa on muuten aika mielenkiintoinen, muutamalla eri kääntäjällä käännettyjen ohjelmien suorituskykyä mittaava "benchmark":

http://www.osnews.com/story.php?news_id=5602&page=3

En tietenkään väitä (eikä väitä myöskään testin tekijä), että tuo olisi koko kaiken kattava totuus, mutta yllättävää kuitenkin oli se, että Visual C .NET ja C#.NET käännetyt ohjelmat suoriutuivat samasta tehtävästä huomattavasti nopeammin kuin GNU GCC C-kääntäjällä käännetty ohjelma. C .NET ja GCC käännöksissä käytettiin lisäksi täsmälleen samaa lähdekoodia.

tässä kirjoitti:

Tuossa on muuten aika mielenkiintoinen, muutamalla eri kääntäjällä käännettyjen ohjelmien suorituskykyä mittaava "benchmark":

http://www.osnews.com/story.php?news_id=5602&page=3

En tietenkään väitä (eikä väitä myöskään testin tekijä), että tuo olisi koko kaiken kattava totuus, mutta yllättävää kuitenkin oli se, että Visual C .NET ja C#.NET käännetyt ohjelmat suoriutuivat samasta tehtävästä huomattavasti nopeammin kuin GNU GCC C-kääntäjällä käännetty ohjelma. C .NET ja GCC käännöksissä käytettiin lisäksi täsmälleen samaa lähdekoodia.

Lue lisää

tuossa eijjoo VC 6.0 olleskaan(siis se "netitön")??? sekin jo teki huomattavasti nopeampaa koodia ku gcc =)

tässä kirjoitti:

Tuossa on muuten aika mielenkiintoinen, muutamalla eri kääntäjällä käännettyjen ohjelmien suorituskykyä mittaava "benchmark":

http://www.osnews.com/story.php?news_id=5602&page=3

En tietenkään väitä (eikä väitä myöskään testin tekijä), että tuo olisi koko kaiken kattava totuus, mutta yllättävää kuitenkin oli se, että Visual C .NET ja C#.NET käännetyt ohjelmat suoriutuivat samasta tehtävästä huomattavasti nopeammin kuin GNU GCC C-kääntäjällä käännetty ohjelma. C .NET ja GCC käännöksissä käytettiin lisäksi täsmälleen samaa lähdekoodia.

Lue lisää

>...että tuo olisi koko kaiken kattava totuus...

Ei varmaankaan mutta tuostakin käy ilmi että Java pesee C#:n selvästi jos jätetään tuo trigonometria (sopivasti valittu ?) pois laskelmista.

testeissä kirjoitti:

>...että tuo olisi koko kaiken kattava totuus...

Ei varmaankaan mutta tuostakin käy ilmi että Java pesee C#:n selvästi jos jätetään tuo trigonometria (sopivasti valittu ?) pois laskelmista.

Lue lisää

Trigonometria olisi siis pitänyt jättää testaamatta kokonaan siksi koska Java 1.4.2 ei pärjää siinä edes Pythonille, niinkö?

Aivan samalla tavalla VB- ja J# -käyttäjät voisivat inistä kuinka epäreilua oli testata I/O -nopeutta ja Python-käyttäjät puolestaan voisivat väittää testiä puolueelliseksi, koska siinä oli testattu pelkän I/O -nopeuden lisäksi laskutoimitusten kaltaisia "epäoleellisuuksia".

On varmaan mahdotonta tehdä testiä joka olisi kaikkien mielestä puolueeton ja reilu. Aina löytyy niitä, joka kyseenalaistavat (tosin vain itselleen epäedulliset) tulokset... siitäkin huolimatta että koodit ovat luettavissa ja imuroitavissa niin että ne voi ajaa vaikka omalla koneella.

En edelleenkään väitä .NET -koodin olevan suorituskyvyltään täysin tasoissa natiivin C-koodin kanssa, mutta ainakin tämä testi osoittaa että puheet .NET (kuten myös Java) sovellusten toivottomasta HITAUDESTA voidaan jättää niille kuuluvaan olemattomaan arvoonsa, etenkin kun tämän testin C# ja C .NET ja Java (trigonometriaa lukuun ottamatta) pesivät GCC:n natiivikääntäjän. Vaikka GCC onkin ilmainen "open source" kyhäelmä ja parempiakin C/C -kääntäjiä varmasti on, niin voisi helposti kuvitella että olisivat 17-18 vuoden aikana saaneet GCC:n siihen kuntoon että sen kääntämä koodi olisi KAIKKEA "puolitulkattua" .NET ja Java -koodia selvästi nopeampaa. "natiivi C-koodi on nopeinta" -totuus ei siis ainakaan tässä tapauksessa pidä alkuunkaan paikkaansa.

Kuitenkin loppupeleissä ohjelman suorituskyvyn yleensä ratkaisee koodaajan osaaminen ja kuinka sovellus on toteutettu/optimoitu, mitä kolmansien osapuolten kirjastoja ja tuotteitä käytetään (ja miten) eikä suinkaan käytetyn kielen nopeus sekä eri kielten merkityksettömät ja lähinnä teoreettiset nopeuserot. Ainakaan itselle ei ole ikinä tullut vastaan sellaista tilannetta jossa ohjelmointikielen laskentanopeus olisi ollut ongelma ja että käytetty ohjelmointikieli olisi "liian hidas", vaan suorituskyvyn pullonkaulat ovat löytyneet aina aivan muualta silloin kun niitä on ollut.