Java - kaikki netissä pyörivät ohjelmat, palvelin-softat.
0Äänestä
Ash
c/c ! Jos kaipaat ehdotonta tehoa! 3D Pelit ym.. mutta ohjelma pitää kääntää erikseen eri ympäristöille (Linux/Windows/MacOs jne..) ei aina mahdollista jos sovellus tehdään esim. alustapitäen Windowssille (Win32/MFC), mutta onnistuu esim. WxWindows kirjastolla.
Java! Jos saman koodin pitää toimia monessa ympäristössä sellaisenaan! (Windows, Linux MacOS), haittana hiemman hitaampi ei-natiivi sovellus (JAR tiedostot)
Itse tein laskutusohjelman Javalla, jossa sekaisin lähiverkossa PC- että Mac koneita ja Java oli siihen ainut järkevä ratkaisu! Absoluuttinen teho (c ) ei tässä tapauksessa tärkeä!
ei pääse suoraan kiinni koneen resursseihin vaan mennään virtuaalikoneen kautta. Tämä virtuaalikone on siis se kikkare, joka kääntää javan opcoden taas konekohtaiseksi koodiksi.
Tämä väli hidastaa koodin suoritusta ja tehokkuus riippuu paljon virtuaalikoneen fiksuudesta.
0Äänestä
absoluuttinen totuus
Jar tiedosto ei ole suoranaisesti sama kuin ei-natiivi. Jar pääte tarkoittaa sitä, että tiedosto on pakattu(kuten esim zip). Homma menee näin, että java päätteiset tiedostot käännetään class päätteiseksi tiedostoiksi, jotka sisältävät ns. byte-codea, joka ajetaan javan vm:ssä.
0Äänestä
jopas
koska se on yksinkertaisesti nopeampi koodata ja vähemmän virhealtista. Monesti ohjelmien kehitys kestää niin kauan (=kallista), että C :lla saavutettu tehoetu voidaan korvata ostamalla uutta ja tehokkaampaa rautaa projektin lopuksi.
Toki C :lla on omat sovelluksensa, kuten edellä on todettu, mutta Java ei nykyään häviä 'työkäyttöön' tehdyissä ohjelmissa enää juuri ollenkaan, oikeastaan roskien keruu on ainoa Javaa heikentevä tekijä, mutta sitäkin pystyy nykyään käsittääkseni 'käyttäjä' aika hyvin itse hallitsemaan.
0Äänestä
Vapsi
"oikeastaan roskien keruu on ainoa Javaa heikentevä tekijä"
Kuinka niin?
0Äänestä
ansoluuttinenTotuus
0Äänestä
jopas
Vapsi kirjoitti:
"oikeastaan roskien keruu on ainoa Javaa heikentevä tekijä"
Kuinka niin?
Koska se virtuaalikone kääntää sen koodin nykyään todella tehokkaasti ja kuluttaa nykyisten koneen tehoista korkeintaan pari prosenttia. Käännetty koodi on kriittisiltä osiltaan natiivia konekieltä, jolloin sen suoritus ei käytännössä eroa esim. C-kielen käännetystä koodista ollenkaan. Tietorakenteissa tai vastaavissa töissä ei Java häviä käytännössä ollenkaan C/C :lle, graafiset toteutukset sen sijaan ovat Javalla ainakin toistaiseksi selkeästi hitaampi, johtuen pitkälti alusta riippumattomuuden monista rajapinnoista.
0Äänestä
jopas
ansoluuttinenTotuus kirjoitti:
sen ainakin voi itse käskyttää, esim. ennen kriittistä kohtaa ja käsittääkseni sen toiminnan voi myös estää.. en nyt ole kyllä varma onko esto jo nykyisessä versiossa, mutta muistelen lukeneeni, että olisi ainakin tulossa.
0Äänestä
absolluuttinenTotuus
jopas kirjoitti:
sen ainakin voi itse käskyttää, esim. ennen kriittistä kohtaa ja käsittääkseni sen toiminnan voi myös estää.. en nyt ole kyllä varma onko esto jo nykyisessä versiossa, mutta muistelen lukeneeni, että olisi ainakin tulossa.
Tämähän alkaa kuulostamaan mielenkiintoiselta. Lause " you cannot force the garbage collector to run" löytyy väittääkseni jokaisesta javan perusteita käsittelevästä julkaisusta. Voit tietysti pyytää sanomalla "System.gc()" roskien keruuta, mutta mitään takeita ei ole siitä että se tehdään. Pyytäminen ei mielestäni kuitenkaan ole hallitsemista (ehkä tässä lähden nyt liikaa viilaamaan pilkkua).
Mutta roskien keruun estäminen kuulostaa jo aika eksoottiselta. Voisitko laittaa jokin referenssin, täytyy tutustua
0Äänestä
absoluuttinenTotuus
jopas kirjoitti:
Koska se virtuaalikone kääntää sen koodin nykyään todella tehokkaasti ja kuluttaa nykyisten koneen tehoista korkeintaan pari prosenttia. Käännetty koodi on kriittisiltä osiltaan natiivia konekieltä, jolloin sen suoritus ei käytännössä eroa esim. C-kielen käännetystä koodista ollenkaan. Tietorakenteissa tai vastaavissa töissä ei Java häviä käytännössä ollenkaan C/C :lle, graafiset toteutukset sen sijaan ovat Javalla ainakin toistaiseksi selkeästi hitaampi, johtuen pitkälti alusta riippumattomuuden monista rajapinnoista.
Joo, mutta mikä tekee roskien keruusta heikkouden? Itse pitäisin sitä vahvuutena. Tarkoitatko kenties sitä, että et voi itse määrätä milloin se tehdään?
0Äänestä
jopas
absoluuttinenTotuus kirjoitti:
Joo, mutta mikä tekee roskien keruusta heikkouden? Itse pitäisin sitä vahvuutena. Tarkoitatko kenties sitä, että et voi itse määrätä milloin se tehdään?
toiminto ja koko systeemi on lukossa sen suorituksen ajan. Yleensä pienillä ohjelmilla sitä ei juurikaan huomaa, mutta isommilla.. Zzz
0Äänestä
jopas
absolluuttinenTotuus kirjoitti:
Tämähän alkaa kuulostamaan mielenkiintoiselta. Lause " you cannot force the garbage collector to run" löytyy väittääkseni jokaisesta javan perusteita käsittelevästä julkaisusta. Voit tietysti pyytää sanomalla "System.gc()" roskien keruuta, mutta mitään takeita ei ole siitä että se tehdään. Pyytäminen ei mielestäni kuitenkaan ole hallitsemista (ehkä tässä lähden nyt liikaa viilaamaan pilkkua).
Mutta roskien keruun estäminen kuulostaa jo aika eksoottiselta. Voisitko laittaa jokin referenssin, täytyy tutustua
koitin nopeesti etsiä aiheeseen liittyvää juttua, mutta eipä tullut vastaan.. Muistaakseni homma liittyi johonkin tulevaan tai jo olemassa olevaan critical section juttuun, koskien natiivien osien ajamista. Critical section olisi kaiketi saman tyyppinen kuin synchronized aluekin ja jos joku on critical sectionissa, niin sitten GC:tä ei ajeta.
GC:n kutsuminen käytännössä ajaa sen heti ja time critical hommissa sitä pitäisi kutsua "jatkuvasti", se vie hieman tehoja, mutta silloin ei tule mitään pidempää lagia.
Tällainen löytyi kuitenkin (linkki alla), en tiedä koska on kirjoitettu, mutta tuossa juuri todetaan, että GC:n kontrolloiminen ei ole mahdollista, mutta siinä esitetään juuri tapoja miten pitäisi voida pystyä estämään GC:n ajo tietyissä tapauksissa. Muistaisin lukeneeni jostain jo aikaisemmin saman suuntaisia juttua, että kyllä SUN varmaan asian eteen jotain on miettinyt. En ole ihan perillä Javan nykytilasta, joten siksi pistin vain arvioita, että GC:tä pitäisi pystyä jo itsekin vähän säätämään..
Vastaukset 14
Vanhimmat
Täl hetkel
C - raskaat työpöytä-ohjelmat, 3D pelit.
Java - kaikki netissä pyörivät ohjelmat, palvelin-softat.
c/c ! Jos kaipaat ehdotonta tehoa! 3D Pelit ym.. mutta ohjelma pitää kääntää erikseen eri ympäristöille (Linux/Windows/MacOs jne..) ei aina mahdollista jos sovellus tehdään esim. alustapitäen Windowssille (Win32/MFC), mutta onnistuu esim. WxWindows kirjastolla.
Java! Jos saman koodin pitää toimia monessa ympäristössä sellaisenaan! (Windows, Linux MacOS), haittana hiemman hitaampi ei-natiivi sovellus (JAR tiedostot)
Itse tein laskutusohjelman Javalla, jossa sekaisin lähiverkossa PC- että Mac koneita ja Java oli siihen ainut järkevä ratkaisu! Absoluuttinen teho (c ) ei tässä tapauksessa tärkeä!
"haittana hiemman hitaampi ei-natiivi sovellus (JAR tiedostot)"
Mitä toi meinaa?
ei pääse suoraan kiinni koneen resursseihin vaan mennään virtuaalikoneen kautta. Tämä virtuaalikone on siis se kikkare, joka kääntää javan opcoden taas konekohtaiseksi koodiksi.
Tämä väli hidastaa koodin suoritusta ja tehokkuus riippuu paljon virtuaalikoneen fiksuudesta.
Jar tiedosto ei ole suoranaisesti sama kuin ei-natiivi. Jar pääte tarkoittaa sitä, että tiedosto on pakattu(kuten esim zip).
Homma menee näin, että java päätteiset tiedostot käännetään class päätteiseksi tiedostoiksi, jotka sisältävät ns. byte-codea, joka ajetaan javan vm:ssä.
koska se on yksinkertaisesti nopeampi koodata ja vähemmän virhealtista. Monesti ohjelmien kehitys kestää niin kauan (=kallista), että C :lla saavutettu tehoetu voidaan korvata ostamalla uutta ja tehokkaampaa rautaa projektin lopuksi.
Toki C :lla on omat sovelluksensa, kuten edellä on todettu, mutta Java ei nykyään häviä 'työkäyttöön' tehdyissä ohjelmissa enää juuri ollenkaan, oikeastaan roskien keruu on ainoa Javaa heikentevä tekijä, mutta sitäkin pystyy nykyään käsittääkseni 'käyttäjä' aika hyvin itse hallitsemaan.
"oikeastaan roskien keruu on ainoa Javaa heikentevä tekijä"
Kuinka niin?
Koska se virtuaalikone kääntää sen koodin nykyään todella tehokkaasti ja kuluttaa nykyisten koneen tehoista korkeintaan pari prosenttia. Käännetty koodi on kriittisiltä osiltaan natiivia konekieltä, jolloin sen suoritus ei käytännössä eroa esim. C-kielen käännetystä koodista ollenkaan.
Tietorakenteissa tai vastaavissa töissä ei Java häviä käytännössä ollenkaan C/C :lle, graafiset toteutukset sen sijaan ovat Javalla ainakin toistaiseksi selkeästi hitaampi, johtuen pitkälti alusta riippumattomuuden monista rajapinnoista.
sen ainakin voi itse käskyttää, esim. ennen kriittistä kohtaa ja käsittääkseni sen toiminnan voi myös estää.. en nyt ole kyllä varma onko esto jo nykyisessä versiossa, mutta muistelen lukeneeni, että olisi ainakin tulossa.
Tämähän alkaa kuulostamaan mielenkiintoiselta. Lause " you cannot force the garbage collector to run" löytyy väittääkseni jokaisesta javan perusteita käsittelevästä julkaisusta. Voit tietysti pyytää sanomalla "System.gc()" roskien keruuta, mutta mitään takeita ei ole siitä että se tehdään. Pyytäminen ei mielestäni kuitenkaan ole hallitsemista (ehkä tässä lähden nyt liikaa viilaamaan pilkkua).
Mutta roskien keruun estäminen kuulostaa jo aika eksoottiselta. Voisitko laittaa jokin referenssin, täytyy tutustua
Joo, mutta mikä tekee roskien keruusta heikkouden? Itse pitäisin sitä vahvuutena. Tarkoitatko kenties sitä, että et voi itse määrätä milloin se tehdään?
toiminto ja koko systeemi on lukossa sen suorituksen ajan. Yleensä pienillä ohjelmilla sitä ei juurikaan huomaa, mutta isommilla.. Zzz
koitin nopeesti etsiä aiheeseen liittyvää juttua, mutta eipä tullut vastaan.. Muistaakseni homma liittyi johonkin tulevaan tai jo olemassa olevaan critical section juttuun, koskien natiivien osien ajamista. Critical section olisi kaiketi saman tyyppinen kuin synchronized aluekin ja jos joku on critical sectionissa, niin sitten GC:tä ei ajeta.
GC:n kutsuminen käytännössä ajaa sen heti ja time critical hommissa sitä pitäisi kutsua "jatkuvasti", se vie hieman tehoja, mutta silloin ei tule mitään pidempää lagia.
Tällainen löytyi kuitenkin (linkki alla), en tiedä koska on kirjoitettu, mutta tuossa juuri todetaan, että GC:n kontrolloiminen ei ole mahdollista, mutta siinä esitetään juuri tapoja miten pitäisi voida pystyä estämään GC:n ajo tietyissä tapauksissa. Muistaisin lukeneeni jostain jo aikaisemmin saman suuntaisia juttua, että kyllä SUN varmaan asian eteen jotain on miettinyt. En ole ihan perillä Javan nykytilasta, joten siksi pistin vain arvioita, että GC:tä pitäisi pystyä jo itsekin vähän säätämään..
http://cdsmith.twu.net/professional/java/pontifications/gc.html