Skip to main content

x86_64 vs ARMv8

Photo by Brian Kostiuk on Unsplash
Things are getting interesting in the SPO 600 course. It’s time to get familiar with modern processor architectures: the x86_64, which powers all most everything today and the new ARMv8 that is gaining traction mostly because of its energy efficiency. Also, for the first time, we will “forget” assembly and focus on the compiler.

So, what is the difference between x86_64 and ARMv8?

Making a processor is hard and expensive, so instead, they decided to make the x86 (32bits) to work as 64bits – x86_64. That strategy popularized the 64bit environment. On the other side, the ARMv8 was designed for 64bits from the beginning, and its energy efficiency made it accessible on mobile applications. Who remembers the RISC vs CISC competition? The RISC concept tells us to execute simple operations quickly. The CISC concept is quite the opposite: complex operations will perform better than a bunch of simple ones. Who won? Well, everybody won! Nowadays, the RISC introduced some CISC features and vice-versa and we have faster CPUs. Lastly, they all differ on registers, instructions, cache and many more.

Luckily, for the ones that don’t want to go assembly - like me - the compiler will know how to produce the executable for each architecture. However, we might end up with a not so well performed product as we were making it in assembly. To help us with that, there are compiler options (-static | -g | -fno-builtin | -O0 | -O3) that we can play around that could improve the overall performance.

We know that compilation is a painful process and can take a lot of time. To address this, the “make” utility will configure and compile our package. It is smart enough to know the proper execution sequence and what doesn’t need to be recompiled – due to no changes, for example.

My next post will talk more about the compiler. See you.
Labels:

Comments

Post a Comment

Popular posts from this blog

Project Stage 3

Photo by  NASA  on  Unsplash Hello! In this post, I’ll make a list of optimization opportunities that I identified on the AWK project based on what I’ve learned in the SPO600 classes. There are two types of optimizations: portable and platform-specific. Portable optimizations are the ones that work everywhere, like better algorithms and implementations, and also compiler building flags. Platform-specific, on the other hand, works only for a targeted architecture. Like the SIMD instructions available only on Arch64 and many others specific for x86_64. It is possible to “force” the usage of such instructions according to the targeted hardware. We can do that on compilation time, and also on run-time. Now that we know our options, let’s dig in. According to my previous post , the functions nematch and readrec are the hotspots. Here is the command line used to run the awk: ./awk 'BEGIN {FS = "<|:|=";} {if ($8 == "DDD>") a ++;} END {print "cou...
Post a Comment
Read more

SIMD - Single Instruction Multiple Data

Photo by  Vladimir Patkachakov  on  Unsplash Hi! Today’s lecture, we learned SIMD - Single Instruction Multiple Data. This is a great tool to process data in a bulk fashion. So, instead of doing one by one, based on the variable size, we can do 16, 8, 4 or 2 at the time. This technique is called auto-vectorization resources, and it falls into the category of machine instruction optimization that I mentioned in my last post. If the machine is SIMD enabled, the compiler can use it when translating a sum loop, for example. If we are summing 8 bits numbers, using SIMD, it will be 16 times faster. However, the compiler can figure that it is not safe to use SIMD due to overlapping or non-aligned data. In fact, the compiler will not apply SIMD in most cases, so we need to get our hands dirty and inject some assembly. I’ll show you how to do it in a second. Here are the lanes of the 128-bit AArch64 Advanced SIMD: 16 x 8 bits 8 x 16 bits 4 x 32 bits 2 x 64 bits 1 x ...
Post a Comment
Read more

Profiling

Photo by  Jack Millard  on  Unsplash Hi! Do you want to know which part of the code is taking more time to run? Profiling is the technique to collect runtime data that shows exactly that. We did that manually in the previous labs by adding the elapsed time for the function under analysis – this is called instrumentation. The other way is to interrupt the execution multiple times, taking snapshots along the way – this is called sampling. Sampling doesn’t change the binary, but it might not get all data. Let’s say that if a task starts and finishes between the snapshots, we won’t get it in the report. On the other hand, the instrumentation will get everything, but it has to change the executable. As a result, we will not test the final version. We have to keep that in mind to use the right tool for the situation. Speaking about tools, here they are gprof and perf. The gprof does sampling and instrumentation, while perf only does sampling. To use gprof, ...
Post a Comment
Read more