The No.1 Website for Pro Audio
 Search This Thread  Search This Forum  Search Reviews  Search Gear Database  Search Gear for sale  Search Gearslutz Go Advanced
Intel vs AMD - DawBench (Pro-Q/Pro-MB/Kramer) on Reaper & Ableton Condenser Microphones
Old 12th June 2017
  #31
Lives for gear
 

To be an uninvited and almost certainly unwanted adjudicator, mattiasync is correct. A vertical line down the 100% mark would make it clearer. Without redoing anything, one of those pop-up message things people use for corrections could be used.

But it isn't accurate as presented at the moment. That's perfectly fair to say. I'm glad I didn't bring it up, my reasoning being that I didn't want to appear to be some kind of AMD fan club member when I am just gunning for competition in what's become a near monopoly.
Old 12th June 2017
  #32
Gear Maniac
 

Thread Starter
Quote:
Originally Posted by captain caveman View Post
To be an uninvited and almost certainly unwanted adjudicator, mattiasync is correct. A vertical line down the 100% mark would make it clearer. Without redoing anything, one of those pop-up message things people use for corrections could be used.

But it isn't accurate as presented at the moment. That's perfectly fair to say. I'm glad I didn't bring it up, my reasoning being that I didn't want to appear to be some kind of AMD fan club member when I am just gunning for competition in what's become a near monopoly.
It is not confusing. Literally NO ONE represents statistics in that way. Go look at any number of peer reviewed studies. Saying that Intel has a 153% performance advantage over AMD is clear as day. I said that reaper had a 360% performance advantage over Ableton. That obviously means that it performed 3.6 times better. Anyone who has ever done statistical analysis understands this is how you are supposed to represent data.

Will not argue this anymore because this is really dumb. I won't correct the video, there is nothing wrong with how I'm representing the data. This is exactly how it should be represented.
Old 12th June 2017
  #33
Lives for gear
 

"advantage" implies "difference" to me. Apparently not to you, and you could have said so right away.

And you could also have said that you don't want any comments that aren't entirely positive.

Grow up.
Old 12th June 2017
  #34
Gear Maniac
 

Thread Starter
Quote:
Originally Posted by mattiasnyc View Post
"advantage" implies "difference" to me. Apparently not to you, and you could have said so right away.

And you could also have said that you don't want any comments that aren't entirely positive.

Grow up.
So not agreeing with your feedback means that somehow I only wanted comments that are entirely positive and that somehow I am acting immaturely?

Maybe you should stop trolling and actually try to engage in a meaningful manner. Plenty of others have brought up critical points that I've addressed without issue. I wonder why?
Old 12th June 2017
  #35
Lives for gear
 

Quote:
Originally Posted by PrismaPhonic View Post
It is not confusing. Literally NO ONE represents statistics in that way. Go look at any number of peer reviewed studies. Saying that Intel has a 153% performance advantage over AMD is clear as day. I said that reaper had a 360% performance advantage over Ableton. That obviously means that it performed 3.6 times better. Anyone who has ever done statistical analysis understands this is how you are supposed to represent data.

Will not argue this anymore because this is really dumb. I won't correct the video, there is nothing wrong with how I'm representing the data. This is exactly how it should be represented.
No need to be rude. I am perfectly comfortable with both peer reviewed studies and the use of percentages. 153% equals a 53% gain/advantage, not 153%. I've never read a study that confuses this concept. I'll stop there.
Old 12th June 2017
  #36
Lives for gear
 

Quote:
Originally Posted by PrismaPhonic View Post
So not agreeing with your feedback means that somehow I only wanted comments that are entirely positive and that somehow I am acting immaturely?

Maybe you should stop trolling and actually try to engage in a meaningful manner. Plenty of others have brought up critical points that I've addressed without issue. I wonder why?
I can answer your question: None of them directly questioned any of your reasoning. That's really the only difference.

I've participated in a meaningful manner because your terminology is unclear. Calling people "trolls" rather than actually discussing an objection to the terms you use is childish.

Now, for reference:

Quote:
The strength of AMDs silicon is better multithreading. Even benchmarked clock-for-clock against Intel's Core i7 6900K Broadwell-E and Core i7-7700K Kaby Lake chips (with all processors frequency locked to 3.5GHz), the Ryzen 7 1800X showed a 2.7 and 6.5 percent performance advantage respectively over its rivals in the Cinebench 1T benchmark.
Quote:
As you can see, AMD will have the advantage in terms of cores and threads, and with twice as many memory channels it will also have a memory bandwidth advantage. On Naples machines it has tested, AMD can push 170.7 GB/sec of memory bandwidth, compared to Intel’s 76.8 GB/sec on its own tests using a Broadwell system with the top bin parts. Intel Broadwells can have up to three memory sticks per channel, compared to two for Naples, so the Naples chip tops out at 512 GB using very cheap 16 GB sticks compared to 384 GB for the Broadwells. So that is a 122 percent memory bandwidth and a 33 percent memory capacity advantage to AMD. (The Naples chip can also run the memory at 2.4 GHz compared to 1.87 GHz for the Broadwells, and that 29 percent speed bump is why it has higher bandwidth than the memory subsystem on the Xeon chip.) If you need to maximize memory in either a Naples or Broadwell system, the former tops out at 2 TB while the latter maxes at 1.5 TB in two-socket machines.
Quote:
The Ryzen and Intel systems go neck-and-neck at 4K resolution. The gap widens a bit at 1440p, giving the Intel system a slight 7 percent performance advantage, but AMD’s chip still delivers a damned fine gaming experience overall in both average frame rates and overall smoothness.
So there you go. A very quick Googling seems to show that (performance) "advantage" really does refer to the delta relative to the lower-performing source which then is the reference.
Old 12th June 2017
  #37
Lives for gear
 

Quote:
Originally Posted by PrismaPhonic View Post
I would be happy to run my tests at various clock speeds to see if that has an impact because I did have a lot of people calling "foul" on my video due to not matching the 3200 Mhz overclock I was able to achieve on the Intel platform.

Let's not forget though that I did clock the memory as high as I could possibly get it on AMD, but that platform is currently experiencing well known limitations in memory speeds. I did see that a new BIOS update just came out for the x370 board I'm using though so I might be able to clock higher now on the Ryzen machine and can run some tests there.
Thanks, that would be great, if you don't mind to try that.. As I've said, I'm mostly interested in relative performance difference among different RAM frequencies at Ryzen.. Like max. frequency, you've achieved there versus base frequency of DDR4s, which is 2133 MHz.
Maybe test with lower ASIO buffer length will be more interesting, as it puts much higher strain to the computer and scheduling performance. Even jump from 1024 to something like 128 will show quite dramatic difference typically.

Quote:
Personally I don't think it would have an impact on max plugin load handling. There have been plenty of reports that on Ryzen going from 2400 Mhz up to an extreme overclock of 4000 Mhz (how they got it that high is beyond me) showed a 9% performance difference in certain benchmarking. As far as I know this has not been tested in audio workloads but if we assume it's true, then it wouldn't even get close to explaining the 150% performance advantage I saw on the 6900K over the 1800x.
I also won't guess, there will be some significant difference with plugin count.
However as we previously talked with Mattias, unique Ryzen architecture with two CCXs and Inifinity Fabric coupled to RAM clock, there is certain chance to affect that. However I won't bet on it, also in previously linked Guru3D article, there were workloads, where it helped and other workloads, where it doesn't add anything.
Maybe second independent test (the first did Peter Kaine, but we haven't any figures), finally ends this discussion.

Quote:
...
And as we saw towards the end of my video, in Cinebench and Blender rendering tests, they really are nearly identical in performance with Intel taking a very small lead. The area we see larger discrepancy is in audio workloads, which could be related to audio plugin developers optimizing for Intel and not AMD since Intel has been the market lead for nearly a decade now. My video is not attempting to state outright that AMD is a poor performer, but that whatever the causative factors are, whether they be hardware related (poor chip performance) or software related (poor optimizations), we do see a large performance discrepancy between these two platforms right now for audio related workloads.
I'm not really sure about further optimization of audio plugins or generally DSP algorithms in DAWs for Ryzen. As I've got it, these game updates, where it really helped at this platform, were mostly about modification of thread scheduling to minimize use of (expensive) data path between CCX units in similar way like it's commonly used at NUMA systems. Where you essentially isolate closely coupled threads and schedule it accordingly (or more carefully adjust memory allocation, when each CPU has its own memory controller). This is used for instance at multi-socket machines.
I don't see much chances to do optimization with threads in some typical DAW, where each track has own effects worker, where all is calculated in serial fashion and each effect has own single processing thread (exceptions are very very rare). Ratio of the time spend in effect processing to the time mixing of track outputs for buses, where it has to wait for complete audio chunk from all contributing workers, is very high, so communication and sharing between threads typically isn't bottleneck there.
Anyway, if that will be the problem with Ryzen and DAWs, then it could be probably quite easily revealed by testing with DAW isolated just at single CCX.
For example using some tool like PSExec or Process Lasso.. and comparing to the performance with unrestricted scheduling to all cores across both units.
In tested applications, where was intensive sharing between threads, performance with isolation was comparatively better.
Also some latest Intel specific instructions (AVX 256, 512) are not really used for plugin optimizations AFAIK to blame specific Intel tuning there.

Anyway, I'm also not really biased against that and for some workloads Ryzens are great value, but here I'm bit skeptic.

Michal

Last edited by msmucr; 13th June 2017 at 09:58 AM.. Reason: fixes
Old 13th June 2017
  #38
Lives for gear
 

Quote:
Originally Posted by mattiasnyc View Post
Yes, he did. And I said "if" for a reason. Someone else linked to another person doing tests saying that increasing memory speed makes a big difference. So they can't both be right.
Quote:
Originally Posted by msmucr View Post
If you're talking about the previous linked post by J. Roseberry, then at the top he just assumes, it will be faster due to CCXs communication.. there are no comparable DAWBench results say at 2133 vs 2933, because he switched to 64bit DAWBench from his previous test at lower RAM clock.
Yeah, I saw Jims results when they were first published and retested here with 2133, 3200, 3600 and didn't see a difference that wasn't within 2% margin or error.

As Michal mentions Jim himself also pointed out in his own thread on the Sonar forum that he'd left the 32bit plugin in the folder and the bridging had screwed the bench results on the first run, I've seen this myself first hand in the past so it's a fair as explanation as any I can see.

I've also done a 1600X recently as I was wondering if this could be attributed to the core thread handling issue that's currently cropping up in some setups as reported by Steinberg, but that chip scaled the same way too and it falls outside of the known 8+ cores threading issue. I'm happy that at least this is at least constant in how its occuring across the range now and isn't something that is going to prove erratic over the longer term which is where my initial fears laid.
Old 14th June 2017
  #39
Gear Maniac
 

Thread Starter
I just finished testing different RAM clock speeds on Reaper. I got identical results running at base clock on Ryzen (2133 Mhz) so literally no difference whatsoever for plugin handling.
Old 14th June 2017
  #40
Lives for gear
 

Thanks to PrismaPhonic and Peter for taking of time to test DawBench with different memory speeds..
I believe, we can probably conclude, typical DAW workload isn't practically affected by that.. more or less random variations around 1-2% are exactly same as I've previously get at Intel setups.

All the best,

Michal
Old 14th June 2017
  #41
Lives for gear
 

So there are two scenarios, plugins where performance scales well relative to Intel and plugins where there is an issue.

To eliminate sharing resources between CCXs from the equation, the plugins in question could be run in dedicated processes in Reaper.

- right-click plugin in FX browser and select Run as -> Dedicated process. The restart Reaper and reload project.

My guess is that this will reduce the plugin count on both machines, but substantially lessen the gap.

If this is the case then it should be easy for devs to see whether their plugins will be affected.
Old 14th June 2017
  #42
Lives for gear
 

I don't think, this is especially good idea with running at dedicated process.
IPC has always pretty high overhead and naturally adds latency, so it makes sense to avoid where possible. It has it's place, where you need bridge between architectures (like calling 32bit library from 64bit software), or where you need total process isolation at own memory space to for security or error resilience reasons, when spawned child process shouldn't crash main program.. for the rest threads are almost always better solution. Thread affinity to particular CPU core is either implicit (handled automatically by OS scheduler) or explicit (internally from the program using appropriate calls). Additionally you can further override OS scheduler and limit affinity range for whole process running in implicit mode.

Vast majority of plugins doesn't use multiple threads for DSP calculation, there is single thread for audio processing with high priority and another thread(s) for UI and automation handling. So in this case, isolating of everything in separate process can't really help as this processing never runs "over" multiple cores.

There are few instruments, which employs multiple internal threads for audio, but it's very rare and usually it's optionally switchable feature. Reason, why this isn't fixed is, It can be problematic in combination with thread scheduling and prioritization at particular plugin host and while it can lead to higher performance with long operation buffers, it can be conversely much more prone to drop outs with short buffers, when overal latency is needed. So cure can be worse than disease in particular combination and if one really needs beefy VSTi with low latency, then CPU with good single core performance is required.
However even with regards to those plugins I don't think, running that in separate process will inherently solve possible issue with running crossing of CCX boundary (assuming it can play some role there, which isn't really given for all cases), because it would require also additional setting of affinity for that particular standalone worker process to cores at one CCX, otherwise this process will be scheduled by OS over all available cores and it doesn't eliminate anything.

Michal
Old 14th June 2017
  #43
Lives for gear
 

I agree that it's a terrible idea for day to day running, but not for what I am thinking about which is shared memory.

If you have 1000 plugin instances all accessing the same memory addresses because they are aware of each other (with statically declared objects), the processor shouldn't need to cache after the first time in these benchmarks since it is getting accessed by every plugin. Which leaves Ryzen doing cross CCX accesses. Running them in individual/dedicated processes should stop this, since the plugins will then not be aware of each other (since using IPC for plugins running in other processes to share a bit of memory would be wasteful) and the memory addresses used by formerly shared variables/objects will be unique.

This should eliminate potential cross CCX access issues. The first bit of positive evidence would be that memory usage goes up (edit: that's not accurate, memory will go up with the wrapper in any case). The second would be that overall plugin count goes down, but less so on Ryzen.

As I say, I'm not recommending this as a solution but to see if this is what the problem is with the plugins tested - remember not all the plugins - that show this behaviour.

Last edited by captain caveman; 14th June 2017 at 10:26 PM..
Old 14th June 2017
  #44
Lives for gear
 

Hmm.. I see, what you're trying to tell, but still there are lot of ifs...
Anyway if that's just for some testing, you'll add another variables (IPC, increased memory consumption) there, so it won't be comparable to obvious baseline, which is normal (threaded) mode.
If I'd like to know, whether particular workload with some effects is being affected by that CCXs crossing due to cache sharing, then I'd simply create two Reaper launcher shortcuts with PSExec. The first with process affinity set just to single CCX, the second with affinity across both CCXs.. it doesn't necessarily has to be full core count, two should be enough to reveal, if that matters or not and you can save lot of plugin instances before you'll hit the ceiling.
That test procedure is enough to fully isolate the issue IMO.

If someone find, that this can theoretically matters for some heavy instruments or FX chains for instance.. It's possible to further test Reaper and local ReaMote (or VEP), where each one will be isolated to its own CCX and affected plugin chains could be offloaded to ReaMote. However I don't think, even if that would be the problem, performance gain would outweigh hassles with added latency and taking care about where to run each FX chain during project.

Michal

Last edited by msmucr; 14th June 2017 at 11:28 PM..
Old 14th June 2017
  #45
Lives for gear
 

Yes, your solution is better. In Reaper you can actually play with processor affinity live - so changes take immediate effect without restart - in...

Preferences -> General -> Advanced UI/System tweaks -> Restrict REAPER to specific CPUs

So 0 -> 7 would be on one CCX and 8 -> 15 would be on the other. Testing for example 0,1,2,3 vs 0,1,7,8 would do it.

Re practical solutions, I am thinking more in terms of what a dev might do for Ryzen performance. I suppose somebody might run VEP with the affinity set to one CCX and Reaper set to the other. On that subject, VEP uses IPC so it's not a no go area because performance concerns when we are not talking about changing 1000s of plugins to use it simultaneously for testing purposes.
Old 15th June 2017
  #46
Gear Maniac
 

Thread Starter
If someone else with a Ryzen machine wants to run your preferred test that's cool (or if you have a Ryzen machine and want to test it ) but these tests do take a long time to run and I'm honestly not interested in running tests that don't model real world performance.

An end user wouldn't bother making these kinds of adjustments, so I wouldn't either in my testing. This is also why I clocked memory speed as high as I could on both platforms rather than making them identical (later testing however showed memory speed made no difference anways). I really wanted these tests to show the kind of performance you'd see from entering into the market right now as a normal end user, and part of that includes taking in all of the growing pains of x370 as a brand new platform.
Old 15th June 2017
  #47
Lives for gear
 

Of course, the question is there for anybody with a Ryzen who is curious about the discrepancies we are seeing. If it is indeed the case that this is the issue then the average end user wouldn't find double clicking a bat file too technical to nearly double the performance of their system before engaged developers update their plugins.
Old 15th June 2017
  #48
Lives for gear
 

@captain caveman
You're true with Reaper internal affinity settings, I didn't recall that dialog. I'm just used to PSExec for generic adjustments of affinity or priority at program launch, when I needed that.. I used is for instance, when I did some machines for video streaming, where priority setting and isolation to particular cores was beneficial with other running programs.
With regards to what devs should do mostly depends at their existing software. However with regards to common plugins, many of them are already pretty heavily optimized at critical parts with explicit use of vector instructions, proper alignment, shortest possible loops. This generally works for any current CPU, I don't really think, there will be some magic formula for performance boost at AMD chips. With regards to plugins with processing in multiple threads, as I've said, it's rare and potentially problematic and only thing, which can be done there, is some runtime detection of used chip and attempt for explicit scheduling to single CCX. While this might work at some sole running standalone application, it's can be can of worms to do that when running as plugin in the environment, which has its own affinity and thread priority management, because it can lead to bad core allocation and overloads. There's no standardized (in common plugin formats) way for exchanging information about that.. basically it's responsibility of plugin host via its workers, whose has to be correctly managed with other DAW threads.. in more holistic picture of course with OS, which schedules its other important tasks.
In general, I can see some kind of initial wishful thinking, further optimization significantly improve performance. Zen seems to be general success for AMD after previous architectures, but I don't really believe that in this particular case, we can expect some overall improvements.. Of course I can be wrong and if you'll find some obvious performance gap caused by CCXs crossing, then share that with us and developer of used software.

@PrismaPhonic
I see, and didn't really expect, you'll be doing such CCX tests. I was just replying in general sense to Captain's testing ideas..

Michal
Old 15th June 2017
  #49
Lives for gear
 

Quote:
Originally Posted by msmucr
With regards to what devs should do mostly depends at their existing software. However with regards to common plugins, many of them are already pretty heavily optimized at critical parts with explicit use of vector instructions, proper alignment, shortest possible loops. This generally works for any current CPU...
I completely agree with this, I am not talking about CPU optimisation or plugins that create multiple threads though. I am thinking specifically of usage of static vs non-static objects and how accessing static/shared methods and/or data objects many times per plugin/channel/voice within a processing block could perhaps create a time overhead with cross CCX cache accesses. Which might also explains the scaling getting better as buffer sizes increase in affected plugins, as well as not all plugins being affected.

I don't know, it's a guess but I think an okay one. But maybe there is very little additional latency (this is not necessarily a bandwidth/memory speed thing) involved and it's something else.
Old 15th June 2017
  #50
Quote:
Originally Posted by PrismaPhonic View Post
It is not confusing. Literally NO ONE represents statistics in that way. Go look at any number of peer reviewed studies. Saying that Intel has a 153% performance advantage over AMD is clear as day. I said that reaper had a 360% performance advantage over Ableton. That obviously means that it performed 3.6 times better. Anyone who has ever done statistical analysis understands this is how you are supposed to represent data.

Will not argue this anymore because this is really dumb. I won't correct the video, there is nothing wrong with how I'm representing the data. This is exactly how it should be represented.
Slightly late to the game, but someone here has to drink beer....

Not that it is very important for this thread IMO as I think everyone gets the point correctly nevertheless, but I do agree with Mattias that claiming a 153% increase is wrong to say. It is correct to display a graph with 153%, but it is called a 53% increase, as 100% is the starting point which you compare to. A performance which also lands at 100% isn't a 100% increase, it is equal.

Just my humble knowledge, I don't want to open a can/worms discussion.
Old 15th June 2017
  #51
Semantics:

15 is 50% more than 10.

But also:
15 is 150% of 10.

Just use the right words and it's all dandy

Last edited by thedberg; 15th June 2017 at 04:17 PM..
Old 15th June 2017
  #52
Lives for gear
 

Quote:
Originally Posted by DAW PLUS View Post
Just my humble knowledge, I don't want to open a can/worms discussion.
Old 15th June 2017
  #53
Something purry is missing...
Old 15th June 2017
  #54
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by captain caveman View Post
Of course, the question is there for anybody with a Ryzen who is curious about the discrepancies we are seeing. If it is indeed the case that this is the issue then the average end user wouldn't find double clicking a bat file too technical to nearly double the performance of their system before engaged developers update their plugins.
Problem I see here is that some are not interested in anything past data that shows Ryzen in a better light, and we end up in these cyclic debates when ever there is a result showing otherwise. Is it the DAWbench methodology that is flawed, is it the plugins being used, is it code / thread optimization within the DAW's , is it all of the above.

Dont get me wrong, I'm actually enjoying the discussion between you and Michal , but realistically what end user is going to be bothered engaging in hacks to minimize cross CCX access/arbitration if that is in fact the issue to work around. My professional clients dont have time for that , they just need a working solution that maintains the focus on the creative process, not fussing over semantics to argue % variables over $ investment for a workstation solution that will be insignificant over the deployment life cycle of 3-5 to 7 years that I am seeing currently.

What ever the issues being navigated with the Ryzen, if it is fact associated with the CCX crossing , will only be even further pronounced with Threadripper ( who the Hell names these things) as its simply more of the same , 3 or 4 CCX modules interconnected and arbitrated in the same manner. Threadripper could well turn out to be a ThreadTripper , for want of a cheesy play on words.

FWIW, I am in the process of finalizing some new DAWbench test sessions with additional freeware plugins that can be used to cross reference results with, they are already in the hands of some close colleagues and also some tech reviewers , so we could get a better idea of variables associated with plugin coding compiling. I have only tested on Intel so far.


Last edited by TAFKAT; 16th June 2017 at 01:30 AM..
Old 16th June 2017
  #55
Lives for gear
 

Quote:
Originally Posted by TAFKAT View Post
Problem I see here is that some are not interested in anything past data that shows Ryzen in a better light, and we end up in these cyclic debates when ever there is a result showing otherwise. Is it the DAWbench methodology that is flawed, is it the plugins being used, is it code / thread optimization within the DAW's , is it all of the above.

Dont get me wrong, I'm actually enjoying the discussion between you and Michel....
These are very interesting questions though. I've been Intel since not long after you and I last exchanged emails several years back re early DAWbench testing on an old X2 4400 or whatever it was at the time. There is 0% (that's an increase of 100%) wrong with digging into what potential issues might be at play here and what the solutions might be.

The very second there are no more questions to ask, I'll stop asking them!
Quote:
... but realistically what end user is going to be bothered engaging in hacks to minimize cross CCX access/arbitration if that is in fact the issue to work around. My professional clients dont have time for that , they just need a working solution that maintains the focus on the creative process, not fussing over semantics to argue % variables over $ investment for a workstation solution that will be insignificant over the deployment life cycle of 3-5 to 7 years that I am seeing currently.

What ever the issues being navigated with the Ryzen, if it is fact associated with the CCX crossing , will only be even further pronounced with Threadripper ( who the Hell names these things) as its simply more of the same , 3 or 4 CCX modules interconnected and arbitrated in the same manner. Threadripper could well turn out to be a ThreadTripper , for want of a cheesy play on words.
I have to play an Apex Fallacy card here, since only a relatively a small percentage of users - especially non-professional ones - actually go for anything above an i7 quad core. In this test there is a water cooled i7-6900k (for sensible reasons, because it runs unprofessionally hot at those clock speeds) vs an air cooled Ryzen. So I'll raise your AMD apologist insinuation with a generally directed, tad too forgiving Intel aficionado probe.

Re more CCXs, that's only a problem if there is an insurmountable issue. If it turns out that there is something identifiable that can be optimised then a small change in coding practises for plugin and/or DAW devs alike could be all that's required. And/or a bat file, whatever the case may be to get $1100 (inc mobo) performance for $380 (that's an amortized % stress minimisation of 2791 quiftboggles (that's taken from the Journal of Applied Physics (okay, okay I'll stop (it's actually from my P6 primary school jotter (okay, I'll really stop now))))).
Quote:
FWIW, I am in the process of finalizing some new DAWbench test sessions with additional freeware plugins that can be used to cross reference results with, they are already in the hands of some close colleagues and also some tech reviewers , so we could get a better idea of variables associated with plugin coding compiling. I have only tested on Intel so far.

Cool, I look forward to results and hope you look forward to some more questions!
Old 16th June 2017
  #56
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by captain caveman View Post
These are very interesting questions though. I've been Intel since not long after you and I last exchanged emails several years back re early DAWbench testing on an old X2 4400 or whatever it was at the time. There is 0% (that's an increase of 100%) wrong with digging into what potential issues might be at play here and what the solutions might be.
They are interesting questions , and we will no doubt be investigating as much as we can moving forward. Having said that, it does get tiring when the dots keep getting shifted by some , this is not directed at you btw.

For example DAWbench only becomes a problem if AMD's do not perform as expected , then its been a witch hunt in the past and even recently into some conspiracy on my part and my trusted testing partners to sway the testing parameters to suit Intel ? ! I personally find those accusations quite entertaining actually, as I have no knowledge ( thats 0%) at that code level to even attempt it , but there is a 100% chance some will continue to find their own truth no matter what is presented.

Quote:
The very second there are no more questions to ask, I'll stop asking them!
We will be here for a while then I suspect :-)

Quote:
I have to play an Apex Fallacy card here, since only a relatively a small percentage of users - especially non-professional ones - actually go for anything above an i7 quad core.
Horses for courses, since the Ryzen launch I have sold an increased % of i7 6900 and 6950's than prior, actually 80% + of my total sales. Not really sure what that is saying past I obviously have a different client demographic that comes to me for solutions.

Quote:
So I'll raise your AMD apologist insinuation with a generally directed, tad too forgiving Intel aficionado probe.
Touche , LOL !

Quote:
Re more CCXs, that's only a problem if there is an insurmountable issue. If it turns out that there is something identifiable that can be optimised then a small change in coding practises for plugin and/or DAW devs alike could be all that's required. And/or a bat file, whatever the case may be to get $1100 (inc mobo) performance for $380 (that's an amortized % stress minimisation of 2791 quiftboggles (that's taken from the Journal of Applied Physics (okay, okay I'll stop (it's actually from my P6 primary school jotter (okay, I'll really stop now))))).
I do have to tip my hat to your optimism, but I suspect it might more akin to wishful thinking, but who knows, lets see where the dust settles.

Quote:
Cool, I look forward to results and hope you look forward to some more questions!
I'm all ears , and have my biosuit and goggles at the ready.


Last edited by TAFKAT; 16th June 2017 at 08:28 AM..
Old 16th June 2017
  #57
Lives for gear
 

Quote:
Originally Posted by msmucr View Post
This is not really related to some upcoming products, you can already do that.. and I believe, for the majority of people here (eg. non-professionals) the price/value ratio is major attribute for their decision. So pricewise R7 1800X is comparable rather to 6800K or 6850K.

Anyway there is always something behind the corner.. for someone it is Threadripper, for others it can be i9. It will never stops.. whenever you look for hardware, you'll always find some recommendation to wait for some forthcoming product.



I don't really get that.. Well if someone relies on Fruity Loops, he likely works at PC.. If someone has complete Mac based environment, then he will likely consider lot of another factors than just sheer CPU power.
Other thing is that core count mantra 8>6, 6>4, 18 kill-em-all.. doesn't really applies to all situations.

Michal

Ponting to this video on YT
https://www.youtube.com/watch?v=xama-Np0yKo

FL is very popular in the gaming community for music production.
Guess their systems will fly on threadripper for a fraction of cost compared to what Apple will deliver in december. Tamed my lust for the actual iMac.
Old 16th June 2017
  #58
Lives for gear
 

Quote:
Originally Posted by lllubi View Post
Ponting to this video on YT
https://www.youtube.com/watch?v=xama-Np0yKo

FL is very popular in the gaming community for music production.
Guess their systems will fly on threadripper for a fraction of cost compared to what Apple will deliver in december. Tamed my lust for the actual iMac.
And how is FL performance is related to Macs..?
Why to consider some Ryzen setup as iMac alternative at first place.

Again, when someone works in FL, he has a PC (although it's for forever in alpha version for Mac), so he don't need to consider iMac as all, unless he'd buy it to run bootcamped Windows, which frankly doesn't make much sense. So he can already buy any PC configuration regardless of current or forthcoming Apple product line-up. If he likes Ryzen for its power/price ratio and appreciate lots of cores for his work.. well.

Similarly, when someone has his workflow based on Logic, he likely don't need to care about some Ryzens and it's performance characteristics at all, until Apple makes some computer with it (unlikely to me in close future).

Michal
Old 16th June 2017
  #59
Quote:
Originally Posted by lllubi View Post
Ponting to this video on YT
https://www.youtube.com/watch?v=xama-Np0yKo

FL is very popular in the gaming community for music production.
Guess their systems will fly on threadripper for a fraction of cost compared to what Apple will deliver in december. Tamed my lust for the actual iMac.
Actually I think the 7700K is doing pretty well in that comparison. The 1800X is approx 30% more expensive (here, street price) and has half the amount of cores.

I do conclude based on *just looking at the stats* that I would pick the 1800X here for that 130€ extra, but I have not seen low latency figures which is where Ryzen has its weak spot.
Old 16th June 2017
  #60
Lives for gear
 

Quote:
Originally Posted by DAW PLUS View Post
Actually I think the 7700K is doing pretty well in that comparison. The 1800X is approx 30% more expensive (here, street price) and has half the amount of cores.

I do conclude based on *just looking at the stats* that I would pick the 1800X here for that 130€ extra, but I have not seen low latency figures which is where Ryzen has its weak spot.
You maybe missed the graph from the Fausta demo at 128 samples buffer.
I wouldn´t call a Ryzen at 4Ghz vs an Intel at 5Ghz weaker in latency.
New Reply Submit Thread to Facebook Facebook  Submit Thread to Twitter Twitter  Submit Thread to LinkedIn LinkedIn  Submit Thread to Google+ Google+  Submit Thread to Reddit Reddit 
 
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump