<span style="font-family: Arial; font-size: 13px;">The only thing I'd add for reference is that in high performance computing, the default is to disable virtual threads (e.g., hyper-threads) as they actually slow down things otherwise. Under normal execution, having more CPU threads available is a good thing, but not if the application needs a lot more out of the CPU. The biggest time issue is actually not the CPU, but memory access. In anything that really pushes the system, like when you perform parallel calculations (e.g., openmp), you simply don't want virtual threads anywhere. As far as I know, all super computer disable virtual threads by default. Each case could vary, but this is something to test for. And in the case Erlang, I'd try with/out to see what results you get. If possible, I'd disable the virtual threads and try CouchDB again.<br><br>Cheers,<br>Alex<br><br>On 1/4/2018 at 12:58 PM, "Eric des Courtis" <eric.des.courtis@gmail.com> wrote:<blockquote style="border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;"><div dir="ltr">+1 for Threadripper or Ryzen Pro</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 3, 2018 at 7:48 PM, Grzegorz Junka <span dir="ltr"><<a>list1@gjunka.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;margin:0 0 0 .8ex;"><div class="HOEnZb"><div class="h5"><br>
<br>
On 03/01/2018 08:21, Iblis Lin wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;margin:0 0 0 .8ex;">
forgot to CC the list.<br>
<br>
<br>
On 01/03/2018 01:21 PM, Iblis Lin wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;margin:0 0 0 .8ex;">
well, purchasing decision is up to you, but I want to share my personal<br>
experience:<br>
<br>
I will vote -100 for the Ryzen build. For me, the term "Ryzen" means<br>
malicious trolling.<br>
<br>
It wasted my time and mental efforts.<br>
<br>
I will show you my journal:<br>
<br>
- I set up the Ryzen box in 2017/5. Mine is 1700 (8 cores 16 threads).<br>
<br>
- I install Arch Linux, ran CouchDB on it... and found the machine<br>
crash and reboot regularly in an interval of 2-3 days.<br>
<br>
- I also tried to build mainline kernel, (at that moment, it's 4.12<br>
IIRC), not work , still crashing or freezing.<br>
<br>
- Another test: disabling all deamon, the box can be alive over a week.<br>
<br>
- Changing memory module in 2017/6, not work.<br>
<br>
- 2017/9 I RMA-ed it.<br>
<br>
- After RMA, it still keeps crashing, hard freezing, soft freezing...<br>
within 3-6 hr if I run something on it.<br>
<br>
the kill-ryzen script DOES kill my box, even it's the new CPU back<br>
from RMA.<br>
<br>
The *improvement* is the crashing interval shrunk. Thank you AMD.<br>
<br>
- 2017/10, I changed my OS from Arch to Ubuntu. not work.<br>
<br>
<br>
On 01/03/2018 06:46 AM, Adam Rutkowski wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;margin:0 0 0 .8ex;">
Hey all,<br>
<br>
I'm thinking of building a Ryzen machine, mainly for Erlang development. There's this rather obscure bug with some Ryzen processors on Linux/BSD [1] and I'm worried I might be getting a unit from the faulty batch; I have no means of verifying this before purchasing from my local suppliers. I'm wondering if I should I expect any issues with Erlang VM doing the multi-core heavy lifting.<br>
<br>
Cheers<br>
<br>
[1]: <a target="_blank" href="https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response" onclick="window.open('https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response');return false;">https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response</a><br>
<br>
<br>
</blockquote></blockquote></blockquote>
<br></div></div>
Interestingly, it's not that not choosing Ryzen guarantees you a worry-free reality:<br>
<br>
<a target="_blank" href="http://www.dailymail.co.uk/sciencetech/article-5232037/Security-flaw-Intel-chips-past-decade.html" onclick="window.open('http://www.dailymail.co.uk/sciencetech/article-5232037/Security-flaw-Intel-chips-past-decade.html');return false;">http://www.dailymail.co.uk/sciencetech/article-5232037/Security-flaw-Intel-chips-past-decade.html</a><br>
<br>
Arguably 50% slowdown or a security flaw is better than a random crash. But maybe the real lesson is to choose a processor that doesn't have any known vulnerability so far, e.g. Threadripper or a dedicated server processor?<br>
<br>
GrzegorzJ<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a>erlang-questions@erlang.org</a><br>
<a target="_blank" href="http://erlang.org/mailman/listinfo/erlang-questions" onclick="window.open('http://erlang.org/mailman/listinfo/erlang-questions');return false;">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></blockquote></span>