Mikä lämmittää?

[anander]

Mistähän tämä Fortran hmmm... perversio oikein tulee muutenkaan, lienee sellaista historiallista perinnettä, ja ettei näihin ympyröihin päätyvät tutkijat yleensä tunne mitään muuta kieltä. No, se on sinänsä sivuseikka, tuloksethan ne ratkaiseee."

However, unlike C and C++, Fortran 90 is designed to generate executable codes that are highly optimized and thus run extremely fast.

http://www.lahey.com/PRENTICE.HTM

Tuo juttusi oli vuodelta 1995, ts. 16 vuotta vanha. Siitä on menty "hieman" eteenpäin paitsi laskentatehossa kääntämistekniikassa.Löytyykös asiasta jotain ihan oikeatakin tietoa kuin 1995 jonkun fyysikon kirjoittama väite ja/tai onko sinulla tästä jotain omakohtaista sanottavaa?

Uskallanpa väittää, ettei (hyvin kirjoitettu ja jollain modernilla kääntäjällä käännetty) esim. massiivisia liukulukumatriiseja pyörittelevä C-ohjelma jää missään olosuhteissa vastaavia laskentoja tekevän Fortran-ohjelman jalkoihin suorituskykymielessä, ja myös esim. C++:ssa (lähinnä kehittyneempien ominaisuuksien takia syntyvää) lähinnä muistinkäytöllistä overheadia voi myös välttää, jos tietää mitä tekee. Ja on niitä muitakin kieliä... Rinnakkaistamisen helpottaminen on yksi argumentti, mutta kyllä sen tekeminen esim. säikeistämällä on helppoa näillä "ihan oikeillakin" ohjelmointikielillä, joihin nyt tätä Fortrania, oikein mitään sen versiota, ei ohjelmistoalalla yleensä lasketa. Milloinkas on Fortrania viimeksi jotenkin muutettu tai kääntäjiä merkittävästi parannettu? Niinpä niin.

Tottakai - asiaan palatakseni jos se (jokin ohjelmointikieli X) täyttää tarpeet, niin mikäs siinä, mutta kyllä se vähintäänkin jonkinasteista masokismia implikoi, jos sillä (F90) mitään monimutkaisempaa alkaa pykäämään. Vähän siinä on samaa kuin tietojenkäsittelypuolen vanhojen partojen onneksi jo historiaan siirtyvässä Coboliin ripustautumisessa.

[Hezaurus]

Tuo juttusi oli vuodelta 1995, ts. 16 vuotta vanha. Siitä on menty "hieman" eteenpäin paitsi laskentatehossa kääntämistekniikassa.Löytyykös asiasta jotain ihan oikeatakin tietoa kuin 1995 jonkun fyysikon kirjoittama väite ja/tai onko sinulla tästä jotain omakohtaista sanottavaa?

Uskallanpa väittää, ettei (hyvin kirjoitettu ja jollain modernilla kääntäjällä käännetty) esim. massiivisia liukulukumatriiseja pyörittelevä C-ohjelma jää missään olosuhteissa vastaavia laskentoja tekevän Fortran-ohjelman jalkoihin suorituskykymielessä, ja myös esim. C++:ssa (lähinnä kehittyneempien ominaisuuksien takia syntyvää) lähinnä muistinkäytöllistä overheadia voi myös välttää, jos tietää mitä tekee. Ja on niitä muitakin kieliä... Rinnakkaistamisen helpottaminen on yksi argumentti, mutta kyllä sen tekeminen esim. säikeistämällä on helppoa näillä "ihan oikeillakin" ohjelmointikielillä, joihin nyt tätä Fortrania, oikein mitään sen versiota, ei ohjelmistoalalla yleensä lasketa. Milloinkas on Fortrania viimeksi jotenkin muutettu tai kääntäjiä merkittävästi parannettu? Niinpä niin.

Melko noloa viitata ohjelmointialalla 16 vuotta vanhoihin juttuihin silloin kun puhutaan suorituskyvystä.
Jopa java on tänään riittävän nopea ollakseen ihan yhtä hyvä valinta matemaattiseen mallinnukseen kuin Fortran. Tärkeintähän noissa on nykyään massiivinen rinnakkaisuus ja siinä tärkeintä itse toteutustapa eikä toteutuskieli.
Jokainen kieli asettaa omat rajoituksensa, mutta tuo mukanaan myös omat vahvuutensa. Javan ja C++:n suurimpia vahvuuksia ovat ennenkaikkea se että osaajien pooli on hieman isompi kuin Fortranilla ja kummallakin kielellä voi käsitellä lähes mitä tahansa ongelmia yhtä sujuvasti/hankalasti..

Oma erikoisosaamiseni liittyy OLAP tyyppiseen tiedon käsittelyyn ja esitystapaan pääosin teollisessa ympäristössä toimivan ohjelmiston (PLIM) suunnittelijana.
Kaikki hitausongelmat liittyvät IO:hon ja kielen valinta tehdään ihan jollain muulla perusteella kuin 'silloin joskus'.

Funktionaaliset kielet lähestyvät suorituskyvyssä kovaa vauhtia ja niiden todella toivoisin yleistyvän tulevaisuudessa. Suosikkinani niistä Scala.

[Lorentz3]

Jopa java on tänään riittävän nopea ollakseen ihan yhtä hyvä valinta matemaattiseen mallinnukseen kuin Fortran. Tärkeintähän noissa on nykyään massiivinen rinnakkaisuus ja siinä tärkeintä itse toteutustapa eikä toteutuskieli.

Onko tästä jossakin uudehdoja linkkejä? Olen ymmärtänyt että mm. kompleksilukujen natiivituen puuttuminen Javasta aiheuttaa jonkin verran harmia. Hyvin koodattu Java-koodi näyttää pärähtävän kätevästi moniydinprossujen kaikille ytimille eli siinä suhteessa rinnakkaisuus toimii.

[anander]

Ohjelmointikielen natiivityyppinä kompleksilukuja ei suurimassa osassa ohjelmointikieliä ole, olkoonkin että niiden implementointi on kyllä aika helppoa, ja yleisimpiin kieliin löytyy hyvät viitetoteutukset, kuten Javalle. Mm. Java vs. jokin muu benchmarkkivertailuja löytyy webin periltä kovasti, tosin niissä uppoaa helposti eri virtuaalikone/käyttöjärjestelmäkombinaatioiden suohon. Joka tapauksessa tulkkausoverhead ei ole ollenkaan sitä mitä vielä 90-luvun puolissa välissä vrt. natiivibinääreiksi käännetyt kielet, ja lähtökohtaisesti uskallan epäillä josko tuolla Fortranilla on ollut mitään etua esim. C/C++:aan silloinkaan...

Suorityskyvyn kannaltahan "natiivi" ei tarkoita prosessoritason tukea asialle, kuten liukuluvuille on, eli joka tapauksessa niiden käsittely perustuu ohjelmistoihin, joten epäillä sopii, josko näistäkään eroa tulisi.

[Lorentz3]

Joo no toivotaan että Java soveltuu tieteelliseen laskentaan, parin vuoden päästä suurimmat datafileet ovat 16Gigabyyttiä tsibaleelta ja niitä pitäisi pystyä käsittelemään suhtkoht normaalisti ilman että systeemi menee täysin polvilleen.

[anander]

Mistä datasetistä puhut? Onko tämän nimenomaisen datasetin käsittelyyn laadittu Javalla jonkinlainen laskentasovellus? Paljonko käytettävissä on muistia? EI ole ylipäätään mitään erikoista syystä minkä takia ohjelmointikieleen X tehty abtraktio kompleksiluvulle olisi muistinkäytön kannalta jotenkin parempi, kuin ohjelmointikielellä Y. Tiedossani ei ole myöskään yhtään prosessoriarkkitehtuuria, missä olisi jotain kompleksilukulaskentaa piillä. Liukulukuja sitten kyllä.

Kaksi lukuahan esim. näihin kompleksilukuihin tarvitaan ja niiden esitystarkkuudesta riippuu muistintarve. Ja sekin voi olla samalla ohjelmointikielellä erilainen eri laitealustoilla. Tietysti jos niille vääntää oliokuorruttimen päälle / komplekiluku, niin muistintarve kyllä kasvanee kertoimella 2-3, mutta ei sitäkään ole pakko niin tehdä.

[juakola]

Mä en tiedä kuinka isoja datasettejä velipojalla on (ei luullakseni edes isoja), mutta jokatapauksessa supertietokoneet laskee parhaimmillaan viikkokausia niitä laskuja... Ei taida kuitenkaan olla niinkään filun koosta kiinni eikä siitä kuinka monta niitä on, vaan täysin siitä mitä niille ollaan tekemässä.
(esimerkkinä siirsin juuri 8Gb dataa kovalevyltä toiselle. Ei mennyt kuin alle kaksi minuuttia.)

Ja heti kun joku rakentaa uuden, ennennäkemättömän nopean supertietokoneen, niin ohjelmointikielestä huolimatta jollakin on jo valmiina laskut millä pistää koneen polvilleen.

[anander]

Mä en tiedä kuinka isoja datasettejä velipojalla on (ei luullakseni edes isoja), mutta jokatapauksessa supertietokoneet laskee parhaimmillaan viikkokausia niitä laskuja... Ei taida kuitenkaan olla niinkään filun koosta kiinni eikä siitä kuinka monta niitä on, vaan täysin siitä mitä niille ollaan tekemässä.
(esimerkkinä siirsin juuri 8Gb dataa kovalevyltä toiselle. Ei mennyt kuin alle kaksi minuuttia.)

Ja heti kun joku rakentaa uuden, ennennäkemättömän nopean supertietokoneen, niin ohjelmointikielestä huolimatta jollakin on jo valmiina laskut millä pistää koneen polvilleen.

Laskentaresoluutiollahan ei tavallaan ole ylärajaa, ja aina voi tuoda lisää vapausasteita. Kaikki koneteho on aina osattu käyttää.

[Tapsa]

Aika reippaasti off topic menee nyt tarinointi.

[juakola]

Aika reippaasti off topic menee nyt tarinointi.

Ainahan se täällä menee .

[Lorentz3]

Mistä datasetistä puhut? Onko tämän nimenomaisen datasetin käsittelyyn laadittu Javalla jonkinlainen laskentasovellus? Paljonko käytettävissä on muistia? EI ole ylipäätään mitään erikoista syystä minkä takia ohjelmointikieleen X tehty abtraktio kompleksiluvulle olisi muistinkäytön kannalta jotenkin parempi, kuin ohjelmointikielellä Y. Tiedossani ei ole myöskään yhtään prosessoriarkkitehtuuria, missä olisi jotain kompleksilukulaskentaa piillä. Liukulukuja sitten kyllä.

Kaksi lukuahan esim. näihin kompleksilukuihin tarvitaan ja niiden esitystarkkuudesta riippuu muistintarve. Ja sekin voi olla samalla ohjelmointikielellä erilainen eri laitealustoilla. Tietysti jos niille vääntää oliokuorruttimen päälle / komplekiluku, niin muistintarve kyllä kasvanee kertoimella 2-3, mutta ei sitäkään ole pakko niin tehdä.

Satelliittikuvia, Javasofta löytyy ja toimii ihan ok nykyisten puolen gigabyytin kuvien kanssa, vaikea arvioida mitä 16Gigabyytissä tapahtuu mutta tosiaan jo pelkkä kuvan lukeminen täydessä resoluutiossa vie sen verran aikaa että ilman fiksumpia ratkaisuja sulavan skrollauksen ja zoomauksen saa unohtaa. Muistin "pitäisi" riittää koska kuvat prosessoidaan 512x512 pikselin tiilissä eli 16Gb ei tarvitse lukea muistiin kerralla.

[Tapsa]

Mitä jos tutustuisit itse malleihin, vaikka tähän? Vai kiinnostaako journalismi enemmän?

http://oceans11.lanl.gov/trac/CICE

Moneen kertaan on huomautettu linkkaustyylistäsi, mutta sama jatkuu. Kaiva itse siitä tarkoittamasi kohta ja kopioi tänne tai ainakin tarkenna tuota linkkiäsi reippaasti pitemmälle. Tuosta kun tulee väkisinkin mieleen, että et ole itse tutustunut koko lähteeseen.

Siis hetkinen, olet keksinyt täysin omasta päästäsi ja asiaan syvällisesti tutustumatta että malleissa joku asia on pielessä. Ei kai tästä taustatutkimuksesi puutteista seuraa että jonkun toisen pitäisi tehdä selvitystyö puolestasi? Käyttöohjeet ovat täällä, siellä selitetään mitä mallissa tehdään ja miten se kytkeytyy muihin osamalleihin. Säteily on näköjään huomioitu, mikä ei ole mikään yllätys:

http://oceans11.lanl.gov/trac/CICE/atta ... format=raw

Ei vaan löydy mitään konkreettista ulos lähtevän säteilyn intensiteetistä, toisin kuin albedosta löytyy oikein käppyröitäkin. Vaatisi tietenkin aikamoista paneutumista, lähdeaineistoa myöten, että pääsisi kunnon käsitykseen. Jään paksuus tuossa näyttää olevan pääasiallinen tutkimuskohde. Ei vakuuta, kun et pysty antamaan mitään tarkkaa kohtaa, mistä pointti löytyy.

[Lorentz3]

Ei vaan löydy mitään konkreettista ulos lähtevän säteilyn intensiteetistä, toisin kuin albedosta löytyy oikein käppyröitäkin. Vaatisi tietenkin aikamoista paneutumista, lähdeaineistoa myöten, että pääsisi kunnon käsitykseen. Jään paksuus tuossa näyttää olevan pääasiallinen tutkimuskohde. Ei vakuuta, kun et pysty antamaan mitään tarkkaa kohtaa, mistä pointti löytyy.

Eli ei ole olemassa mitään todisteita siitä että jäämallinnuksesta olisi unohtunut jotain, paitsi yksisilmäinen tiedejournalismi?

[Tapsa]

Ei vaan löydy mitään konkreettista ulos lähtevän säteilyn intensiteetistä, toisin kuin albedosta löytyy oikein käppyröitäkin. Vaatisi tietenkin aikamoista paneutumista, lähdeaineistoa myöten, että pääsisi kunnon käsitykseen. Jään paksuus tuossa näyttää olevan pääasiallinen tutkimuskohde. Ei vakuuta, kun et pysty antamaan mitään tarkkaa kohtaa, mistä pointti löytyy.

Eli ei ole olemassa mitään todisteita siitä että jäämallinnuksesta olisi unohtunut joptain, paitsi yksisilmäinen tiedejournalismi?

Näinkin voi sanoa, mutta todisteita ei löydy kumpaankaan suuntaan.

[Lorentz3]

Eli ei ole olemassa mitään todisteita siitä että jäämallinnuksesta olisi unohtunut joptain, paitsi yksisilmäinen tiedejournalismi?

Näinkin voi sanoa, mutta todisteita ei löydy kumpaankaan suuntaan.

Ei tässä keskustelussa, mutta ei ole mitään syytä olettaa että jotain simppeliä efektiä ei olisi ehditty ottaa mukaan vuosikymmenten tutkimustyön aikana.