• Huom! TechBBS-foorumi on päivitetty uusimpaan Xenforo 2.1-versioon. Kyseessä oli iso päivitys, jonka seurauksena ulkoasu täytyy työstää kokonaan uudelleen, lisäosat päivittää ja toiminallisuuksia säätää. Päivityksen jälkeinen työ ja viilailu jatkuu kulisseissa ja palautetta voi antaa palautealueella, kiitos.

Testissä AMD Ryzen Threadripper 3960X & 3970X (Castle Peak)

Proscribo

Kiitos.
Liittynyt
16.10.2016
Viestejä
415
Nakkelin tuon 3960X:n tilaukseen, pannaan runko astetta rankemmaksi. Onko @Sampsa tossa testisetin Zenithissä ollut mitään negatiivista sanottavaa?
Hinta? :btooth:

Riippuu vähän tarpeista, esim. integroitua 10Gbit liitäntää ei näköjään paljoa halvemmalla saa.
 
Liittynyt
17.10.2016
Viestejä
1 072
Hinta? :btooth:

Riippuu vähän tarpeista, esim. integroitua 10Gbit liitäntää ei näköjään paljoa halvemmalla saa.
Hinta tosiaan, mutta se on edullisin tarpeeksi järeä lankku johon saa 4x 16 slot ja riittävät liitännät.

Kun pitäs saada kellotus- ja pelilelu samaan pakettiin työaseman kanssa niin edullisempi ostaa tuo kuin kaksi erillistä 8) 10Gbit ei itselle ole oleellinen mutta kiva lisähän se on.

E: Strix tai Taichikin kelpaisi. Näistä ennemmin Taichi. Sillon pitäs hukata toinen pcie-levy, mutta myöhemmin toisen voisi korvata nvme-pakalla kun Taichissa tulee lisäkortti.

E2: Vaikka Taichissa on vaan kolme täyspitkää slottia, siinä on vielä 1kpl 1x johon sais usb-lisäkortin. Zenithissä on vaan neljä täyspitkää eli lisäkortin takia sellainen pitäisi kuitenkin uhrata.
 
Viimeksi muokattu:
Liittynyt
20.06.2017
Viestejä
170
Hieno artikkeli! :tup:

Mieleenpainuvimmat jutut:
- CS:GO 9900K 666FPS :D
- Adoben paska scaalaavuus vs. DaVinci
- Intelin 18c prossussa yhtä paska muistilatenssi kuin AMD:n vastaavissa(kertokoot viisaammat mistä johtuu ja miksei yllä samaan kuin oma 9900k?)
- Pelit rasittaa huomattavasti enemmän prossuja kuin cinebench? :btooth:
 

svk

Apua, avatarini on sormi!
Liittynyt
14.12.2016
Viestejä
2 825
- Pelit rasittaa huomattavasti enemmän prossuja kuin cinebench? :btooth:
Mistä tämä käy ilmi? Virrankulutustestissä ero johtuu siitä, että kokoonpanossa on myös paljon syövä näytönohjain. Lämpötilatestissä taas prossu on kuumempi cinepelissä, kuin bäfässä :think:
 
Liittynyt
01.12.2017
Viestejä
928
Mutta eikös se ole niillä intelin 18 ytimisillä skaalautunut kuitenkin ihan ok? (ainakin se fysiikkatesti siinä lopussa).
Ainakin siinä taannoisessa mahottomassa youtubearvostelijoiden kellottelu ja benchmark kisa-hulabaloossa, johon vähän Sampsakin osallistu takavasemmalta, niin oli kaikilla intelin hedt prossut käytössä. Siihen lienee ollut syynä enemmänkin ydinten määrä kuin seksikäs painatus heat spreaderin pinnalla :)
Fire strike skaalautuu 16 threadiin asti, parhaat tulokset tulee kun ottaa tässä tapauksessa 2 ydintä ja hyperthreadingin käytöstä 18 ytimisellä.

Time spy extreme taas osaa käyttää ainakin 56 threadia. 10 korkeinta cpu scorea on xeon 3175x jonka jälkeen alkaa näkymään jo uusia threadrippereitä.
 
Liittynyt
04.08.2017
Viestejä
11
Huomenissa pitäisi tulla 3960x, 64gb mem, Msi Creator emo ja Dark rock pro 5 ilmäjäähy.
Mites tuo lämpötahna pitäis laittaa? Tasainen kerros prossun päälle, vaiko X marks the spot.
Kyseessä Arctics MX-4 lämpötahna.

Odottelen vielä sopivaa AIO-jäähyä tulevaksi. Vielä on hieman epävarma olo, että minkälaisen AIO:n
hankkis myöhemmin.
 
Liittynyt
17.10.2016
Viestejä
1 072
Huomenissa pitäisi tulla 3960x, 64gb mem, Msi Creator emo ja Dark rock pro 5 ilmäjäähy.
Mites tuo lämpötahna pitäis laittaa? Tasainen kerros prossun päälle, vaiko X marks the spot.
Kyseessä Arctics MX-4 lämpötahna.

Odottelen vielä sopivaa AIO-jäähyä tulevaksi. Vielä on hieman epävarma olo, että minkälaisen AIO:n
hankkis myöhemmin.
Tarkoitat varmaan Dark Rock Pro TR4?

Itse laappasin muovilastalla hyvin ohuen ja tasaisen lähes läpikuultavan kerroksen koko IHSn päälle.
 
Liittynyt
27.11.2016
Viestejä
270
Tarkoitat varmaan Dark Rock Pro TR4?

Itse laappasin muovilastalla hyvin ohuen ja tasaisen lähes läpikuultavan kerroksen koko IHSn päälle.
Tuo on se miten itse olen laittanut jo vuosikymmenet lämpötahnan. Tällöin koko alue IHS:tä on katettu lämpötahnalla, eikä jää kyseenalaisia kohtia ottamatta kontaktia prosessorijäähdyttimeen, jolloin lämpö siirtyy koko alueelta sinne mihin se pitääkin siirtää. Nimenomaan tuollainen määrä levitettynä, että lämpötahnan läpi kuultaa IHS hieman alta.
 
Liittynyt
04.08.2017
Viestejä
11
Samoin olen myös itse tehnyt. Kiitoksia ja jännityksellä jäädään odottamaan prossun lämpötiloja.
 
Liittynyt
17.10.2016
Viestejä
1 562
Hieno artikkeli! :tup:
- Intelin 18c prossussa yhtä paska muistilatenssi kuin AMD:n vastaavissa(kertokoot viisaammat mistä johtuu ja miksei yllä samaan kuin oma 9900k?)
Intelin hyvin peleissä menestyvät matalalatenssiset prossut on ringbus topologialla. Mutta toistaiseksi ringbus ei skaalaudu kuin kahdeksaan ytimeen ja siitä yli mentäessä siirrytään mesh topologiaan joka on tuntuvasti heikompi.
 

Sampsa

Sysop
Ylläpidon jäsen
Liittynyt
13.10.2016
Viestejä
8 042
Huomenissa pitäisi tulla 3960x, 64gb mem, Msi Creator emo ja Dark rock pro 5 ilmäjäähy.
Mites tuo lämpötahna pitäis laittaa? Tasainen kerros prossun päälle, vaiko X marks the spot.
Kyseessä Arctics MX-4 lämpötahna.

Odottelen vielä sopivaa AIO-jäähyä tulevaksi. Vielä on hieman epävarma olo, että minkälaisen AIO:n
hankkis myöhemmin.
Itse olen käyttänyt X ja hyvin levittynyt koko pohjan alalle, videolla näkyy asennus meidän Youtube-kanavalla
 
Liittynyt
21.09.2017
Viestejä
733
Aika vahvasti kuriositeetti-linjalle mennään mutta onko näiden threadrippereiden pelisuorituskykyä testattu smt disabloituna missään?
 

Sampsa

Sysop
Ylläpidon jäsen
Liittynyt
13.10.2016
Viestejä
8 042
Aika vahvasti kuriositeetti-linjalle mennään mutta onko näiden threadrippereiden pelisuorituskykyä testattu smt disabloituna missään?
Jotkut pelit kuten Far Cry 5 eivät toimi kunnolla noin suurella määrällä säikeitä, sellaisiin tapauksiin Ryzen Masterilla Game Mode käyttöön joka disabloi SMT:n
 
Liittynyt
16.10.2016
Viestejä
4 831
Eikö ole olemassa mitään työkalua, jolla esim sen pelin saa lukittua vain tietyille rajatuille coreille (esim 1-4)?
 
Liittynyt
17.10.2016
Viestejä
1 562
Eikö ole olemassa mitään työkalua, jolla esim sen pelin saa lukittua vain tietyille rajatuille coreille (esim 1-4)?
Process lassolla onnistuu mut farcry pelien ongelma on ollut myös se että jos peli näkee suuren määrän suorittimia niin se ottaa ja kaatuu :D

... laatupelejä
 

prc

Liittynyt
18.10.2016
Viestejä
596
Eikö ole olemassa mitään työkalua, jolla esim sen pelin saa lukittua vain tietyille rajatuille coreille (esim 1-4)?
Vaikka ihan task managerilla kun olet pelin käynnistänyt. Sieltä napsuttelet CPU affinity valinnoista vaikka coret 0-3, voit toki napsutella vaikka 0,1, 14 ja 15 (16C lastulla) mutta se on melkoisen epäoptimaalinen conffi toki. :)

Pysyvän profiilin tekoon ainakin joskus piti käyttää jotain työkalua. EOS miten nykyisin, tulee niin vähän wintendoiltua.
 
Liittynyt
22.10.2018
Viestejä
244
Eikö ole olemassa mitään työkalua, jolla esim sen pelin saa lukittua vain tietyille rajatuille coreille (esim 1-4)?
Joo helposti saa rajattua pelin käytössä olevat ytimet task managerilla, komentoriviltä tai process lassolla. Ongelmana on lähinnä se, että jos peli kysyy käyttöjärjestelmältä että montako ydintä on olemassa, niin se kertoo täyden määrän ton rajoitetun määrän sijaan ja saattaa tehdä aivan pöhköjä rinnakkaistusvalintoja sen tiedon pohjalta.

Monesti noissa moniydinprossuilla huonosti pyörivissä peleissä saatetaan aivan turhaan jakaa tehtävät niin pieniin osiin, että vastausten keräämiseen menee enemmän aikaa kuin siihen laskemiseen. Ts. joku onglema pilkotaan vaikka 64 osaan vaikka prosessorista riippumatta se laskettaisiin nopeiten esimerkiksi max. neljän säikeen voimin, jolloin synkronointiin menevä aika ei räjähdä liian isoksi. Ohjelmoidessa siis on tehty jotain oletuksia (maksimi)ydinmäärästä sen sijaan että tutkittais limitit joiden yli ei vaan kannata edes yrittää rinnakkaistaa jotain tiettyjä ongelmia. Periaatteessa ei ole mitään oikeaa syytä sille että joku peli pyöris nopeammin pienemmällä ydinmäärällä, vaan kyseessä on aina huono säikeistyksen optimointi.
 
Liittynyt
16.10.2016
Viestejä
4 831
Joo helposti saa rajattua pelin käytössä olevat ytimet task managerilla, komentoriviltä tai process lassolla. Ongelmana on lähinnä se, että jos peli kysyy käyttöjärjestelmältä että montako ydintä on olemassa, niin se kertoo täyden määrän ton rajoitetun määrän sijaan ja saattaa tehdä aivan pöhköjä rinnakkaistusvalintoja sen tiedon pohjalta.

Monesti noissa moniydinprossuilla huonosti pyörivissä peleissä saatetaan aivan turhaan jakaa tehtävät niin pieniin osiin, että vastausten keräämiseen menee enemmän aikaa kuin siihen laskemiseen. Ts. joku onglema pilkotaan vaikka 64 osaan vaikka prosessorista riippumatta se laskettaisiin nopeiten esimerkiksi max. neljän säikeen voimin, jolloin synkronointiin menevä aika ei räjähdä liian isoksi. Ohjelmoidessa siis on tehty jotain oletuksia (maksimi)ydinmäärästä sen sijaan että tutkittais limitit joiden yli ei vaan kannata edes yrittää rinnakkaistaa jotain tiettyjä ongelmia. Periaatteessa ei ole mitään oikeaa syytä sille että joku peli pyöris nopeammin pienemmällä ydinmäärällä, vaan kyseessä on aina huono säikeistyksen optimointi.
Kun kerran voidaan virtualisoida koko tietokone, niin eikö ohjelmaa nyt vain voida käynnistää jonkun loaderin läpi, joka virtualisoisi esim pelkän prossun halutun kaltaiseksi ko ohjelman osalta. Eli kysyipä tai tutkipa ohjelma asiaa miten tahansa, niin sen maailmassa koneessa olisi aina esim 4C8T prossu..
 
Liittynyt
08.12.2017
Viestejä
342
Kun kerran voidaan virtualisoida koko tietokone, niin eikö ohjelmaa nyt vain voida käynnistää jonkun loaderin läpi, joka virtualisoisi esim pelkän prossun halutun kaltaiseksi ko ohjelman osalta. Eli kysyipä tai tutkipa ohjelma asiaa miten tahansa, niin sen maailmassa koneessa olisi aina esim 4C8T prossu..
Käyttiksen affinity-rajoitukset ihan riittävät tuohon, jos käyttää rajapintoja oikein. Se on softantekijän oma vika, jos on rakennellut isompia himmeleitä olettamaan asioita prosessorista. Mitä virtualisointiin tulee, säikeethän ovat jo käskyjonojen "virtualisointia". Käyttis heiluttaa tahtipuikkoja tuossa ja päättää kenen prosessilla on lupa suorittaa milloin ja missä.
 
Liittynyt
18.10.2016
Viestejä
1 198
Ihan command promptilla voi säätää affinityn käynnistyksessä vaikka batin avulla. Voi toki olla eri asia paljon softa havainnoi käyttiksen läpi ytimiä.
 
Liittynyt
17.10.2016
Viestejä
1 562
Mutta mikään muu ei farcy peleihin auta kuin pelin näkemien prossujen määrän pudottaminen.

Se ei millään affiniteetilla korjaudu että jos peli näkee 32 ydintä niin se kaatuu :D
 
Liittynyt
22.10.2018
Viestejä
244
Kun kerran voidaan virtualisoida koko tietokone, niin eikö ohjelmaa nyt vain voida käynnistää jonkun loaderin läpi, joka virtualisoisi esim pelkän prossun halutun kaltaiseksi ko ohjelman osalta. Eli kysyipä tai tutkipa ohjelma asiaa miten tahansa, niin sen maailmassa koneessa olisi aina esim 4C8T prossu..
Kyllä voi! Microsoftia vaan syyttämään siitä että hommat on miten on. Linux puolella käsittääkseni onnistuu läpinäkyvämmin vastaavat säädöt.

Mutta mikään muu ei farcy peleihin auta kuin pelin näkemien prossujen määrän pudottaminen.

Se ei millään affiniteetilla korjaudu että jos peli näkee 32 ydintä niin se kaatuu :D
Jep, koska se ei varmaan kysele mitään käyttäen siihen tarkoitettuja apeja, vaan se on kovakoodattu kaatumaan tilanteissa jossa sitä ei ajeta n. 4 ytimisellä intelin prossulla XD.
 
Liittynyt
08.12.2017
Viestejä
342
Mutta mikään muu ei farcy peleihin auta kuin pelin näkemien prossujen määrän pudottaminen.

Se ei millään affiniteetilla korjaudu että jos peli näkee 32 ydintä niin se kaatuu :D
Paskasti koodattu softa. Otetaan toiseksi esimerkiksi vaikkapa GNU make. Softa on vanha kuin taivas ja tukenut useampaa ydintä ihan aikojen alusta (melkein). Muistan kun joskus oli dual-socket Pentium 2 pöydällä, niin siinäkin sai jo monta ydintä käyttöön (tietenkin yksi ydin per CPU sen aikaisissa). Unix-koneissa sai enemmän kun oli parempaa rautaa. Nykyisin ajanut make -j32, eikä mitään merkkiä kaatuilusta.
 

prc

Liittynyt
18.10.2016
Viestejä
596
Paskasti koodattu softa. Otetaan toiseksi esimerkiksi vaikkapa GNU make. Softa on vanha kuin taivas ja tukenut useampaa ydintä ihan aikojen alusta (melkein). Muistan kun joskus oli dual-socket Pentium 2 pöydällä, niin siinäkin sai jo monta ydintä käyttöön (tietenkin yksi ydin per CPU sen aikaisissa). Unix-koneissa sai enemmän kun oli parempaa rautaa. Nykyisin ajanut make -j32, eikä mitään merkkiä kaatuilusta.
Veikkaan että make:ssa ei ole mitään keinotekoista rajaa (en jaksa etsiä sorsista). Jonkun pointterin perässä ne threadit on, että sen pointterin bittisyys määrittää maksimin, jos se on yli 16bit pointteri niin ihan varmana leviää kerneli/scheduleri käsiin. Tosin ennen lie tulee reaaliongelmaksi ongelmaksi löytää kone jossa on niin paljon coreja, että se pointteri loppuu kesken (pois lukien tuo 16bit tapaus jossa usignedilläkin "vain" 65+k corea riittää).

Koodin kääntäminen toki on myös kivasti rinnakkaistuva ongelma, ei tarvi tehdä keinotekoisia rajoja. Pelimoottorissa voi hyvinkin tarvita, mutta sen ny voi koodailla silti niin ettei se kosahda ympäri jos on liian monta corea. :D
 
Liittynyt
22.10.2016
Viestejä
5 791
Veikkaan että make:ssa ei ole mitään keinotekoista rajaa (en jaksa etsiä sorsista). Jonkun pointterin perässä ne threadit on, että sen pointterin bittisyys määrittää maksimin, jos se on yli 16bit pointteri niin ihan varmana leviää kerneli/scheduleri käsiin. Tosin ennen lie tulee reaaliongelmaksi ongelmaksi löytää kone jossa on niin paljon coreja, että se pointteri loppuu kesken (pois lukien tuo 16bit tapaus jossa usignedilläkin "vain" 65+k corea riittää).
Ei käytännössä missään ole mitään 16-bittisiä pointtereita enää. Pointterit on 64-bittisiä 64-bittisessä käyttiksessä. Tarkoittanet jotain muuta kuin pointteria puhuessasi pointterista.

Koodin kääntäminen toki on myös kivasti rinnakkaistuva ongelma, ei tarvi tehdä keinotekoisia rajoja. Pelimoottorissa voi hyvinkin tarvita, mutta sen ny voi koodailla silti niin ettei se kosahda ympäri jos on liian monta corea. :D
Koodin kääntämisen rinnakkaistus on itseasiassa monimutkaisempi juttu, kuin mitä triviaalisti luulisi.

Tyypillisessä makefileessä käännellään ensin kooditiedostot objektitiedostoiksi, ja sen jälkeen ne linkataan yhteen.

Ja käytännössä tuo linkkaus on täysin yhdessä prosessissa ja säikeessä ajettava ei-rinnakkaistumaton asia, jonka voi tehdä vasta kun kaikki kooditiedostot on ensin käännetty.

Eli, meillä on kaksi eri työvaihetta, toinen rinnakkaistuu (melkein) kooditiedostojen määrän verran, toinen ei yhtään.

Ja perinteinen make tyypillisesti oletuksena ajetaan yhdelle hakemistolle kerrallaan, ja se sitten kutsuu rekursiivisesti alihakemistoille makea, mutta kerralla siis käännetään vain yhtä hakemistoa.

Jos koodi on sijoiteltu suureen määrän hakemistoja joissa jokaisessa on melko pieni määrä kooditiedostoja, rinnakkaistus ei ole kovin hyvää.

Eli pitäisi myös rinnakkaistaa eri hakemistojen kääntäminen rinnakkain, että saisi rinnakkaisuutta tarpeeksi, mutta koska niitä kutsutaan normaalisti rekursiivisesti, säikeiden määrää olisi silloin vaikea rajoittaa, ja riskinä olisi helposti laukoa eksponentiaalinen määrä säikeitä hakemistorakenteen hierarkian syvyyteen nähden. (minkä takia se make ei siis tee tätä oletuksena)

Eli käytännössä jos halutaan hyvin rinnakkaistuvaa kääntösysteemiä, pitääkin se ehkä tehdä jollain muulla kuin makella, tai vähintään käyttää makea hyvin eri tavalla kuin miten sitä on perinteisesti totuttu käyttämään.

Lisäksi erityisesti melko oliopohjaisessa C++-koodissa (ainakin jos siinä käytetään paljon esim. templateja) tulee vastaan helposti sellainen ongelma, että suuurin osa kääntöajasta ei itse asiassa usein kulu varsinaiseen koodin kääntämiseen, vaan siihen, että preprosessori parsii headeita, kun koodi inkludoi vaikka mitä jotka taas ne inkludoivat vaikka mitä, jotka inkludoivat vaikka mitä, ja tämä headerien parsiminen vie saman määrän aikaa, olisi varsinainen koodi hyvin lyhyt tai hyvin pitkä. Tämä tarkoittaa sitä, että jos halutaan vähentää tähän kuluvaa turhaa työtä, kannattaakin samaan kooditiedostoon laittaa mahdollisimman paljon koodia, ja minimoida kooditiedostojen määrä - mikä taas on rinnakkaistamisen kannalta huono.


Isot softaprojektit ovat kyllä usein optimoineet koodin sijoitteluaan tiedostoihin ja kääntöjärjestelmiään aika paljonkin, jotta aikaa ei kulu turhiin headerien parsimisiin, mutta silti saadaan hyödynnettyä paljon rinnakkaisuutta, jotta ne kääntyvät siedettävän nopeasti ja hyötyvät suuresta määrästä ytimiä - mutta sen tekemiseen on jouduttu näkemään paljon vaivaa.
 
Liittynyt
21.06.2017
Viestejä
3 162
Eikö ole olemassa mitään työkalua, jolla esim sen pelin saa lukittua vain tietyille rajatuille coreille (esim 1-4)?
Vaikka ihan task managerilla kun olet pelin käynnistänyt. Sieltä napsuttelet CPU affinity valinnoista vaikka coret 0-3, voit toki napsutella vaikka 0,1, 14 ja 15 (16C lastulla) mutta se on melkoisen epäoptimaalinen conffi toki. :)

Pysyvän profiilin tekoon ainakin joskus piti käyttää jotain työkalua. EOS miten nykyisin, tulee niin vähän wintendoiltua.
Ihan windowsin start.exe komennolla toi onnistuu käyttämällä /affinity vipua. Sen hex mäskin säätäminen on vaan hiukan työlästä, mutta kun sellaiset yleiset mäskit laittaa jonnekkin jemmaan niin ei senkään kanssa tartte sen enempää ihmetellä kuin sen kerran.
Tuon saa viriteltyä vielä ihan shortcutin kautta toimivaksi, testattu on.
 
Liittynyt
08.12.2017
Viestejä
342
Eli käytännössä jos halutaan hyvin rinnakkaistuvaa kääntösysteemiä, pitääkin se ehkä tehdä jollain muulla kuin makella, tai vähintään käyttää makea hyvin eri tavalla kuin miten sitä on perinteisesti totuttu käyttämään.

Lisäksi erityisesti melko oliopohjaisessa C++-koodissa (ainakin jos siinä käytetään paljon esim. templateja) tulee vastaan helposti sellainen ongelma, että suuurin osa kääntöajasta ei itse asiassa usein kulu varsinaiseen koodin kääntämiseen, vaan siihen, että preprosessori parsii headeita, kun koodi inkludoi vaikka mitä jotka taas ne inkludoivat vaikka mitä, jotka inkludoivat vaikka mitä, ja tämä headerien parsiminen vie saman määrän aikaa, olisi varsinainen koodi hyvin lyhyt tai hyvin pitkä. Tämä tarkoittaa sitä, että jos halutaan vähentää tähän kuluvaa turhaa työtä, kannattaakin samaan kooditiedostoon laittaa mahdollisimman paljon koodia, ja minimoida kooditiedostojen määrä - mikä taas on rinnakkaistamisen kannalta huono.
Njoo, en missään kohtaa tarkoittanut, että make olisi hyvä esimerkki tehokkaasta ohjelmasta. Pointti oli vaan, että se on aika vanha työkalu ja testatusti on tukenut nykyisiä prosessimääriä jo pitkään. Nykyisten pelien yms. kaatuilu 4-32 ytimellä on jotain ihan muuta.

<ot>Periaatteessa C++:n moduulien pitäisi jossain määrin auttaa tuohon. Jos ajatellaan sen verran laatikon ulkopuolelta, että ei rajoituta esikääntäjää käyttäviin kieliin (C/C++), niin olioparadigmassa tai templateissa ei sinällään ole rinnakkaistumista estäviä piirteitä niin paljon kuin voisi kuvitella. Lex+parse on perinteisissä ei-optimoivissa kääntäjissä moninkerroin raskaampi operaatio kuin koko loppu pipeline (ja linkkeriä on nykyään alettu mm. LLVM-projektissa rinnakkaistaa myös). Kuitenkin jos kieli ei käytä esikääntäjää, jokaisen moduulin voi jäsentää täysin itsenäisesti. Symboliviittausten ratkonta ja namespacet tuohon päälle ovat 1% siitä ajasta mitä jäsennys, riippuen tietty jäsennysalgoritmista. Jäsentämisessä voi yllättäen levy tulla pullonkaulaksi, kun pitäisi tehdä pieniä lukuja monen tiedoston kanssa rinnan. Levyn optimointiin yksi hopealuoti on käyttää tmpfs:ää. Näin siis jos on tosi kiire. Voidaan myös optimoida siinä, että jos tiedetään projektin käyttävän kaikkia moduuleitaan, voidaan iteroida sorsakoodin hakemistopuu läpi optimaalisesti eikä odotella kunnes tiedostot "löydetään" includeista. Includeilla vasta linkitettäisiin TU:t toisiinsa kun moduulien symbolinimiä aletaan ratkoa. Kieliopilla pystyy hiukan optimoimaan sitä, kuinka paljon viittauksia pitää ratkoa. Ja kaiken kukkuraksi kun on käännetty, ei ole järkeä heittää kaikkea pois vaan esim. kytkeä inotifyllä levyjärjestelmään ja päivittää AST vähän samaan tapaan kuin mitä virtual DOM -hommelit webbipuolellla.. tässäkin hyötyä jos käytössä jokin dataflow-koodausta tukeva funktionaalinen kieli eikä imperatiivinen paske.</ot>
 
Liittynyt
04.08.2017
Viestejä
11
Huom! Wraiht Ripper:in tuuletin on asennettu tehtaalla väärin päin cooleriin! En tiedä onko uudempiin malleihin jo tehty korjaus. Eli kannattaa katsoa minne päin Ripper puhaltelee.

Vaihdoin tuulettimen suuntaa. Aiemmin se puhalsi suoraan kopan etuosaan ja lisäsi sekä lämpötiloja että ääntä. Nyt kone on paljon hiljaisempi ja lämpötilat tippuivat 10C.

Wraiht Ripperin coolerista irrotetaan alhaalta ruuvit ja sen jälkeen otetaan varovasti coolerin muovikuori päädyistä napsauttamalla. Älä riko muovin sivuilla olevia kumireunoja.

Itse cooleria pitää kiinni kaksi pyöreäpäistä ruuvia sekä muovinapsut. Ruuvit ovat pyöreäpäisiä, jottei kukaan saisi helposti niitä auki. Laita ruuvin sekä ruuvimeisselin väliin paksua kumilenksua ja väännä suoraan ylhäältä , näin ruuvit saa irti. Tämän jälkeen tuuletin pitää varovasti hivauttaa pois coolerista ja kääntää toisin päin, jotta kuuma ilma menee oikealla tavalla kopasta ulos.

Nyt kone hyrrää idlessä ihan mukavasti, eikä huuda jatkuvaa soittoa.

Jouluja kaikille!
 
Viimeksi muokattu:
Liittynyt
19.02.2017
Viestejä
1 337
Jääkö IO-techille tuommoista threadripperiä projektikoneeksi? Olisi mielenkiintoista nähdä kokeiluja sen suhteen että mihin kaikkeen kotikäyttäjä voisi tuollaista soveltaa ja onko semmoisia skenaarioita missä tuo ylimääräinen raha kannattaisi jopa maksaa.
Eikös sampsalla ollu jossai striimi koneessa dripperiä jo ennestään. Ainaki huomannu et noitä hyödynetty juuri striimikäytössä ellen ihan väärässä ole. Parhainta kuitenkin et amd iskeny joka osa alueelle ja nyt saamme kilpailun myötä vastinetta rahalle eikä tarvii yli hintaa maksaa kun kilpailua ei ole.
 
Liittynyt
17.10.2016
Viestejä
240
Jääkö IO-techille tuommoista threadripperiä projektikoneeksi? Olisi mielenkiintoista nähdä kokeiluja sen suhteen että mihin kaikkeen kotikäyttäjä voisi tuollaista soveltaa ja onko semmoisia skenaarioita missä tuo ylimääräinen raha kannattaisi jopa maksaa.
Oma 3970X + Zenith II + 128Gb DDR4 + RTX 2080Ti kone ollut nyt muutaman päivän kasassa ja jonkin verran ehtinyt tässä testejä ajelemaan. Photogrammetria- ja laserkeilauksen rekisteröintiohjelmilla ja lopputulos on se, että joka euron arvoinen setti on kasassa. Esim. Pix4D:llä saman projektin pyöräyttämiseen meni 2700X + 32Gb + 1080Ti aikaa 2:45:35. Tämä Theadripper vetää saman 35:49
 
Liittynyt
17.10.2016
Viestejä
5 630
Oma 3970X + Zenith II + 128Gb DDR4 + RTX 2080Ti kone ollut nyt muutaman päivän kasassa ja jonkin verran ehtinyt tässä testejä ajelemaan. Photogrammetria- ja laserkeilauksen rekisteröintiohjelmilla ja lopputulos on se, että joka euron arvoinen setti on kasassa. Esim. Pix4D:llä saman projektin pyöräyttämiseen meni 2700X + 32Gb + 1080Ti aikaa 2:45:35. Tämä Theadripper vetää saman 35:49
Sulla on 4000€ softa kotikäytössä?
 
Liittynyt
16.10.2016
Viestejä
4 831
Sulla on 4000€ softa kotikäytössä?
Selvästi on käytössä joko kotona tai yrityksessä, MUTTA mitä merkitystä?!
Hyvä, että joku on testannut noilla prossuilla ja jakaa testituloksen!

Eikä se 4000e jostain softasta ole edes paljon, jos tekee hommia sillä.
 
Liittynyt
17.10.2016
Viestejä
5 630
Selvästi on käytössä joko kotona tai yrityksessä, MUTTA mitä merkitystä?!
Hyvä, että joku on testannut noilla prossuilla ja jakaa testituloksen!

Eikä se 4000e jostain softasta ole edes paljon, jos tekee hommia sillä.
Moukula kysyi viestissään erityisesti kotikäyttäjille relevantteja käyttökohteita joita varten kannattaisi harkita uudesta Threadripperistä maksamista.

En epäile yhtään, etteikö ammattilaisen photogrammetriasovelluksessa 32-coreinen monsteri olisi hyvä valinta. Etenkin kun softan hintaan verrattuna ne muutamat tonnit työasemasta on vielä ihan siedettävä hinta. En vaan näe, että tuolla testituloksella olisi nimenomaan kotikäyttäjälle juurikaan merkitystä.

Sen sijaan esim. Agisoftin metashapen $179 USD hintaisella standard-versiolla tehty testi olisi kotikäyttäjille merkittävästi relevantimpi benchmark. Ties vaikka se olisi jollekin harrastelija droneilijalle erittäinkin mielenkiintoinen softa.

Eli joo, mielenkiintoinen benchmark, mutta ei vastaa ollenkaan sen alkuperäisen kysyjän tarpeeseen.
 
Liittynyt
17.10.2016
Viestejä
240
Moukula kysyi viestissään erityisesti kotikäyttäjille relevantteja käyttökohteita joita varten kannattaisi harkita uudesta Threadripperistä maksamista.

En epäile yhtään, etteikö ammattilaisen photogrammetriasovelluksessa 32-coreinen monsteri olisi hyvä valinta. Etenkin kun softan hintaan verrattuna ne muutamat tonnit työasemasta on vielä ihan siedettävä hinta. En vaan näe, että tuolla testituloksella olisi nimenomaan kotikäyttäjälle juurikaan merkitystä.

Sen sijaan esim. Agisoftin metashapen $179 USD hintaisella standard-versiolla tehty testi olisi kotikäyttäjille merkittävästi relevantimpi benchmark. Ties vaikka se olisi jollekin harrastelija droneilijalle erittäinkin mielenkiintoinen softa.

Eli joo, mielenkiintoinen benchmark, mutta ei vastaa ollenkaan sen alkuperäisen kysyjän tarpeeseen.
Jos tässä halutaan alkaa hiuksia halkomaan, en vastannut alkuperäisen kysyjän tarpeeseen. Yleisesti vaan ilmaisin, millaisia tehonlisäyksiä voi ko. prossulta odottaa.

[OT]Agisoftiltakin on professional versio tuosta Metashapesta saatavilla ja sekin maksaa ~$4000[/OT]
 
Liittynyt
17.10.2016
Viestejä
5 630
Jos tässä halutaan alkaa hiuksia halkomaan, en vastannut alkuperäisen kysyjän tarpeeseen. Yleisesti vaan ilmaisin, millaisia tehonlisäyksiä voi ko. prossulta odottaa.

[OT]Agisoftiltakin on professional versio tuosta Metashapesta saatavilla ja sekin maksaa ~$4000[/OT]
Niin on, mutta nimenomaan tuon edullisen version olemassaolo (en tiedä mitä noista pro-featureista voisi harrastelijana kaivata) tekee siitä kotikäyttäjälle mielenkiintoisemman.
 
Toggle Sidebar

Uusimmat viestit

Statistiikka

Viestiketjuja
80 408
Viestejä
1 642 961
Jäsenet
36 190
Uusin jäsen
Wundebar

Hinta.fi

Ylös Bottom