Itse en usko moiseen millään. Mutta jos riittää kutakuinkin samaan kuin nykyinen 4.8GHz kellotettu 2600K tai enempi (se 350$ malli) niin toki vaihdan 8-ydin/16-säie vaikka ei jotain 5GHz kellotettua kabylakea varmaan päihitä 1-ytimen pelitehossa tai jotain Intelin 10-ydin+ prossuja raskaimmissa hyötysoftissa.
Niin se onkin vaikeaa.
Kuha ny et vain joutuisi pettymään. On sen verta hypeä puheissa, että voi voi.
Odotuksesi on todella korkealla, toivottavasti et joudu pettymään.
Väärin. Kyllä sillä on merkitystä. Ilman markkinaosuutta ei nyt oikein mikään onnistu pörssiyhtiöltä, markkinatilanne vaikuttaa perkeleesti myös itse tuotteiden hinnoitteluun. AMD markkinaosuus on nyt pieni Inteliin verrattuna joten heidän on järkevää haasta Rizenin avulla juuri hinnassa. Tähän vaikuttaa positiivisesti vielä se että Intelin tuotteet ovat selvästi olleet ylihinnoiteltuja jo pitkään. GPU puolella AMD on hakenut yliotetta nvidiasta kehittämällä juurikin markkinaosuuttaan konsolien avulla.
Mietitäämpä vähän prosessorin valmistuksen suurin kuluerä on sen suunnittelut ja testaus valmistusvalmiiksi saakka tämä erä on kiinteä se ei riipu mitenkään siitä kuinka monta prosessoria valmistetaan.
Mitä tulee tuohonväitteeseen sinä teit päätelmän nurinniskoin kun, mitä suurempi myyntivolyymi on sitä pienemmän suhteellisen kustanuksen yksi aiheutuva tukitapaus aiheuttaa, eli sinun tapauksessakin päätelmä on se että AMD:n kannataa maksimoida myytävä prosessori määrä (niin kauan kun se ei leikkaa kokonaistuottoa).
Juu halpa Intel 6/12 on paha kilpailija laskentatehtävissä jotka skaalautuu 100% kaikille ytimille, mutta pitää huomioida että se halpa Intel 6/12 on aika pienillä kelloilla joten ei se pelikoneeseen päädy.
Tosin pitää huomioida että ei (monella) joku 500€ prosessori päädy pelikoneeseen. 2600K oli hieman alle (296€) 300€ vaikka euron kurssi ehkä olikin hieman eri 2011. Mikäli hinta on sen ennustetun 350$ + suomiväännös = 350€ ennen mahdollisia myöhempiä alennuksia vuoden+ päästä myyntiin tulostaan uskoisin että moni ostaa tuon 350€ prosessorin ihan pelikäyttöönkin.
No odotellaan nyt jotain edes auttavia näyttöjä siitä, että AMD:n IPC on oikeasti kilpailukykyinen yleisessä käytössä Intelin kanssa, ennenkuin lähetänä dumaamaan 3.4/3.6GHZ 6800K maan rakoon huonosti threadautuvassa koodissa verrattuna julkaisemattomaan Ryzeniin.
Onko 3.4/3.6GHZ 6800K 6/12 ?
https://www.jimms.fi/fi/Product/Sho...well-e-i7-6800k-lga2011-v3-3_4-ghz-15mb-boxed
Hmm aina oppii uutta, olin siinä luulossa että kaikki E sarjan peliprossut on 8/16 prossuja ja maksaa sen n. 1k€, piitää ottaa seuraava prossuvalintaa pelikäytöön tehdessä huomioon nuo Intel 6/12 variantit.
Maksimituotto on tässä se avainsana. Myydäänkö 100kpl hinnalla X vai 70kpl hinnalla 1,5*X. Näistä jälkimmäinen tuo rahaa sisään enemmän ja vielä enemmän jää käteen kulujen jälkeen. Luvut toki voivat olla mitä tahansa, mutta ajatus että AMD myisi suorittimensa halvalla saadakseen enemmän markkinaosuutta ja vähemmän rahaa ei ole realismia.
Tuella en tarkoittanut asiakastukea, vaan ohjelmistojen optimointia tehokkaiksi AMD:n suorittimilla. Se, ja sitä kautta parempi kilpailuasema tulevaisuudessa, siis voisi puoltaa markkinaosuuden tavoittelua tuoton kustannuksella, mutta luulen että siihen ei tarvita erityisen suurta markkinaosuutta. Eikös tämä ole enimmäkseen kääntäjistä kiinni (korjatkaa toki)?
Haistan tuuhean kasan bullshittia, koska tuli aikoinaan hieman seurattua x264:n kehitystä ja muistikuvat ei vastaa kertomustasi. Muistikuvani mukaan AVX2-optimoinnit oli tehtynä kun Haswell julkaistiin. Toisekseen ainoa etu minkä keksin AVX(1):stä on, että kolmen operandin käskyillä voitiin välttyä monilta muistisiirto-käskyiltä.Handbrake käyttää libx264:ää ja se tukee AVX/AVX2 käskyjä. Ainoa ongelma on, että koska toimintoja on vasta alettu kirjoittamaan AVX/AVX2 assemblynä ei noista saada tällä hetkellä mitään hyötyä
x265:ssa DSP-funktiot varmastikin vievät enemmän aikaa, jolloin niiden vaikutus suorituskykyyn on suurempi. Ennen Haswellia x264:n c vs. asm oli ~40:60 prosessori-ajasta (irkki-logista). Lisäksi HEVC-standardissa panostettiin rinnakkaisuuden lisäämiseen surkeiden AVC GPUsofta-enkoodereiden opettamana.
Höpöjä puhut, ei kaikki ongelmat ole matriisi-kertolaskuja. objdump -d -M intel x264 |grep _avx2 | grep 000000 |wc -l antoi funktiomääräksi 86. Grepattaessa _avx\> antoi 113 ja _sse2\> 181. Kaikille funktioillehan ei kannata kirjoittaa leveämpää asm-vastinetta. Esimerkiksi sad_4x4:stä on vain c ja mmx-versio.Ei liene sattumaa että AMD valitsi demoon työkuormia jotka eivät käytä juurikaan 256-bit käskyjä
Tämä on selvä.
Jos AVX/AVX2 tuki on X264:ssä niin hyvällä mallilla, niin miksei sen käyttämisellä / käyttämättä jättämisellä ole hevon helvetin vaikutusta suorituskykyyn?Haistan tuuhean kasan bullshittia, koska tuli aikoinaan hieman seurattua x264:n kehitystä ja muistikuvat ei vastaa kertomustasi. Muistikuvani mukaan AVX2-optimoinnit oli tehtynä kun Haswell julkaistiin. Toisekseen ainoa etu minkä keksin AVX(1):stä on, että kolmen operandin käskyillä voitiin välttyä monilta muistisiirto-käskyiltä.
Piti kuitenkin tarkistaa, onko uutta assemblya tullut. Koneella oli jo viimeksi joskus ~kesäkuussa viimeksi päivitetty repo. Puolen vuoden aikana oli tullut vain yksi AVX2-spesifi commit mbtree_propagate_list-funktiolle, mikä nimen perusteella kuuluu rate-controlliin ja näin ollen ei ole erityisen suuri ajankuluttaja. Tämä viittaa kypsään AVX2-tukeen, koska luonnollisesti raskaat funktiot tehdään ensin.
Seuraavaksi katsoin x264dev-irkkilogin.
2013-04-12 21:45:41 < Skyler_> is AMD going to ream me for committing AVX2 with their opencl?
2013-04-12 21:48:13 < muggs> heh
2013-04-12 21:48:46 < muggs> noone can fault you for making x264 more efficient
2013-04-12 21:49:41 < Skyler_> unfortunately I can't tell anyone how much faster it is! people will probably assume it helps more than it really does though.
2013-04-12 22:05:31 < muggs> so.. you can't say how much AVX2 helps because you don't have a haswell, or because Intel has you under NDA?
2013-04-12 22:05:42 < Skyler_> Latter. I wouldn't commit this much stuff (or really be able to write it) without a haswell.
2013-04-12 22:06:10 < Skyler_> I don't think I'm actually under a specific NDA right now (?) but since I'm using someone's haswell and I might have a past NDA, I should err on the side of caution
2013-04-23 22:15:37 < kierank> how did you end up getting a haswell in the end?
2013-04-23 22:16:37 < Skyler_> kierank: ask gramner
2013-04-23 22:18:28 < kierank> Gramner: how did you get a haswell
2013-04-23 22:18:40 < Gramner> I asked Intel if they could give me one. Then lots of bureaucracy and paperwork
Uusi hotti käsky aiheuttaa pettymyksen
2013-05-13 19:28:56 < Skyler_> Gramner: also, vgather is so so so slow, I find it hard to believe
2013-05-13 19:29:13 < Skyler_> I did a vgather-based sad_x4_4x4 implementation and I was like 12->32 cycles or something
2013-05-13 19:29:23 < Skyler_> it's not just "okay it's no faster, and there's overhead in calculating addresses"
2013-05-13 19:29:26 < Skyler_> it's "wowow this is horrible"
2013-05-13 19:29:34 < Gramner> i know. i tried it once and it was kinda ridiculous
2013-05-13 19:29:53 < Skyler_> like I am amazed it was actually possible to make an implementation this terrible
2013-05-13 19:29:55 < Gramner> it's way, way, way slower than doing individual loads
Ensimmäisten revikoiden aikaan
2013-06-01 15:10:17 < Skyler_> Here were my results from a bit back, since I suppose I can mention them now
2013-06-01 15:10:19 < Skyler_> This is with AVX2
2013-06-01 15:10:36 < Skyler_> Haswell: ~17% faster than Ivy Bridge, ~28% faster than Sandy Bridge, ~39% faster than Nehalem
2013-06-01 15:10:40 < Skyler_> on a clock for clock basis
2013-06-01 15:12:03 < Skyler_> (x264 of course)
2013-06-01 15:13:16 < BugMaster> Have you tested without AVX2 support also (i.e. old builds without special support)?
2013-06-01 15:21:01 < Skyler_> AVX2 gives ~5%, so you should be able to do the math there
2013-06-01 15:21:06 < Skyler_> (just pull ~5% off each of those)
2013-06-01 15:32:38 < boiled_sugar> can you try with --asm to disable avx2?
2013-06-01 15:33:58 < Skyler_> I did, but I don't have access to the haswell over the weekend
2013-06-01 15:34:02 < Skyler_> but I can confirm it's about 5% lesscommit 03396f82bd1a709aa83d15de0affd0c4c5bd621d
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:53 2013 +0200
x86: AVX2 pixel_ssd_nv12_core
commit dc05aebbc51b64b6cf3cfa95a1fbb20f6ffe94c6
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:50 2013 +0200
x86: AVX2 high bit-depth pixel_ssd
commit f49c2eba352a9087301dfc3c3de902ab083bd9e9
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:46 2013 +0200
x86: AVX2 high bit-depth pixel_sad_x3/pixel_sad_x4
Also reduce the number of xmm registers used by sse2/ssse3 pixel_sad_x3.
commit 0e69048d4f9664f1293c5eed0604522c67adaff5
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:43 2013 +0200
x86: AVX2 high bit-depth vsad
commit 9f885c112d6566388d472da68ada0301ce330311
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:39 2013 +0200
x86: AVX2 high bit-depth pixel_sad
Also use loops instead of duplicating code; reduces code size by ~10kB with
negligible effect on performance.
commit 295f83af2afa93073d7810ab96b1d8d889a53ed2
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:35 2013 +0200
x86: AVX2 high_bit_depth pixel_avg2, get_ref, mc_copy_w16, mc_luma
Also reduce the number of xmm registers used by mc_copy_* to avoid
saving and restoring xmm6 and xmm7 on 64-bit Windows.
commit e7a46b6536ab3ea4806f585b771b6cbb261031d1
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:32 2013 +0200
x86: AVX2 nal_escape
Also rewrite the entire function to be faster and drop the AVX version which is no longer useful.
commit 547a6573af56afe8d551201245775c6ba179e781
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:29 2013 +0200
x86: AVX memzero_aligned
commit 0f776f63daf47eac9b69ef77aaf7c9c16213cba9
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:25 2013 +0200
x86: AVX2 predict_16x16_dc
commit 97ad171ae33c51f48e6214abdf7c978e4dd5d2d1
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:22 2013 +0200
x86: AVX2 predict_8x8c_p/predict_8x16c_p
commit 8ecdeb2709b4b7095237330e68e9a76ea8060a2f
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:18 2013 +0200
x86: AVX2 predict_16x16_p
Also fix the AVX implementation to correctly use the SSSE3 inline asm
instead of SSE2.
commit f3d521da8163bb9a381284ef0b5c949b8a5c9f9c
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:14 2013 +0200
x86: AVX high bit-depth predict_16x16_v
Also restructure some code to reduce code size of various functions,
especially in high bit-depth.
commit fa40b44f339501917e7a7c003ab826bf3e7b6a10
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:08 2013 +0200
x86: AVX2 high bit-depth predict_4x4_h
commit 7908dc632330b6028ab7dae42834e2098e628b24
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:04 2013 +0200
x86: AVX2 high bit-depth predict_16x16_h
commit 51708c3e193438439aaeaf31c377b070ca403e0e
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:27:00 2013 +0200
x86: AVX2 high bit-depth predict_8x8c_h/predict_8x16c_h
commit 184c50554ae95aa60edd3fa309ca8013e00a8648
Author: Henrik Gramner <henrik@gramner.com>
Date: Tue Apr 16 23:26:47 2013 +0200
x86util: Support ymm registers in HADD macros
commit 0ea5be852e97d8cfdf04e384a8a78210f87c2dc0
Author: Fiona Glaser <fiona@x264.com>
Date: Tue Feb 26 16:26:34 2013 -0800
x86: more AVX2 framework, AVX2 functions, plus some existing asm tweaks
AVX2 functions:
mc_chroma
intra_sad_x3_16x16
last64
ads
hpel
dct4
idct4
sub16x16_dct8
quant_4x4x4
quant_4x4
quant_4x4_dc
quant_8x8
SAD_X3/X4
SATD
var
var2
SSD
zigzag interleave
weightp
weightb
intra_sad_8x8_x9
decimate
integral
hadamard_ac
sa8d_satd
sa8d
lowres_init
denoise
commit 19e1a2bbf2d1aaa15ea2d2c118b0236ff64b4bd1
Author: Loren Merritt <pengvado@akuvian.org>
Date: Mon Feb 25 21:16:45 2013 +0000
x86inc: create xm# and ym#, analagous to m#
For when we want to mix simd sizes within one function.
Lyhyt paperikin löytyy näemmä, preview näyttää ensimmäisen sivun.
Description: An introduction to AVX2 optimizations in x264 for the upcoming Haswell CPU line from Intel.
x265:ssa DSP-funktiot varmastikin vievät enemmän aikaa, jolloin niiden vaikutus suorituskykyyn on suurempi. Ennen Haswellia x264:n c vs. asm oli ~40:60 prosessori-ajasta (irkki-logista). Lisäksi HEVC-standardissa panostettiin rinnakkaisuuden lisäämiseen surkeiden AVC GPUsofta-enkoodereiden opettamana.
Höpöjä puhut, ei kaikki ongelmat ole matriisi-kertolaskuja. objdump -d -M intel x264 |grep _avx2 | grep 000000 |wc -l antoi funktiomääräksi 86. Grepattaessa _avx\> antoi 113 ja _sse2\> 181. Kaikille funktioillehan ei kannata kirjoittaa leveämpää asm-vastinetta. Esimerkiksi sad_4x4:stä on vain c ja mmx-versio.
Profiloin x264:n nopeasti samalla presetillä ja resolla (prossuna Ivy), mitä sinulla oli. Eniten aikaa vievä funktio oli x264_pixel_sad_x4_16x16_avx 10.96 % osuudella. Checkasm --bench antoi tuolle
sad_x4_16x16_c: 19849
sad_x4_16x16_mmx: 1400
sad_x4_16x16_sse2: 765
sad_x4_16x16_sse3_c64: 767
sad_x4_16x16_ssse3: 757
sad_x4_16x16_ssse3_c64: 920
sad_x4_16x16_avx: 761
Eli ei ole nopeampi kuin ssse3 tässä funktiossa, mutta pienempi koko, laskin 160 vs. 224 konekäskyä. Pullonkaula tälle taidettiin irc-logissa mainitakin, sad-funktiot ovat muistilataus-rajotteisia.
Toiseksi aikaa vievin oli x264_me_search_ref 10.26, nimestä päätellen sille ei ole assemblya ollenkaan.
Vertailuna avx vs. sse4.2 (--asm sse4.2), 2.87 fps ja 2.83 fps.
Tämä on selvä.
Annoit taannoin ymmärtää että nämä AVX2 käskyt ovat "syynä" siihen että Intel TDP on 140 wattia vs Ryzen 95 wattia. Tarkemmin ajateltuna se analogia on kyllä aikamoista bullsshittiä. Että jokin tietty käskykanta nyt nostaa 50% virrankulutusta. Höpöhöpö.
En ole lainaamasi käyttäjä mutta mutuilen että Intelin skylake (ja kai vanhemmatkin) suorittimet kykenevät suorittamaan 256 bittisen AVX käskyn yhdessä kellojaksossa kun Ryzen käyttäisi siihen kaksi kellojaksoa.
Ainoa mikä taitaa olla aikamoista bullshittiä on sun aivotoiminta, sikäli kun sellaista hirveästi ylipäätään on.
Miksi faktoja tarvitsisi selitellä?
Jos et lue niitä faktoja mitä tiskiin laitetaan ja perehdy asiaan persetuntumaa kummemmin niin se kyllä omasta mielestäni poistaa oikeuden inttää koko asiasta.
Eipä se sitä ymmärtäisi vaikka lukisikin. Röllit ignoreen ja Zenin oikeita mittaustuloksia oottelemaan.
Eli et edes lukenut @The Stilt :n viestiä kunnolla?
Eli et edes lukenut @The Stilt :n viestiä kunnolla?
Ei nyt jumalauta.......
Joo jätänpä tämän sitten tähän
Taidat nyt tukehtua omaan purkkaan tuolla länkytyksellä. Stilt on yksi arvostetuimmista AMD tietäjistä koko foorumilla ja kehtaat tuollaista veistellä.
Ei helvetti sä oot huono
Kannattaa ottaa ensialkuun selvää mitä koko lyhenne TDP tarkoittaa.
Rauhoitutaanpas, vielä hyvän sään aikana. Keskustelua voi käydä menemättä henkilökohtaisuuksiin.
Konseptin eri kellotaajuuksilla ja siten myös eri hinnoilla myytävistä prosessoreista ei pitäisi olla outo eikä pitäisi olla outoa myöskään se että esim. välimuistessa voi olla eroa (Intelhän kikkailee välimuistimäärillä aika paljon)
Kyllä, nuo ovat ilmoitetut arvot.
