Intel’s Comet Lake-S Could Push Even More People Toward AMD

[d3bug]

The problem with your argument is Intel's own compiler which is not that widely used in most software development. That is kinda beating a dead horse. Nowadays Intel's compiler is mostly used in datacenters and HPC environment (for servers and supercomputers). Actually the most widely used compiler is Microsoft's own compilers (for their Microsoft Visual Studio development platform). Heck besides Microsoft's own software, many games also uses Microsoft compilers. If you want to blame software preference then look at Microsoft was well.

I am aware of that, and it uses the same CPU dispatcher as the Intel compiler. There is a fix however, which I posted in this very forum. JIC you don't want to find it... you can find it yourself HERE

If you still don't want to look it up... Here you go:

// Example 13.3. Override Intel CPU dispatching
#include <stdint.h>

extern "C" {

// link to dispatcher in library libirc.lib or libirc.a

void __intel_cpu_features_init();
void __intel_cpu_features_init_x();
extern uint64_t __intel_cpu_feature_indicator;
extern uint64_t __intel_cpu_feature_indicator_x;
}

// call this function in the beginning of your program:

void dispatch_patch() {

// replace the Intel-only dispatcher with the fair dispatcher

__intel_cpu_feature_indicator = 0;
__intel_cpu_feature_indicator_x = 0;
__intel_cpu_features_init_x(); // call fair dispatcher
__intel_cpu_feature_indicator = __intel_cpu_feature_indicator_x;

Now, of course for the Microsoft compiler, you have to choose the appropriate library.

 

[GetSmart]

I am aware of that, and it uses the same CPU dispatcher as the Intel compiler. There is a fix however, which I posted in this very forum. JIC you don't want to find it... you can find it yourself HERE

Again that is still beating a dead horse. How many software and games uses Intel's compiler? Here is an example of Unreal Engine development requirements and that is Microsoft Visual Studio (as mentioned earlier). Nowadays most software development uses that.

Now, of course for the Microsoft compiler, you have to choose the appropriate library.

Nopesies, unless you want to use specific low level instructions only available to AMD or Intel (typically with inline _asm code), otherwise Microsoft's compiler works the same way. Also Intel64 and AMD64 instructions are not 100% compatible as there are many specific vendor centric instructions and optimizations, thus there will also be Microsoft's own internal dispatcher for each specific code path.

 

[d3bug]

Again that is still beating a dead horse. How many software and games uses Intel's compiler? Here is an example of Unreal Engine development requirements and that is Microsoft Visual Studio (as mentioned earlier). Nowadays most software development uses that.

Nopesies, unless you want to use specific low level instructions only available to AMD or Intel (typically with inline _asm code), otherwise Microsoft's compiler works the same way. Also Intel64 and AMD64 instructions are not 100% compatible as there are many specific vendor centric instructions and optimizations, thus there will also be Microsoft's own internal dispatcher for each specific code path.

Once again, you IGNORED what I said.
Here, I will bold it for you.

" it uses the same CPU dispatcher as the Intel compiler"

Can you see it now? It's not beating a dead horse, the problem is still there - dirty tricks by Intel (and Microsoft).
Perhaps you should actually bother to read the links I provided & you'll learn something.

Second, I am not referring to low level assembly code that is vendor specific, nor is the blog that I linked to. It is referring to well established STANDARD code like MMX, SSE, SSE2, SSE3, etc... Not whatever you had in your imagination. Additionally, what I was saying is only that you have to specify the proper library name for the Microsoft compiler instead of the Intel one if you are using the Microsoft compiler... you know, just like you would do if you were using libc under Linux with GCC.... names matter.

 

[GetSmart]

Once again, you IGNORED what I said.
Here, I will bold it for you.

" it uses the same CPU dispatcher as the Intel compiler"

Can you see it now? It's not beating a dead horse, the problem is still there - dirty tricks by Intel (and Microsoft).
Perhaps you should actually bother to read the links I provided & you'll learn something.

Second, I am not referring to low level assembly code that is vendor specific, nor is the blog that I linked to. It is referring to well established STANDARD code like MMX, SSE, SSE2, SSE3, etc... Not whatever you had in your imagination. Additionally, what I was saying is only that you have to specify the proper library name for the Microsoft compiler instead of the Intel one if you are using the Microsoft compiler... you know, just like you would do if you were using libc under Linux with GCC.... names matter.

The blog is long time dead already (hence beating a dead horse). Nowadays nobody bothers with trying to replace the dispatcher anymore because it is automatic in all compilers including those by Microsoft and GNU Foundation (GCC). And to use specifically AMD or Intel specific MMX, SSE, SSE2, SSE3, etc... (and especially AVX, AVX2 and AVX512) that actually requires inline assembly code otherwise all floating point and SIMD-type operations (such as matrix multiplication) are handled automatically by the compiler.

 

[d3bug]

The blog is long time dead already (hence beating a dead horse). Nowadays nobody bothers with trying to replace the dispatcher anymore because it is automatic in all compilers including those by Microsoft and GNU Foundation (GCC). And to use specifically AMD or Intel specific MMX, SSE, SSE2, SSE3, etc... (and especially AVX, AVX2 and AVX512) that actually requires inline assembly code otherwise all floating point and SIMD-type operations (such as matrix multiplication) are handled automatically by the compiler.

You are wrong. Intel has NEVER fixed their compiler & only adds a disclaimer... but you rock on in your ignorance.

As I thought... you didn't bother actually reading. We are done. Adios.
Don't bother with a response. I won't see it. This conversation is the only thing beating a dead horse.

 

[GetSmart]

You are wrong. Intel has NEVER fixed their compiler & only adds a disclaimer... but you rock on in your ignorance.

As I thought... you didn't bother actually reading. We are done. Adios.
Don't bother with a response. I won't see it. This conversation is the only thing beating a dead horse.

Well, your arguments are beating dead horse because its entirely based on Intel's compiler (which was that blog's main subject). Nowadays Microsoft Visual Studio compiler is the predominant compiler for software development and the compiled binaries have Microsoft's own internal dispatcher for Intel or AMD code paths (which generates Microsoft's own specific binaries for either Intel64 or AMD64). Heck even GCC also has the same thing (all the code paths for binary compilation are contributed by the respective companies). Like I mentioned, nobody does this crude dispatching anymore. Nowadays its either using inline assembly or preprocessor defined (such as using #IFDEF) within the source code itself (for CPU specific optimizations). Everything else is internally handled automatically by the compiler (for each CPU specific code paths and binary generation). And for those Intel's (math) "libraries" those are rarely used for software development, mostly for stuff like Fortran and in HPC software development . Every developer have their own precompiled optimized libraries and DLLs (typically using Microsoft's compilers). You will only find Intel compilers more common in servers and supercomputers nowadays, such as server benchmarks like SPEC CPU2017 (an example here).

 

[BulkZerker]

Um, why the double-quote?


I'm not trying to defend Intel of mischaracterizing the power/performance of their CPUs. They definitely need to communicate this better.

What I am trying to do is alert people to the underlying reasons behind this discrepancy. Mr. Safford does his readers a disservice by over-simplifying the issue and not providing or directing people to the real explanation of what's going on.

As for the similarity of results across motherboards, that's because many are running with "unlimited turbo". Try actually reading the article, and you'll understand.

However, try putting one of these CPUs in a workstation motherboard and you'll see it respect its TDP, under sustained loads. Likewise, I expect systems from large OEMs, like Dell and HP to behave closer to Intel's recommendations.

By not acknowledging the role of the motherboard in this situation, you're failing to equip users of such systems with the knowledge that the motherboard might be holding them back. And user empowerment is really what I care about. Really, what good can come of these forums if not education?

Guess you didn't read my post.

 

[bit_user]

The problem with your argument is Intel's own compiler which is not that widely used in most software development. That is kinda beating a dead horse. Nowadays Intel's compiler is mostly used in datacenters and HPC environment (for servers and supercomputers).

Their "Genuine Intel" optimizations don't only exist in their compiler - it's also in some of their math and deep learning libraries.

Actually the most widely used compiler is Microsoft's own compilers (for their Microsoft Visual Studio development platform).

According to whom? I'd probably guess Clang, since it's used for iOS and Android development, plus a lot of Linux developers are starting to use it. Then again, GCC is still used for nearly every other platform and probably the second most popular Windows compiler - and still the only compiler supported for building the Linux kernel.

 

[bit_user]

it use to be that code was hand optimized and one cared about memory optimization.

low-level code also tends to use a lot of primitive datastructures & algorithms, because more sophisticated techniques are more time-consuming and error prone to implement, and take more work to test. So, it really cuts both ways. Personally, I wouldn't go back to the bad old days.

Most significant performance changes I believe will not happen until the IO is improved on system especially with storage. I personally would like to see more computing power directly aim at helping storage efforts similar to way we have with graphics now days

It depends on your use case. A lot of storage I/O is already fast, due to disk caching & buffering by the OS. But Intel is investing a lot of time & effort to move much of storage I/O into userspace, to better utilize their Optane DIMMs.

https://www.phoronix.com/scan.php?page=news_item&px=Intel-PMEMFILE

 

[bit_user]

Also Intel64 and AMD64 instructions are not 100% compatible as there are many specific vendor centric instructions and optimizations,

Nopesies!

You're not 100% wrong, but mostly. There's a very large compatible subset. In fact, you can simply target the "AMD64" baseline, and it will run on both. This is how Linux distros and probably most windows programs are compiled. If you want to use any ISA extensions beyond that (such as AVX), you have to explicitly tell the compiler to generate them (or explicitly use the intrinsics - which it won't let you do, if you haven't enabled those instructions) or use straight asm.

 

[bit_user]

The blog is long time dead already (hence beating a dead horse).

Dead according to whom? His optimization manuals were last updated just 3 weeks ago.

Heck even GCC also has the same thing (all the code paths for binary compilation are contributed by the respective companies).

Got a source on that?

And for those Intel's (math) "libraries" those are rarely used for software development, mostly for stuff like Fortran and in HPC software development.

Have you ever heard of "deep learning"?

 

[bit_user]

Guess you didn't read my post.

That's BS... or maybe I should say BZ. Obviously, I did.

Perhaps you're just here to troll Intel, which is not something I care to be involved in, on one side or another. I just think the article does readers a disservice by failing to properly explain the issue of Intel's TDP. As I said, I'm not trying to defend Intel's practices.

 

[GetSmart]

Their "Genuine Intel" optimizations don't only exist in their compiler - it's also in some of their math and deep learning libraries.

Those math and deep learning libraries are mostly from Intel specifically for stuff like Fortran and HPC software which are tailored around their own CPUs (with AVX512 A.I and deep learning instructions). And typically find these libraries are mainly used in workstations, datacenters and supercomputers (which may change with arrival of Intel's Ice Lake into consumer laptops). These are usually highly customized software for specific CPU and platforms. However AMD CPUs do not have those type instructions (only up to AVX2 without any A.I or deep learning instructions). If AMD want "a piece of that pie" (in servers for A.I and deep learning) then AMD has to create their own libraries tailored to their own CPUs. Currently AMD's other choice is to promote their Radeon Pro and FirePro as accelerators (such as that GPUOpen initiative).

According to whom? I'd probably guess Clang, since it's used for iOS and Android development, plus a lot of Linux developers are starting to use it. Then again, GCC is still used for nearly every other platform and probably the second most popular Windows compiler - and still the only compiler supported for building the Linux kernel.

And how many Linux users are there compared to Windows users? Nearly all of Windows software nowadays are compiled using Microsoft's Visual Studio, and another example is Unity 3D engine which caught headlines at SIGGRAPH 2019. Don't be surprised that many games and game engines uses Microsoft Visual Studio (even the venerable ones like CryEngine). As for second most popular compiler for Windows, in my opinion should be C++Builder (continuation of Borland's C++ legacy).

 

[BulkZerker]

That's BS... or maybe I should say BZ. Obviously, I did.

Perhaps you're just here to troll Intel, which is not something I care to be involved in, on one side or another. I just think the article does readers a disservice by failing to properly explain the issue of Intel's TDP. As I said, I'm not trying to defend Intel's practices.

Firstly, nice use of the PC culture N word to dehumanize me.

"The damage control is amazing.

1. Intel has not lifted a single finger to disuade any motherboard maker to stop the practice of aggressive boost clocks.
2. Somehow, all of them have a very similar performance, almost as if they are following a spec. (Them trying to pull a fast one by adjusting bClk nonwithstanding)

Its been known for a while the TDP for Intel is at base clock."

my op.

Intel for years has know motherboard manufacturers are not conforming to their specs. And they haven't made a single move to even suggest that Asus,ASRock,Biostar(ECT) are doing something that they actually disapprove of.

That is complete and total wink wink nudge nudge move, and both Intel and their board partners are both in on.

Of Intel actually cared they would make a public statement beyond "that's out of spec, oh well". It would be along the lines of "this is unacceptable and being resolved".

 

[bit_user]

Firstly, nice use of the PC culture N word to dehumanize me.

I'm not quite sure what you're talking about, but I was trying to play off your name. It was meant in a good spirit, so I'm sorry you took offense by it. I certainly am not trying to dehumanize anyone.

For my part, I didn't appreciate the way you seemed to accuse me of doing damage control for intel.

Intel for years has know motherboard manufacturers are not conforming to their specs. And they haven't made a single move to even suggest that Asus,ASRock,Biostar(ECT) are doing something that they actually disapprove of.

That is complete and total wink wink nudge nudge move, and both Intel and their board partners are both in on.

Of Intel actually cared they would make a public statement beyond "that's out of spec, oh well". It would be along the lines of "this is unacceptable and being resolved".

That's a legit opinion. I think it's a little extreme, however. There's a middle-ground where they could say "these motherboards are running our CPUs out of spec, and thereby invalidating our stated TDP." They don't need to punish the MB makers, so long as the MB isn't doing anything to void the CPU warranty, but just let consumers know to adjust their expectations of power consumption and cooling requirements, accordingly.

I'm just pointing out that there aren't only two ways of dealing with the situation. I'm not trying to take a position on that, so much as promote the idea that readers should be informed about what's really going on with Intel's TDPs, which is quite thoroughly covered in the link I cited. The way the article described it is, in my opinion, too simplistic and doesn't serve readers as well as it could've.