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

Liittynyt
01.12.2017
Viestejä
1 564
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ä
39
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 439
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ä
519
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ä
39
Samoin olen myös itse tehnyt. Kiitoksia ja jännityksellä jäädään odottamaan prossun lämpötiloja.
 
Liittynyt
17.10.2016
Viestejä
3 799
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
Team Tesla
Liittynyt
13.10.2016
Viestejä
12 529
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ä
1 018
Aika vahvasti kuriositeetti-linjalle mennään mutta onko näiden threadrippereiden pelisuorituskykyä testattu smt disabloituna missään?
 

Sampsa

Sysop
Ylläpidon jäsen
Team Tesla
Liittynyt
13.10.2016
Viestejä
12 529
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ä
12 044
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ä
3 799
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ä
873
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ä
9 542
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ä
12 044
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ä
1 404
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 931
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ä
3 799
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ä
9 542
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ä
1 404
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ä
873
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ä
11 029
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ä
6 984
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ä
1 404
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ä
39
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 591
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ä
330
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ä
11 941
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ä
12 044
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ä
11 941
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ä
330
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ä
11 941
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

Statistiikka

Viestiketjut
237 331
Viestejä
4 157 436
Jäsenet
70 409
Uusin jäsen
Eycte

Hinta.fi

Ylös Bottom