Avisynth plugins - clang, msvc, AVX, SSE... which one to choose?

[SlowDelivery]

Hello, I'm very new to avisynth so sorry if this question has been asked before, but I couldn't find much on this.
I'm trying out lots of avisynth plugins, and they often come in different versions with clang, msvc, AVX, SSE etc.
Searching tells me that clang, msvc are compilers and AVX, SSE are CPU instructions, but I don't know what difference they make in the end.

So far, I've tried all the different versions for a given plugin and chose the fastest working one, though the difference is not very big usually.
But perhaps there is a better way to determine the best version?
I'm currently using Intel i5 9600KF on Windows 10 64bit.

Also, I see a lot of XP versions for these plugins, what are the advantages of running things on XP?

[magnetite]

AFAIK, AVX2 is the fastest instruction set for regular consumers (excluding power users who may use X series chips from Intel with AVX512) . Not every plugin supports it (not sure why). Some only use SSE2.

Compilers are programs which take source code (written in C, C++, Java, etc) and convert it into machine code for the computer to use. I've always used MSVC compiled plugins, because I have never had any Intel or Clang plugins. Some say each compiler may be faster than the other, but everyone's machine is different. I was told to experiment and decide for myself. So far, I haven't noticed much of a difference, so I just go with MSVC plugins.

Windows XP is dead. Has been dead since 2014 when it went reached it's end of life. Windows 10 is more advanced than Windows XP. Windows XP was designed for computers around the turn of the millennium. We've come a long way technology wise since then.

[TheFluff]

Avisynth plugin developers do quite a few things for reasons that are at best shrouded in the mists of time, and these are some of them.

The Windows XP thing is basically a thing for extremely obstinate people only. Doom9 is one of the few holdouts where there are people who unironically think that Windows XP was the last good version of Windows and therefore they refuse to upgrade from it. Modern software development tools have stopped supporting Windows XP out of the box so these people sometimes make special versions of plugins that work on Windows XP. There is no reason for anyone else to use these.

As far as the instruction sets go, when you build software you can choose what CPU features the compiler is allowed to use. Sometimes (especially in video processing software) you might even write some low-level code relying on certain CPU features yourself to make things go really fast on CPU's that support these features. Normally you make the software automatically detect which features your CPU supports and then run the fastest available code based on that. On doom9 however there are some people who for some inexplicable reason don't like computers doing things for them automatically, and there are some people here who insist on using CPU's that are literally 20 years old, so some people build multiple versions of plugins with or without certain CPU-specific features so you have to choose yourself which one you want. There's no reason to do this either and it makes things a lot more complicated for users (as you have discovered), but that's the way they chose to do it. Choose AVX/AVX2 if available, SSE(2/3/4) if not. Do not choose AVX512, that's a thing for very expensive server CPU's only.

AFAIK, AVX2 is the fastest instruction set for consumers. Not every plugin supports it (not sure why). Some only use SSE2.
Most plugins that require specific instruction sets do so because someone hand-wrote optimized code in assembler for that instruction sets, and many plugins were written before AVX even existed. Also, AVX is only faster than SSE (or anything else for that matter) if you manage to come up with code that can use its features in an advantageous way. In some cases that might not be possible.

You can tell the compiler to try to automatically optimize C or C++ code with AVX/AVX2 but it almost never leads to a meaningful improvement, so most people don't bother and just target SSE2, which is available on every CPU from the last 15+ years. There are of course a few exceptions - some people certainly won't let test data that shows that there is no reason to do it get in the way of their way of doing things (https://forum.doom9.org/showthread.php?p=1814868#post1814868).

[FranceBB]

I'm trying out lots of avisynth plugins, and they often come in different versions with clang, msvc, AVX, SSE etc.
Searching tells me that clang, msvc are compilers and AVX, SSE are CPU instructions, but I don't know what difference they make in the end.

Quick answer: it depends on your CPU.

I'm going to quote myself from October 10th, 2019, 07:16 AM (https://forum.doom9.org/showthread.php?p=1887057#post1887057) as I'm lazy:



SSE, SSE2, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX512 are CPU Instruction sets which in terms of a program refer to how the program has been compiled. A program can have manually written intrinsics (e.g parts written in assembly) or it can be written using C++ and then compiled.
To clarify this, there are low-level programming languages like Assembly and high-level programming languages like C++. When you write a program and then you compile it, it's up to the compiler to produce a code that the machine understands.
If you write it using a low-level programming language like Assembly, the code is gonna be very optimized as it's gonna be as close as possible to what the machine understands, however writing a full program in a low-level language is a nightmare, especially for complicated things, where it's easy to lose track of what you are doing and why you are doing it. As opposite, a high level programming language like C++ is easier to use, however it will be less optimized 'cause the compiler has to "guess" what you wanted to do and "bring" your code to something that a machine can understand. Generally, the idea is to use a high level programming language and then optimize the key parts by manually writing intrinsics, (which is not easy and it's far too advanced for me as I'm not able to do that and I only code using a high level programming language).
Let's suppose that a plugin is written in C++ only and then compiled using different assembly optimizations.
This way, it's gonna be the compiler that will try to understand what the programmer wanted to do and will try to optimize it for different assembly instructions, which won't be as fast as manually written intrinsics, but it will be faster than using no assembly optimizations at all.
Now, I know what you are thinking... you are basically thinking "fair enough, Frank, but what are those SSE, SSE2, SSE3 SSSE3, SSE4.1, SSE4.2, AVX ecc things?".
Well, one way I use to explain this to non-programmers is to think about two CPUs, an old one with SSE2 and a recent one with AVX2.
Think about the SSE2 CPU as a "dumb child" who can only do addition and the AVX2 one as a "smart child" who can do multiplication.
Of course, as long as the teacher assigns those children additions, both are gonna be fine, however, if the teacher assigns those children multiplications, the second child (the smart one) will do them, while the first one (the dumb one) will have to split them into additions and then will get to the same result.
The teacher is like the program you are trying to execute.
Additions is like a program compiled with SSE2.
Multiplication is like a program compiled with AVX2.
If you try to assign multiplications to the dumb child without splitting them into additions, the dumb child won't be able to do them, which means that if you compile a program with AVX2 and you try to open it with an SSE2 capable CPU it won't be able to run it and will fail, however if you split them in sums and you assign them to the dumb child, he will be able to do them, but it will take longer (i.e if you compile the program with SSE2, the CPU will be able to run the program but it will be slower).

And... that's it. :)
I know that it's a very simple way to see it and there is more behind this, but I'm not gonna explain it any further as it would take pages to get into details of what each and every instruction set does, but you can check Wikipedia for them as they are all documented.
One little note at the end: remember that I told you that sometimes programs are written in C++ only and then compiled with assembly optimizations by the compiler which has to guess what the compiler is doing? Well, it may not guess right and, as a matter of fact, there are times in which an AVX2 compiled code is not faster than an SSE4.2 compiled one (I'm sure there are topics about it on Doom9 but I can't think about them, I just know that I've been over this other times in the past). :)

To that I'm gonna add a few things:

1) Different compilers make different assembly optimizations, therefore you see binaries compiled with Intel Parallel Studio (ICC), some others compiled with Visual Studio (MSVC), some other compiled with Clang and so on. In some cases Intel Parallel Studio produces faster code for the same instruction set target (like AVX2), some other times Clang does... It really depends, there isn't a "pick one to rule them all".

2) Sometimes targeting things like AVX512 might be useless if there's nothing inside your program that make use of those. Same for other instruction sets.

3) For those who don't like the very stupid example and wanna know how multiplications and divisions are done in real life, they're done with Shift Registers and have nothing to do with instructions set, but I like to use that example as it's like thinking about a CPU that doesn't have any shift registers (for which I made a video) (https://www.youtube.com/watch?v=PGaBIR_ZIsA&list=PL7dD-bUWOf-oupQXE3dYiPChdpqvv-TD8&index=45) xD

4) As a quick and dirt method if you don't wanna know any of this, just download Piriform Speccy, go to the "CPU" section and look at which instructions it supports, then choose the correspondent build.

5) As to the XP Binaries, they're made for Windows XP. They're compiled targeting v141_xp which uses XP compatible APIs, thread-safe options and targeted assembly optimizations are never greater than SSE4.2 due to OS-specific limitations (however many programmers tend to "play safe" and target SSE2 on those builds 'cause they wanna make sure that they run everywhere and that are compatible with each and every CPU). Technically you should use them only if you are running XP (many people still are), or if you have an incredibly old CPU that doesn't support anything except plain C / SSE / SSE2 instructions.


Windows XP is dead. Has been dead since 2014 when it went reached it's end of life.

Not true.
Premium Support for businesses is still a thing: if people pay 15'000 bucks every year, Microsoft releases to their computers updates every second Tuesday of the month (Patch Tuesday).
Besides, updates 'till July 2019 were leaked and a whole community (of which I'm proudly part of) is working on a custom kernel with backported APIs: Link (https://github.com/Skulltrail192/One-Core-Api) - Link (http://shorthornproject.com/).
So believe it or not, XP is still alive xD
Of course, even if I'm a die-hard, I keep it for nostalgia only and I use it for leisure (listening to music, browsing, chatting etc), 'cause I have Win10 x64 for work and Fedora Linux for other things.

[SlowDelivery]

Wow, thanks for the detailed reply everyone! Very helpful:thanks:

[magnetite]

Not true.
Premium Support for businesses is still a thing: if people pay 15'000 bucks every year, Microsoft releases to their computers updates every second Tuesday of the month (Patch Tuesday).
Besides, updates 'till July 2019 were leaked and a whole community (of which I'm proudly part of) is working on a custom kernel with backported APIs: Link (https://github.com/Skulltrail192/One-Core-Api) - Link (http://shorthornproject.com/).
So believe it or not, XP is still alive xD
Of course, even if I'm a die-hard, I keep it for nostalgia only and I use it for leisure (listening to music, browsing, chatting etc), 'cause I have Win10 x64 for work and Fedora Linux for other things.

I always thought if people still used XP in 2020 or after the EOL they'd be open to security holes and exploits. Didn't know about the Premium business support thing they had going on.

Think about the SSE2 CPU as a "dumb child" who can only do addition and the AVX2 one as a "smart child" who can do multiplication.
Wouldn't the smart child be able to do both? Since they would have learned addition before multiplication?

[Groucho2004]

I always thought if people still used XP in 2020 or after the EOL they'd be open to security holes and exploitsI doubt that anyone is interested in exploiting security holes in XP.

[Myrsloik]

I have one more thing to add:

If the developer can't be bothered to benchmark which build is faster (if any) they're lazy bastards and you should annoy them with private messages so they learn not to do it anymore.

You'd be surprised how many people wrote sse2, sss3 AND sse4.1 code paths in the good old days without actually checking that newer instructions=faster.

The same thing applies to different compiler builds. A HUGE WASTE OF TIME. Simple benchmarking would show which build to distribute.

[tormento]

I doubt that anyone is interested in exploiting security holes in XP.
You can't even imagine how many SCADA are connected to XP.

*cough*IRAN*cough*NORTH KOREA*cough

And perhaps lot of factories close to where you live.

[FranceBB]

Wouldn't the smart child be able to do both? Since they would have learned addition before multiplication?

Yes, the smart child can do both, just like AVX capable CPUs can execute SSE programs. haha the analogy works xD


I always thought if people still used XP in 2020 or after the EOL they'd be open to security holes and exploits. Didn't know about the Premium business support thing they had going on.

Well, as long as Microsoft guys can rip off businesses... they do it... There's a similar program for Win7 now that it reached End of Support and many businesses already purchased it...

I doubt that anyone is interested in exploiting security holes in XP.

True. Most of the patches released during patch Tuesday from 2014 to 2019 were security issues that were discovered in newer version of Windows but that were also affecting XP, so they had to patch XP and its derivatives as well... It's a shame, though, that nothing post July 2019 has been leaked, but I guess there's always 0patch which provides a certain level of security for individuals...

You can't even imagine how many SCADA are connected to XP.

*cough*IRAN*cough*NORTH KOREA*cough

And perhaps lot of factories close to where you live.

Well one of the reason XP is still very popular is its embedded products. Many McDonald's tills are still running Windows XP Embedded POSReady 2009, in the UK self-checkout machines from Tesco run on Windows Embedded (which is XP), in Italy Trenitalia ticket machines are running on Windows Embedded (which is XP), so are fuel pumps that take your cash at the gas station, elevators that tell you which floor you're at and whether you're going up/down and if the doors are closing or opening and so on... You'd be surprised by how many things are still running on XP...
And... sure, Microsoft is trying to make people switch to Windows 10 Embedded (also called Windows 10 for IoT), but the point is that those machines almost definitely run on a secure intranet completely disconnected from internet anyway and they might be bonded to hardware put in place several years ago which is still working but that doesn't have any drivers for Win10 (and never will as the manufacturer wants to sell you... I don't know, a new fuel pump for instance) etc.
So it's very unlikely that people will ever upgrade these system and they'll keep them running 'till those machines will die (i.e break).
We have a group called "Windows XP Spotter" on MSFN where we post pictures of XP machines running in the wild whenever we spot one (and there are many of them): Link (https://msfn.org/board/topic/176692-windows-xp-spotter-the-club/)

[SlowDelivery]

I have one more thing to add:

If the developer can't be bothered to benchmark which build is faster (if any) they're lazy bastards and you should annoy them with private messages so they learn not to do it anymore.

You'd be surprised how many people wrote sse2, sss3 AND sse4.1 code paths in the good old days without actually checking that newer instructions=faster.

The same thing applies to different compiler builds. A HUGE WASTE OF TIME. Simple benchmarking would show which build to distribute.

Haha, it would be nice if developers explicitly state which version is the best, though I'm already grateful that they are sharing their work