Skrivet av andda715:
Tror vi pratar förbi varandra, ovan är precis varför jag tycker att en 8700k är meningslös i dessa scenarion. Dvs så länge inte dessa byggen eller unit-tester faktist kräver mer än vad en hallonpaj kan leverera. Dvs perfekt för en surface pro eller till och med en S8 Note.
Däremot om man kör något som kan utnyttja kärnor (make/parallella testsviter) så är återigen en 8700k ett dåligt val i min mening då den helt enkelt har för få kärnor.
För egen del tar jag mycket hellre exempelvis +8 kärnor på 1.8-2.0 GHz, med hyfsad IPC så ARM/RISC går bort, än 2-4 på +4.0 GHz. Av den enkla anledningen att de 8 på lägre kommer köra på lägre volt och frekvens => betydligt effektivare för strömförbrukning. Dvs laptopen funkar fint att köra lite tyngre tester/simuleringar när man inte har möjlighet till uppkoppling mot server. I förbyggande mening så kan ju nämnas att spänningsskalning (i min mening och erfarenhet) är ganska meningslöst under tiden man använder alla kärnorna. Spänningsskalning brukar nämnas av "singel core-entusiaster" iaf. "snigel core"-förespråkare håller inte med.
Tror inte vi pratar förbi varandra. Är fullt medveten om att i7-8700K sex kärnor inte ger speciellt mycket vinst i de flesta typiska uppgifter en utvecklare företar sig.
Ta skriva-kod/bygga/köra-test cykeln, finns absolut fall där inget av stegen tar någon relevant CPU-kraft. Sitter man på stora projekt, framförallt sådana som använder mycket templates i C++, så vill man inte ha en RPi3 då "bygga" steget mycket väl kan ta 10-20 s, det för en enda fil. Enda som spelar roll då är enkeltrådprestanda, är ju tiden att kompilera en fil man vill slippa vänta på. (Ovanpå det tar länksteget i ett stort projekt mer RAM än vad RPi3 har, så fungerar inte av den anledningen heller).
i7-8700K är "bäst" för att den har högst enkeltrådprestanda. I praktiken sitter ändå allt fler på bärbara, här finns två stora orsaker till det idag fungerar så bra
flera moment är I/O-intensiva, många små transaktioner. Bärbara sög på detta tidigare då mekaniska 2,5" diskar var klart långsammare än 3,5" för stationära. Idag är finns ingen relevant skillnad i diskhastighet mellan bärbara och stationär tack vare SSD
15 W TDP laptops finns idag med boost till och med strax över 4,0 GHz. De kan hålla denna frekvens tillräckligt länge för att överleva koda/kompilera/testa cykeln -> som om man satt på en stationär med 4,0 GHz CPU
Skrivet av HappyPie:
Vid renderingar där hela eller delar av en scenen får plats i grafikkortets minne och beräkningar görs i "sessioner" eller pass, att data överförs i 1st gång eller färre antal gånger under hela renderingen. Det är ett rimligt och vanligt use-case.
MLT renderare är ett sådant exempel.
Däremot där arbete kräver högt antal i/o operationer framför stor mängd så är det säkert en fördel med DDIO.
Dock läser jag till mig att DDIO är best case eller kanske ett low latency case c:a 10-15% snabbare enbart p.g.a. DDIO. E5 plattformen klarar av som bäst c:a 31GBps (250Gbps) i labbmiljö (hittar bara gamla papper från 2012! så....).
Hursomhelst, som jag förstår det så är det att föredra med direktansluten pcie på cpun än via "sydbryggan" över NIC med DDIO.
Helt enkelt att ha ett multigpu system är att föredra framför flera singlegpu system kopplade över nic via DDIO, för gpgpu-beräkningar som har en viss beroende av låga latenser mellan jobben.
Nu har varken 7980XE eller TR DDIO men TR stödjer RDIMM samt fler antal pcie kanaler direkt till cpu:n, utöver de pcie kanaler som går till moderkortet, än 7980XE.
Så i sin helhet att kunna ha flera gpuer via pcie direkt kopplat till cpu:n samt med RDIMM för att ha relativt stor mängd RAM till relativt låga latenser och i samband med stabilitet i ett systemet med ECC och REG ger TR en fördel. (REG ger även lägre latenser när fler stickor används?).
Då räcker säkert en 1900X, men om arbetet skalar bra och utnyttjar även cpu:er eller har en tumregel på att vara optimerad till 1 dedikerad kärna per gpu så kan 1920X eller 1950X vara bra vid flera gpuer.
Där 7980XE har sin nisch så slår antingen 1950X på funktioner och ev. prestanda eller alternativt någon av varianterna av Epyc singel 24/48, 32/64 eller dual 16/32, 24/48, 32/64 till samma pris som ett 7980XE.
För övrigt att 7980XE är en "konsument" cpu struntar jag i som argument om priset är högre än AMDs "server" cpu, pris per system gällande prestanda och funktioner är vad som är betydelsefullt
Ett Epyc system verkar vara mer intressant än Xeons variant i samma visa som mellan TR och 7980XE, även om man kan köra med DDIO med Xeon E5:or.
Jag utgår som sagt att DDIO är en funktion för kommunikation mellan flera datorer bl.a. via NIC(?) ....och att ha en dator med cpu med flera pcie kanaler är att föredra framför det, så att en dator kan innehålla så många gpu:er som möjligt i latenskänsliga beräkningar.
Är det cpu-beräkningar så tänker jag att en single Epyc 32/64 eller dual 24/48, 32/64 om det är nödvändigt med ännu flera cpu-kärnor, i latenskänsliga beräkningar som skalar bra på antalet kärnor, till samma pris som en 7980XE eller Xeon.
Om det är IPC och klock som är viktigast och jobbet är cpu-baserad samt kan delas upp över nätverket relativt oberoende av varandra latensmässigt så är flera i7 8000 att föredra, vilket vissa renderingsjobb är anpassade för.
Tiden att överföra data kontra tiden att utföra beräkning gör att dataöverföringen blir irrelevant. GPUn kommer signalera att jobbet är klart, data kan sedan DMAs ner från kortet samtidigt som nästa jobb laddas upp. Ofta är indata i ett sådant jobb långt mindre än utdata (bilden) + PCIe är en enkelriktad buss så upp- och nedladdning påverkar inte varandras kapacitet (separata kanaler).
Se på mining-riggarna. De specialdesignade moderkorten är tapetserade med PCIe x1 portar för att få in så många GPUer per CPU som möjligt.
DDIO är en funktion som gör det möjligt att köra DMA till/från CPU-cache. Effekten blir därför noll om man enbart gör bulktransfer via DMA. Tekniken nämns främst ihop med NICs, men den är väldigt effektivt på alla former av I/O där man gör väldigt många I/O-transaktioner per tidsenhet.
Vid introduktion av DDIO, Sandy Bridge, var det kanske bara 10/40 Gbit/s Ethernet som riktigt kom upp i problematiskt höga I/O frekvenser. Idag når SSDer och än mer Optane väl in i regionen av miljoner I/O-transaktioner per sekund, i alla fall totalt över systemet.
Var ett par år sedan jag sist jobbade med den här typen av problem. Har sett fall där DDIO gav klart över 50 % boost, detta i ett system som hanterade väldigt mycket I/O per tidsenhet.
Ett typfall för CPUn var att en transaktion kom in, den skulle klassificeras (av CPUn, så CPUn behöver inkommande data från t.ex. NIC och relevant tillstånd för att utföra klassificeringen från någon form av databas som låg lokalt på disk). Klassificeringen kanske resulterade i att data först måste dekrypteras, något som endera gjordes på CPU men ibland på kryptoaccelerator (PCIe-baserad accelerator).
Huruvida det finns en flaskhals vid 250Gbps låter jag vara osagt, det fungerade i alla fall att köra 8 st 10 Gbit/s NICs + lite kryptoacceleratorer och ett gäng diskar (allt jämt fördelat över sockets/NUMA-zoner) från dual-socket E5 2690v1 och framåt. En av huvudpoängerna med Skylake SP är ju att rejält bumpa intern I/O-kapacitet, så gränsen ligger rimligen långt högre idag (har varit mycket ARM och sådan på senare tid, inte så mycket Xeons...).
Rent generellt: DDIO hjälper i fall där periferienhet<->CPU latens är flaskhals.
Intels konsument-CPUer med eDRAM ger sedan Skylake en "fattigmans DDIO". Sedan Skylake sitter eDRAM inte som L4$ till CPU utan som en "osynlig" RAM-buffer, d.v.s. på RAM-sidan av RAM-kontroller. Det betyder att alla DMA-transaktioner också går via eDRAM -> går att köra DMA till/från eDRAM. Blir inte alls samma boost som DDIO då eDRAM har betydligt högre latens jämfört med CPU cache, men man kan få 10-20 % boost mot sin NVMe disk vid små transaktioner/långt ködjup.
TR stödjer ECC+RDIMM, dock saknas väl ändå sådant stöd på de "konsumentanpassade" moderkorten? För mig är TR inte riktigt en konkurrent till Intels HEDT plattform, det är en konkurrent till Xeon Silver/Bronze. Varför?
Intels HEDT plattform är ett vettig val i lägen som inte skalar väl över NUMA-zoner, saker som skalar är ofta mer kostnadseffektiva att köra på TR eller Xeon Silver/Bronze. TR är ur denna aspekt identiskt med dual-socket maskiner, inte med en monolitiskt Intel HEDT
Behöver man riktigt många PCIe men inte superkraft i CPUn så ger faktiskt två Xeon Bronze (som finns från ~$200 styck) totalt 96 PCIe linor till CPU, ovanpå det tillkommer de från sydbryggan, svårt att se något annat kunna konkurrera med det prismässigt
Xeon Silver/Bronze ger en plattform med officiellt ECC och RDIMM stöd + maximal RAM-kapacitet är 1,5 TB (768 GB per socket) vilket vida överstiger HEDT-plattformen
Skrivet av sAAb:
Läs på http://www.caselab.okstate.edu/research/euler3dbenchmark.html
"Intel's Fortran Compiler generates different code paths for different processor capabilities. Non-Intel processors may not trigger the fast code path (See more information). Yes, we are aware of this issue. Yes, it is quite annoying that Intel's compilers behave this way. According to an anonymous contributor, the difference on a modern AMD processor is about 10%. We actually expected the difference to be significantly greater! We are also aware of several fixes but have not applied them as of yet."
Det är en både meningslös och missvisande benchmark att hänvisa till. Den visar inget om HEDT.
Det har definitivt något med Intels HEDT att göra. Detta problem skalar inte väl över NUMA, det gäller även på Intel så har inget med kompilatorn att göra. Detta problem skalar lysande med väldigt hög minnesbandbredd (vilket är väldigt ovanligt, får program har någon större skalning med minnesbandbredd), det även på Intel så har inget med kompilator att göra.
Och om nu skillnaden för AMD är 10 %, det är långt mer som skiljer här relativt hur det ser ut i andra fall.
Infinity Fabric nämns väldigt ofta som något revolutionerande, men det är egentligen inget nytt
IF ett protokoll, inte en elektrisk specifikation (det är en evolution av HyperTransport)
Är specifikt i fall där det knappt finns någon större mängd kommunikation mellan kärnor där TR står sig riktigt väl mot Intels HEDT, d.v.s. där IF knappt används (multi-socket system skalar också lysande i motsvarande fall)
Finns det ingen relevant skillnad mellan IF och protokoll i andra intersocket länkar, Intel har faktiskt lägre latens och högre bandbredd mellan sockets i Skylake SP än vad Epyc har mellan sina CPU-kärnor som ligger på samma kapsel (något som knappast beror på de olika protokollen utan på hur länken realiserats i kisel, UltraPath Connect har väldigt hög frekvens (4,8-5,2 GHz beroende på SKU) -> låg latens)
Benchmarken må ha brister, vilket tyvärr gäller de flesta benchmarks.
Men varför klagar så få på Cinebench i så fall? Cinebench använder en instruktionsmix som inte är relevant för något designat de senaste 10-15 åren. Cinebench har ett "working-set" som helt får plats i lokal cache, så det är helt okänsligt för saker som RAM bandbredd/latens och det skalar därför orealistiskt. Euler 3D är ingen supermåttstock för generell prestanda, men Cinebench är i väldigt många fall en ännu sämre måttstock på det.