Koneella voidaan ajaa montaa javascriptiä yhtäaikaa, s.e. kutakin ajetaan omalla corellaan / coreillaan. Ja jos JAVA on niin täyttä sontaa, ettei se mitenkään säikeisty, niin kun ottaa huomioon koneiden kehitysuunnan, niin siitä tullaan sitten luopumaan tässä jossain vaiheessa, sehän on täysin pakkorako.
Java säikeistyy oikein hyvin.
Mutta ei tässä olla puhuttu yhtään mitään Javasta, vaan Javasciptistä, ne ovat kaksi
täysin eri kieltä.
Ja kuten totesin, nyklyisin on kokoajan enemmän merkitystä, miten nopeat muistit koneessa on, ele nuo valimuistisysteemit eivät ole selkeästikään alkuunkaan riittävät
Se, että sinä väität jotain paikkaansapitämätäntä ei muuta sitä todeksi, vaikka kuinka jankutat sitä.
Benchmarkit softien suorituskyvystä eivät tue väitettäsi.
, jos ne olisivat ok, kuten käsittääkseni väität, niin olisi aivan sama, vaikka ajaisi vain yhdellä muistikanavalla, hitaalla muistilla, jos prossussa ei ole näyttistä (käytössä). Ja ei se näyttiksen viemä kaistakaan mitään haittaisi.
Todella typerää olkiukkoilua.
Muistien KELLOTAAJUUS vaikuttaa myös sen muistin
viiveeseen.
ja sillä viiveellä
on selvästi väliä.
Koska sinne muistiin tulee kuotenkin niitä
yksittäisiä accesseja huomattavasti.
Muistiaccessin kokonaisviive ytimelle on luokkaa 50ns.
Sillä on väliä, onko tämä 45ns, 50ns 55ns, että kuinka kauan niitä yksittäisiä accesseja joudutaan odottamaan.
Yhden välimuistilinjan datansiirtoaika on luokkaa 2.5ns(3200 T/s transfer rate, 64bit), ja koko välimuistilinja tulee nykyaikana samasta muistikanavasta
Se, että muistikanavien määrä tuplataan ei nopeuta yhtään sen yksittäisen välimuistilinjan siirtämistä, ei vaikuta yhtään siihen, kuinka kauan prosessori joutuu sitä tyypillisesti odottamaan.
Se vaikuttaa vaan siihen todennäköisyyteen, että sitä muistiaccessia ei voida aloittaa heti, koska juuri samaan aikaan joku muu haluaa aloitta samassa muistikanavassa toisen muistiaccessin.
Ja se, että välillä odotetaan sen 50ns päälle 2.5ns ylimääräistä ennen kuin päästän aloittamaan se access, ei ole kovin paha hidastus.
Sen sijaan, jos sen muistin viive onkin 50ns sijasta vaikka 55ns kun se käy pienemmällä kellotaajuudella - tässä on heti suurempi hidastus joka ikisellä muistiaccessilla.
Että saadaan edes kahden muistikanavan kaista saturoitua, tarkoittaa se sitä, että sitä pitää olla suuruusluokkaa 50ns/2.5ns * 2 = ~40 välimuistilinjan yhtäaikainen haku menossa. Eli 16 ytimelläkin jokaisen ytimen pitää hakea DRAM-muistista asti yhtä aikaa noin viittä välimuistilinjaa. Eli siis joka ytimellä pitää olla viisi L3-missiä menossa. Prossulta loppuu jo OoOE-ikkunakin aika nopeasti kesken että aika harvassa koodissa se löytää niitä viittä eri missaavaa loadia koodista. SMT tosin auttaa että niitä ei tarvi löytää samasta säikeestä, mutta samoista käskypuskureista ne kaksi säiettä kuitenkin tappelee.
(ja kun yhteen välimuistilinjaan mahtuu monta arvoa, peräkkäiset accessit samaan välimuisitlinjaan eivät johda uuden välimuistilinjan hakemista muistista, käytännössä niiden keskeneräisten accessien määrä on paljon suurempi).
Käytännössä softan pitää tehdä jotain melko puhdasta taulukon läpikäyntiä (sisältämättä juuri yhtän laskentaa) jostain todella isosta, välimuistiin mahtumattomasta taulukosta, että se kaista alkaa tulemaan pullonkaulaksi. Hyvin harvat työpöytäsoftat tekee tällaista. Ne datat, mitä yleisemmin käsitellään, mahtuu välimuisteihin, ja/tai ne isot melko puhtaat taulukkoaccessit tehdään hyvin harvoin esim. jossain softaa käynnistettäessä.