AMD Zen/Ryzen thread

wrc1944 · Posted: Wed Feb 15, 2017 7:35 am Post subject:

AM4 boards are showing up for pre-order.

http://vr-zone.com/articles/amd-am4-motherboards-pre-order-australia-prices-revealed/122022.html

Marlo · Veteran Joined: 26 Jul 2003 Posts: 1591

Hi@

Does anyone knows when linux will support Ryzen and x370?

THX
MA
_________________
------------------------------------------------------------------
http://radio.garden/

NeddySeagoon · Posted: Wed Feb 15, 2017 8:12 pm Post subject:

Marlo,

It already does. You need gcc-6.x though, which is hard masked in portage as some things won't build correctly with it.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Marlo · Veteran Joined: 26 Jul 2003 Posts: 1591

NeddySeagoon!
Thanks a lot for the quick reply.

But in linux-kernel do we have the options for the processor and the mainbord?

THX
Ma
_________________
------------------------------------------------------------------
http://radio.garden/

wrc1944 · Posted: Thu Feb 16, 2017 1:11 am Post subject:

I would think march=native will cover the Ryzen cpu, and i do recall some new gcc flags listed in gcc-6.x.x.

wrc1944 · Posted: Fri Feb 17, 2017 5:32 pm Post subject:

FWIW: AMD Ryzen 5 1600X Leaked Benchmarks Analyzed, Faster Than Intel’s Fastest 6 Core (both the single and multi-core CPU-Z benchmarks)

http://wccftech.com/amd-ryzen-5-1600x-leaked-benchmarks-analyzed-faster-intels-fastest-6-core

Tony0945 · Posted: Tue Feb 21, 2017 12:54 am Post subject:

wrc1944 · Posted: Tue Feb 21, 2017 6:08 am Post subject:

Not exactly sure what that output of your grep -ri fam17 command means, but at least we know some fam17h stuff is now showing up in kernel-4.10.0.

When I compiled 4.10.0 I didn't see anything zen related in make xconfig. Guess they haven't added zen to the gcc-opts patch yet. But even if they don't, wouldn't "native" still cover it?

I had wondered about the "zenbook," so I looked it up and the Asus Zenbook is a high performance very expensive Intel i5-i7 based laptop. Nothing to do with AMD Zen cpus. If they somehow also have an AMD Excavator Bristol Ridge model on an AM4 mobo, I can't find it.

http://store.asus.com/us/category/A18489

wrc1944 · Posted: Tue Feb 21, 2017 11:28 pm Post subject:

Here's some good news:

stephan-t · Tux's lil' helper Joined: 12 May 2014 Posts: 122

I can't wait for Ryzen based APUs. Think about, the first revision or stepping also bugles?

wrc1944 · Posted: Wed Feb 22, 2017 7:47 pm Post subject:

AMD Ryzen Officially Launched, Brings A Mammoth 52% IPC Increase – 8 Core, 16 Threaded Processors Starting at $329 US With Pre-Orders Today, AM4 Board Prices Detailed

AMD Ryzen Officially Launched – More IPC Gain Than Originally Promised, Highly Competitive Pricing

The launch of Ryzen begins a fresh new start for AMD by bringing a highly competitive x86 architecture to the market. The launch took place at a “Tech Day” event which was generally aimed at editors but it was decided to release the details to the public due to a great amount of hype surrounding Ryzen. Starting today, AMD Ryzen processors will go on pre-order through several retailers and officially hit the market on 2nd March, 2017.

This looks like it's really here, a bit early.

Ryzen CPU Pre-Order LInks on Amazon (1800x 1700x) & Newegg: https://www.newegg.com/Product/Product.aspx?Item=N82E16819113430 Plus 180 other retailers worldwide (said Lisa Su)
http://wccftech.com/amd-ryzen-7-1800x-1700x-official-launch

AM4 mobos pre order: https://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&Description=am4&ignorear=0&N=100007625&isNodeId=1
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.40-r5, gcc-14
kernel-6.11.3 USE=experimental python3_12.7-final-0

Tony0945 · Posted: Wed Feb 22, 2017 9:23 pm Post subject:

And finally on the Gigabyte web site, however buried deep. Look under "chipsets: other"
http://www.gigabyte.us/Comparison/Result/2?pids=6166,6167,6225,6227

No PCI from Gigabyte but a board with TWO PCI slots from MSI AND with Intel LAN! Is the "killer" supported by the Linux kernel? Oh well, I do have already an Intel PCIe card. How about the ALC1220 Audio chip? ALC 887 is an old standby and is good enough for non-audiophiles.

If I do have to retire the HVR-1600, this card is supposed to be supported in the kernel: https://www.amazon.com/dp/B01DZSVLTW/ref=wl_it_dp_o_pC_nS_ttl?_encoding=UTF8&colid=2SM2N0CZN0R9S&coliid=I1W6XDPZGSQXY6&psc=1

I'm rather disgusted that one of the boards on newegg already has a 5 egg review even though it's only pre-order.

EDIT: B350 boards surprisingly cheap. I have no need for fancy graphics. $600 for an 1800X and mobo. Less than many Intel chips alone. But not offered with cooler so I guess it's the $100 Noctua after all.

EDIT2: Corrected tv card model number.

EDIT3: Gigabyte now has AM4 fully integrated into their website. I see nothing at the MSI & Biostar websites

wrc1944 · Posted: Thu Feb 23, 2017 5:45 pm Post subject:

On the newegg site, these AsRock boards have the very detailed specs fully listed under the specs tab, but biostar and others only have a bare minimum shown. It looks like it's still hit or miss on getting the full picture on some brands- even at their own web sites. Links for each AsRock for convenience:

https://www.newegg.com/Product/Product.aspx?Item=N82E16813157759&cm_re=pre_order_asrock_am4-_-13-157-759-_-Product

https://www.newegg.com/Product/Product.aspx?Item=N82E16813157757&cm_re=pre_order_asrock_am4-_-13-157-757-_-Product

https://www.newegg.com/Product/Product.aspx?Item=N82E16813157756&cm_re=pre_order_asrock_am4-_-13-157-756-_-Product

https://www.newegg.com/Product/Product.aspx?Item=N82E16813157761&cm_re=pre_order_asrock_am4-_-13-157-761-_-Product

https://www.newegg.com/Product/Product.aspx?Item=N82E16813157758&cm_re=pre_order_asrock_am4-_-13-157-758-_-Product

FWIW, I've built with a few AsRock boards in the past, and they were aways first rate.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.40-r5, gcc-14
kernel-6.11.3 USE=experimental python3_12.7-final-0

wrc1944 · Posted: Fri Feb 24, 2017 4:39 am Post subject:

http://wccftech.com/amd-ryzen-7-1700-overclocked-4ghz

Some independent testing is now coming in, and it looks very encouraging.

wrc1944 · Posted: Mon Feb 27, 2017 7:43 am Post subject:

FWIW, even though cpu-world.com has as yet no Ryzen info in its regular news, it does have a nice little feature where you can get a side-by-side comparison of any 2 cpus in its data base, which surprisingly does include some Ryzen info.
http://www.cpu-world.com/CPUs/Zen/AMD-Ryzen%207%201700X.html (scroll down to enter the cpu you wish to compare with)

For example, my FX-8320 vs. Ryzen 7 1700x
http://www.cpu-world.com/Compare/986/AMD_FX-Series_FX-8320_vs_AMD_Ryzen_7_1700X.html

Also, I'm wondering about that with the new Ryzen threading (8c/16t) as opposed to all previous AMD products, would this affect our Gentoo MAKE_OPTS= setting? In other words, will the 1700x actually utilize -j16 instead of the normal setting of -j8 (or -j9) for the 8 core FX-8320?
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.40-r5, gcc-14
kernel-6.11.3 USE=experimental python3_12.7-final-0

NeddySeagoon · Posted: Mon Feb 27, 2017 10:20 am Post subject:

wrc1944,

It all depends on what the new limit for throughput becomes.
I would expect to see MAKEOPTS increase though.

To avoid swapping, allow between 512Mb and 1G RAM per gcc thread. That is, >16G RAM if you want to try MAKEOPTS="-j16"
Then there is the phenomena called "cache thrashing" which you see when older but still needed data in the CPU cache is displaced to make room for new data. It subsequently has to be fetched from (comparatively) slow RAM.

There is no ideal MAKEOPTS setting. Test on a few things that will run a massively parallel make. Like the kernel and glibc.
There comes a point where bigger MAKEOPTS will slow down the build. That point is different for different packages.

One thing is for sure, don't build a 16 threaded Gentoo box with less than 32G RAM.
2x16G sticks looks like a good start, then you can add the other two later without removing existing RAM.
The prices make your eyes water just now.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

wrc1944 · Posted: Mon Feb 27, 2017 10:58 am Post subject:

Neddy,
Thanks much for the info- very informative. I was going for my now standard 16GB ram, so your feedback in my case is really helpful.

Thought I'd add these relevant items I just saw:
Feb. 26- latest Phoronix info/discussion/advice on Ryzen kernels. http://www.phoronix.com/scan.php?page=news_item&px=AMD-Ryzen-Newer-Kernel They will have a new round of testing in the near future.

Zucca · Posted: Mon Feb 27, 2017 12:57 pm Post subject:

wrc1944 · Posted: Mon Feb 27, 2017 6:15 pm Post subject:

Zucca,
I think Neddy means the "cache thrashing" refers to the actual on-die L1,L2, or L3 cpu caches, which are of course defined on limited areas on the cpu itself. When those caches become saturated, the processor has to unload something to the RAM in order to free up room for more critically needed data when it's requested.

Doing so would obviously slow things down, being somewhat analogous to how RAM has to temporarily swap out its least critical data to a hard drive when it becomes saturated.

Given that the on-die L1,L2, or L3 cpu caches are finite, I don't believe that if they become completely filled and then need to utilize more critical data there is any other option except to swap something out to RAM, and thus free up space on a cpu cache, which would be "cache thrashing."

In other words, AFAIK there is no apparent way to help avoid "cache thrashing" once your on-die caches are filled, and more essential data is requested. At least that's my current thinking, but of course I could be wrong, as I had never thought about "cache thrashing" in CPU terms before Neddy mentioned it.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.40-r5, gcc-14
kernel-6.11.3 USE=experimental python3_12.7-final-0

Zucca · Posted: Mon Feb 27, 2017 6:45 pm Post subject:

NeddySeagoon · Posted: Mon Feb 27, 2017 8:14 pm Post subject:

Zucca,

That's not what -pipe does.

gcc runs in multiple passes. -pipe tells gcc to keep the intermediate files (between passes) in RAM if it can.
If not, they are written to disk in the normal way. Using -pipe is harmless. Omitting it may cause unnecessary disk writes that may never be read, since the kernel will keep things around in buffers as long as it can.

I'm not sure CPU 'cache thrashing' is the issue it was when CPU caches were smaller.
It was easy to detect at run time. Packages built with -O3 ran slower than the same package built with -O2.
-O3 makes the code bigger to try to make it faster. Then the working set wouldn't fit in the CPU cache.
-O2 made smaller code but with more branch instructions (that do not contribute to code doing useful work) but the working set fitted in the CPU cache, so it was faster.
Modern CPUs do prefetch too, to improve cache hits.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

wrc1944 · Posted: Mon Feb 27, 2017 9:04 pm Post subject:

This is great stuff to know about- thanks for all the input. I'm learning a lot, and am thinking more about factors I hadn't really paid much attention to.

Neddy,
is the cpu prefetch enabled by default, or does it need to be enabled in kernel, or somewhere in an /etc/ file, such as the kde prefetch is (was?)?

I did have the kde prefetch enabled years ago, but IIRC I read somewhere it could cause problems, and I think I disabled it at some point, but couldn't tell any difference in kde performance either way. Maybe my usage profile wasn't enough to push the limits, so I wouldn't ever noticed it anyway?

I'm assuming today's larger cpu caches would make cache thrashing less likely to happen, and thanks for the -pipe and gcc clarifications.

Guess we will have a slight learning curve on tweaking our settings for Ryzen/AM4 hardware.

Hope this is not too much off topic, but does anyone know if the cpu caches keep data loaded only as long as it's really needed, or has a timed limit as a hedge against possibly needing it again, or a strict timed limit for only certain types of data, or any other scheme(s) that pre-ordain how all this works in practice. Wouldn't all this type stuff be spelled out in the cpu instruction sets? (Obviously, I too an no low-level expert).
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.40-r5, gcc-14
kernel-6.11.3 USE=experimental python3_12.7-final-0

NeddySeagoon · Posted: Mon Feb 27, 2017 10:15 pm Post subject:

wrc1944,

The whole idea of the cache RAM is to be invisible and make it look like it represents the entire addressable memory space, so that a cache hit happens as often as possible.
A cache miss means a stalled CPU pipleline while the data/instruction is fetched from RAM, time wise, that's expensive.

Modern CPUs do program (thread?) flow prediction for pre fetch and branch prediction. There is nothing special you need do.

Some systems allow you to turn off the CPU cache. That's a once in a lifetime experiment because its something you never forget.

Cache management is a complex subject. Its not just the CPU that needs to know what's in the cache.
Consider the following.
The CPU does a write. The write is only in the cache, its not yet been written back to RAM.
Now the DMA system wants to transfer the contents of that location to disk. If it uses the RAM location, it will hold the wrong value.
Even weirder, what about self modifying code, there's not a lot of it around any more but it was popular on early systems to make the code more compact.
The CPU treats the contents of the same RAM address as data at some time and code at another time.
The CPU changes the data and writes it to the data cache (many CPUs have separate data and instruction caches) then tries to execute it as an instruction before its written back to RAM.
All these things work correctly or you have a hardware bug.

The Wikipedia page will make your head hurt.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Zucca · Posted: Mon Feb 27, 2017 11:53 pm Post subject:

Thanks for all the info Neddy.

You spoke of disabling of CPU cache... I'd guess that would make everything much slower?
_________________
..: Zucca :..