121–126 of 126 posts
Earlier quoted context omitted.
You don't trust the presentation demo AMD made a few weeks ago ?
No. I trust independent comparisons a lot more than I would ever trust the company making the product.
Earlier quoted context omitted.
No. I trust independent comparisons a lot more than I would ever trust the company making the product.
I think the benchmarks shown by amd can be trusted. But they are very very cherry picked, example the demonstration they did when they released the rx480
Earlier quoted context omitted.
I think that's why so many people go with the older HP microservers. Super cheap, nice form factor, just add ECC RAM and HDDs.
I have an HP MicroServer N40L that I bought several years ago, and it's almost a doorstop now. Its CPU (dual-core 1.5 GHz AMD Turion II Neo) is slow and doesn't support AES-NI. It maxes out at 8 GB of RAM (16 GB of RAM if the stars align and it likes the RAM you bought). It has one GigE port, and SATA ports are limited to 3 Gbps (SATA II). Expansion is limited to an eSATA port, USB 2.0 ports, a low-profile PCIe 2.0 x…
Of course it always depends on the use-case, but for most people at home it's sufficient. I use it as a Minecraft and media server.
Earlier quoted context omitted.
"SLI doesn't scale beyond 2 cards" Guess you weren't around in the days of Quad VooDoo 2 GPU rigs. They most certainly did scale. nVidia and AMD's implementation? Nope. They screwed the pooch with that one and will never recover until they learn that the older way was indeed better.
SLI only matters for gaming - which is outside of the scope of my argument. Regardless, it looks like 3Dfx SLI wasn't that great[1] and I did own a Diamond Monster 3D II. [1]: http://www.tomshardware.com/reviews/diamond-monster-3d-ii,52...
And if your dataset or code is GPU-capable, then no, SLI is quite useful here.
"Only matters for gaming" Yea, as if there weren't a bunch of other datasets that could utilize matrix acceleration.
Earlier quoted context omitted.
"The proof of a CPU is in how it benchmarks across real workloads." Define 'real workload' here. Are we talking about a workload where the compiler specifically optimizes for Intel, or where the executable chooses unoptimized paths if it finds anything other than intel processors inside? Because I've found that when it comes to raw x86, no SSE anything or other nonsense; pure, unadulterated original x86, AMD simply o…
Because I've found that when it comes to raw x86, no SSE anything or other nonsense; pure, unadulterated original x86, AMD simply owns. Who cares, though? Is that something that matters?
Earlier quoted context omitted.
"The proof of a CPU is in how it benchmarks across real workloads." Define 'real workload' here. Are we talking about a workload where the compiler specifically optimizes for Intel, or where the executable chooses unoptimized paths if it finds anything other than intel processors inside? Because I've found that when it comes to raw x86, no SSE anything or other nonsense; pure, unadulterated original x86, AMD simply o…
Other nonsense? These additional instruction sets aren't just a gimmick, they exist to do more work faster. But my definition of two workload really just means a spectrum of different sorts of computation so we can see how various subsystems compare.
They don't really work much faster when the basic stuff in the core architecture is gimped (low-count ADD/MULTIPLY units? In this day and age of cheap silicon? Really?)