AviSynth+ thread Vol.2

[pinterf]

I was trying the famous rife script with this intel build and the latest avspmod. What can be the difference? I'm on w11pro, 11th gen i7. It worked fine.

[gispos]

VirtualDub2_64
The Avisynth.dll is loaded and after the VCRUNTIME140_1.dll is loaded the error starts.
Is it possible that the VCRUNTIME140 is not compatible with the Intel runtimes? Or are there newer VC runtimes after all?
Note: Fehler = Error

Ereigniszeit	Ereignisart	Thread-ID	Speicheradresse	Dateinam	
00:01:32.426	DLL laden	6264	00007ff9`a43c0000	C:\Windows\SYSTEM32\AviSynth.dll		
00:01:32.427	DLL laden	6264	00007ff9`f0010000	C:\Windows\System32\imagehlp.dll		
00:01:32.427	DLL laden	6264	00007ff9`ac020000	C:\Windows\SYSTEM32\MSVCP140.dll		
00:01:32.428	DLL laden	6264	00007ff9`e2d80000	C:\Windows\SYSTEM32\VCRUNTIME140.dll		
00:01:32.428	DLL laden	6264	00007ff9`e9d30000	C:\Windows\SYSTEM32\VCRUNTIME140_1.dll		
00:01:32.429	Fehler	6264	00007ff9`ac033028		Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000	
00:01:32.430	Fehler	6264	00007ff9`ee31b699		Fehlercode: 0xe06d7363, Parameter: , 0x19930520, 0x004fe740, 0x200905f0, 0x1fc70000	
00:01:32.478	Fehler	6264	00007ff9`ac033028		Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000	
00:01:32.478	Fehler	6264	00007ff9`ac033028		Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000	
00:01:36.003	Thread beenden	7304			Austrittscode: 0xc0000005

[pinterf]

Originally Posted by DTL

"optional AVX2 code paths"

With VirtualDub 1.10.4 at Win7 x64 and E7500 CPU I got not crash but some unknown error in Avisynth

E7500 is good up to SSE4.1, I examined and searched the Intel compiler switches again, but they tell that the base "Not Set" processor level is for SSE2, and the /QaxCORE-AVX2 defines the alternative code path.

I don't know this VirtualDub version, where is it from? I'm using VirtualDub2 44282, please try with it, or with an even newer one.

[pinterf]

Originally Posted by gispos

VirtualDub2_64
The Avisynth.dll is loaded and after the VCRUNTIME140_1.dll is loaded the error starts.
Is it possible that the VCRUNTIME140 is not compatible with the Intel runtimes? Or are there newer VC runtimes after all?
Note: Fehler = Error

Ereigniszeit	Ereignisart	Thread-ID	Speicheradresse	Dateinam	
00:01:32.426	DLL laden	6264	00007ff9`a43c0000	C:\Windows\SYSTEM32\AviSynth.dll		
00:01:32.427	DLL laden	6264	00007ff9`f0010000	C:\Windows\System32\imagehlp.dll		
00:01:32.427	DLL laden	6264	00007ff9`ac020000	C:\Windows\SYSTEM32\MSVCP140.dll		
00:01:32.428	DLL laden	6264	00007ff9`e2d80000	C:\Windows\SYSTEM32\VCRUNTIME140.dll		
00:01:32.428	DLL laden	6264	00007ff9`e9d30000	C:\Windows\SYSTEM32\VCRUNTIME140_1.dll		
00:01:32.429	Fehler	6264	00007ff9`ac033028		Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000	
00:01:32.430	Fehler	6264	00007ff9`ee31b699		Fehlercode: 0xe06d7363, Parameter: , 0x19930520, 0x004fe740, 0x200905f0, 0x1fc70000	
00:01:32.478	Fehler	6264	00007ff9`ac033028		Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000	
00:01:32.478	Fehler	6264	00007ff9`ac033028		Fehlercode: 0xc0000005, Parameter: , 0x00000000, 0x00000000	
00:01:36.003	Thread beenden	7304			Austrittscode: 0xc0000005

I don't have problems, my vcruntime140.dll and vcruntime140_1.dll files in the system32 come with version 14.42.34433

[DTL]

VirtualDub 1.10.4 is build 35491. It is from some old decades 201x or 200x . With build 44282 it is really crashed but make more valuable crashlog with some call stack info:

VirtualDub2 crash report -- build 44282 (release-AMD64)
--------------------------------------

Disassembly:
7fee0052e20: 4883c108        add    rcx, 08h
7fee0052e24: e93f880200      jmp    e007b668
7fee0052e29: cc              int    3
7fee0052e2a: cc              int    3
7fee0052e2b: cc              int    3
7fee0052e2c: 48895c2418      mov    [rsp+18h], rbx
7fee0052e31: 56              push   esi
7fee0052e32: 57              push   edi
7fee0052e33: 4156            push   esi
7fee0052e35: 4883ec40        sub    rsp, 40h
7fee0052e39: 488b0558380700  mov    rax, [e00c6698]
7fee0052e40: 4833c4          xor    eax, esp
7fee0052e43: 4889442430      mov    [rsp+30h], rax
7fee0052e48: 8b01            mov    eax, [rcx]
7fee0052e4a: 4c8bf2          mov    r14, edx
7fee0052e4d: 0fbaf008        btr    eax, 08h
7fee0052e51: 488bf1          mov    rsi, ecx
7fee0052e54: 83f801          cmp    eax, 01h
7fee0052e57: 752c            jnz    e0052e85
7fee0052e59: ff1541230400    call   dword ptr [e00951a0]
7fee0052e5f: 394648          cmp    [rsi+48h], eax
7fee0052e62: 7419            jz     e0052e7d
7fee0052e64: 488d4e08        lea    rcx, [rsi+08h]
7fee0052e68: 488b01          mov    rax, [rcx]
7fee0052e6b: 488b00          mov    rax, [rax]
7fee0052e6e: ff15ac270400    call   dword ptr [e0095620]
7fee0052e74: ff1526230400    call   dword ptr [e00951a0]
7fee0052e7a: 894648          mov    [rsi+48h], eax
7fee0052e7d: ff464c          inc    dword ptr [rsi+4ch]
7fee0052e80: e9f3000000      jmp    e0052f78
7fee0052e85: 4d85f6          test   esi, r14
7fee0052e88: 7524            jnz    e0052eae
7fee0052e8a: ff1510230400    call   dword ptr [e00951a0]
7fee0052e90: 394648          cmp    [rsi+48h], eax
7fee0052e93: 0f849d000000    jz     e0052f36
7fee0052e99: 488d4e08        lea    rcx, [rsi+08h]
7fee0052e9d: 488b01          mov    rax, [rcx]
7fee0052ea0: 488b00          mov    rax, [rax]      <-- FAULT
7fee0052ea3: ff1577270400    call   dword ptr [e0095620]
7fee0052ea9: e988000000      jmp    e0052f36
7fee0052eae: 48833a00        cmp    qword ptr [rdx], 00h
7fee0052eb2: 7c62            jl     e0052f16
7fee0052eb4: 7506            jnz    e0052ebc
7fee0052eb6: 837a0800        cmp    dword ptr [rdx+08h], 00h
7fee0052eba: 7e5a            jle    e0052f16
7fee0052ebc: ba01000000      mov    edx, 00000001
7fee0052ec1: 488d4c2420      lea    rcx, [rsp+20h]
7fee0052ec6: e8b5080000      call   e0053780
7fee0052ecb: 488b442420      mov    rax, [rsp+20h]
7fee0052ed0: 493b06          cmp    eax, [r14]
7fee0052ed3: 7c0c            jl     e0052ee1
7fee0052ed5: 757d            jnz    e0052f54
7fee0052ed7: 418b4608        mov    eax, [r14+08h]
7fee0052edb: 39442428        cmp    [rsp+28h], eax
7fee0052edf: 7d73            jge    e0052f54
7fee0052ee1: ff15b9220400    call   dword ptr [e00951a0]
7fee0052ee7: 394648          cmp    [rsi+48h], eax
7fee0052eea: 744a            jz     e0052f36
7fee0052eec: 488b4608        mov    rax, [rsi+08h]
7fee0052ef0: 488d542420      lea    rdx, [rsp+20h]
7fee0052ef5: 498bce          mov    rcx, esi
7fee0052ef8: 488b5810        mov    rbx, [rax+10h]
7fee0052efc: e86f070000      call   e0053670
7fee0052f01: 8bd0            mov    edx, eax
7fee0052f03: 488d4e08        lea    rcx, [rsi+08h]
7fee0052f07: 488bc3          mov    rax, ebx
7fee0052f0a: ff1510270400    call   dword ptr [e0095620]
7fee0052f10: 84c0            test   al, al
7fee0052f12: 7522            jnz    e0052f36
7fee0052f14: eba6            jmp    e0052ebc
7fee0052f16: ff1584220400    call   dword ptr [e00951a0]
7fee0052f1c: 394648          cmp    [rsi+48h], eax
7fee0052f1f: 74              db     74h

Built on Anton4 on Fri Mar 20 00:39:05 2020 using compiler version 1500

Windows 6.1 (Windows 7 x64 build 7601) [Service Pack 1]
Memory status: virtual free 8388407M/8388608M, commit limit 7895M, physical total 3199M

RAX =                0
RBX =      7fede4c5e2b
RCX =          3c219d0
RDX =                0
RSI =          3c219c8
RDI =          3c21930
RBP =           31bf40
R8  =           31c050
R9  = ffffffffffffee21
R10 =                0
R11 =              286
R12 =         ffffffff
R13 =                0
R14 =                0
R15 =           31c708
RSP =           31beb0
RIP =      7fee0052ea0
EFLAGS = 00010286


Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'VirtualDub64'...

...reading address 0000000000000000.

Pointer dumps:

RBX   7fede4c5e2b: 65757274 75725400 6f630065 6e69746e 68006575 61767865 0065756c 3a726f66
RCX   03c219d0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
RSI   03c219c8: 00000002 00690057 00000000 00000000 00000000 00000000 00000000 00000000
RDI   03c21930: 3f4ccccd 00000000 03c21800 00000000 00000000 00000000 03c2cd90 00000000
RSP   0031beb0: 00054be9 00000000 000f1983 00000000 001ed691 00000000 0013a7d1 00000000
      0031bed0: 00f7fa0a 00000000 0040bf94 00000000 670cb5e9 000071af 00159000 00000000
      0031bef0: 03c219c8 00000000 03c21930 00000000 0031c050 00000000 dd90fd6f 000007fe
      0031bf10: 0000237f 00000000 0187f000 00000000 de4c5e2b 000007fe 0005e4f0 00000000
RBP   0031bf40: 03c21930 00000000 31f8b800 00000000 03c1af00 00000000 000505e0 00000000
      0031bf60: 0031bff0 00000000 dd91bcd5 000007fe 03c21930 00000000 001555b0 00000000
      0031bf80: 001555b0 00000000 03c21930 00000000 001207d8 00000000 00000040 00000039
      0031bfa0: c7e2e000 00000000 54be9000 00000000 ed691000 00000001 fbd0e000 00000000
R8    0031c050: 00000062 00000039 00000001 00000000 54be9000 00000000 ed691000 00000001
R15   0031c708: 0031ea40 00000000 00000000 00000000 f56864a9 000007fe dd9f94ce 000007fe

Thread call stack:
7fee0052ea0: MSVCP140!_Thrd_yield [7fee0040000+12d60+140]
7fedd90fd6f: AviSynth!001ffd6f
7fedd91bcd5: AviSynth!avs_get_error [7fedd710000+2025c0+9715]
7fef1dd383f: ucrtbase!__stdio_common_vswprintf_s [7fef1dd0000+37a0+9f]
7fedd9121ec: AviSynth!CreateScriptEnvironment2 [7fedd710000+2021b0+3c]
7fedf7569f8: scripted!000069f8
7fedf7a3e43: scripted!VDGetPluginInfo [7fedf750000+8d40+4b103]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf75fa6c: scripted!VDGetPluginInfo [7fedf750000+8d40+6d2c]
7fedf7d314b: scripted!VDGetPluginInfo [7fedf750000+8d40+7a40b]
7fedf7d314b: scripted!VDGetPluginInfo [7fedf750000+8d40+7a40b]
7fedf756898: scripted!00006898
7fedf752282: scripted!00002282
7fedf754b1d: scripted!00004b1d
7fedf751f45: scripted!00001f45
7782f615: USER32!SystemParametersInfoW [77820000+f4f0+125]
7782f5e7: USER32!SystemParametersInfoW [77820000+f4f0+f7]
77836850: USER32!IsDialogMessageW [77820000+166d0+180]
7782f668: USER32!SystemParametersInfoW [77820000+f4f0+178]
77a8d8f5: ntdll!KiUserCallbackDispatcher [77a40000+4d8d6+1f]
7fedf754e63: scripted!00004e63
77839ae6: USER32!TranslateMessageEx [77820000+19974+172]
778337b6: USER32!GetWindowLongPtrA [77820000+13794+22]
7fedf755191: scripted!00005191
13f355f09: VirtualDub64!000c5f09
13f5975c2: VirtualDub64!003075c2
77a8fa48: ntdll!RtlAllocateHeap [77a40000+4f8d0+178]
13f586790: VirtualDub64!002f6790
13f56b765: VirtualDub64!002db765
7fef56864a9: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+1c9]
13f340f90: VirtualDub64!000b0f90
77a8d351: ntdll!RtlRestoreContext [77a40000+4d06f+2e2]
13f340f90: VirtualDub64!000b0f90
7fefdc62851: ole32!CoUninitialize [7fefdc40000+21324+152d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefdc73fff: ole32!ObjectStublessClient4 [7fefdc40000+33de0+21f]
77933a3d: kernel32!RegOpenKeyExW [77920000+13a20+1d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefe22d7a1: USP10!UspFreeMem [7fefe210000+1d740+61]
7fefdc53feb: ole32!CoGetTreatAsClass [7fefdc40000+13e90+15b]
13f340f90: VirtualDub64!000b0f90
77a690dd: ntdll!RtlDecodePointer [77a40000+28fb0+12d]
77a583db: ntdll!RtlUnwindEx [77a40000+18050+38b]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
13f340f90: VirtualDub64!000b0f90
13f340f90: VirtualDub64!000b0f90
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
77aba5eb: ntdll!RtlIsDosDeviceName_U [77a40000+55ac0+24b2b]
13f340f90: VirtualDub64!000b0f90
7fefdc62851: ole32!CoUninitialize [7fefdc40000+21324+152d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefdc73fff: ole32!ObjectStublessClient4 [7fefdc40000+33de0+21f]
77933a3d: kernel32!RegOpenKeyExW [77920000+13a20+1d]
7fefdc685c3: ole32!CoCreateInstance [7fefdc40000+274a0+1123]
7fefe22d7a1: USP10!UspFreeMem [7fefe210000+1d740+61]
7fefdc53feb: ole32!CoGetTreatAsClass [7fefdc40000+13e90+15b]
7795051e: kernel32!RtlUnwindEx [77920000+30500+1e]
13f340f90: VirtualDub64!000b0f90
13f562b49: VirtualDub64!002d2b49
13f31e361: VirtualDub64!0008e361
7fefd8c3150: KERNELBASE!GetProcAddress [7fefd8c0000+30f0+60]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
7fef5686843: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+563]
7fef568656a: VCRUNTIME140!_set_se_translator [7fef5680000+62e0+28a]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
13f56afae: VirtualDub64!002dafae
7fefdc77242: ole32!IsEqualGUID [7fefdc40000+34810+2a32]
7fedd9f9069: AviSynth!DllCanUnloadNow [7fedd710000+2e6aa0+25c9]
77a68e9e: ntdll!RtlLookupFunctionTable [77a40000+28df0+ae]
13f56afc7: VirtualDub64!002dafc7
13f5625f1: VirtualDub64!002d25f1
13f56afae: VirtualDub64!002dafae
13f56b96e: VirtualDub64!002db96e
13f56afc7: VirtualDub64!002dafc7
13f562530: VirtualDub64!002d2530
13f5625f1: VirtualDub64!002d25f1
13f56bc28: VirtualDub64!002dbc28
13f56b2aa: VirtualDub64!002db2aa
13f56c292: VirtualDub64!002dc292
13f56c611: VirtualDub64!002dc611
13f340f90: VirtualDub64!000b0f90
13f562773: VirtualDub64!002d2773
77a6905d: ntdll!RtlDecodePointer [77a40000+28fb0+ad]
77a58c0f: ntdll!RtlUnwindEx [77a40000+18050+bbf]
13f340f90: VirtualDub64!000b0f90
7fefdc5159a: ole32!CLSIDFromString [7fefdc40000+10680+f1a]
7fefdc516a7: ole32!CLSIDFromString [7fefdc40000+10680+1027]
13f31e361: VirtualDub64!0008e361
77936074: kernel32!RegGetValueW [77920000+15ed0+1a4]
77a8d948: ntdll!KiUserExceptionDispatcher [77a40000+4d91a+2e]
7fee0052ea0: MSVCP140!_Thrd_yield [7fee0040000+12d60+140]
77a59008: ntdll!RtlRaiseException [77a40000+18fc0+48]
77a59208: ntdll!RtlRaiseException [77a40000+18fc0+248]
7fefd8cb16d: KERNELBASE!RaiseException [7fefd8c0000+b130+3d]
77a8f9b8: ntdll!RtlAllocateHeap [77a40000+4f8d0+e8]
13f56afc7: VirtualDub64!002dafc7
13f565dc2: VirtualDub64!002d5dc2
13f56dff2: VirtualDub64!002ddff2

-- End of report

Disassembly looks correct - RAX is zero and reading from zero address cause crash.

[pinterf]

I've created ReleaseWithDebug builds. These have the same speed as release builds (if they work ), but they may help to show where it crashes.

I've put together a zip file with four Intel ICX builds of Avisynth.dll and Avisynth.pdb. Each build comes with its corresponding PDB debug info file. Please copy both the DLL and PDB files into the System32 directory.

The variants are as follows (see folder names):

SSE2
SSE2 + AVX2
AVX2
AVX2 + AVX512 (for Ice Lake - 10th/11th gen i7 processors, for example)

You can download them from the link (the base pack is still there).
https://github.com/pinterf/AviSynthP...ag/v3.7.3.4198

Thanks.

[tormento]

Originally Posted by pinterf

I've created ReleaseWithDebug builds..

As I am —still— an AVX user, do you think an Intel AVX build could be of any utility to have a small speed bump?

[tebasuna51]

For me, and for users even more ignorant than me, please can you explain the limits and advantages of each compilation of Avs+?

There are the xp_or_better, the intel_icx (with 4 variants) but also Clang and intelLLVM builds.

If there are a stable build of Avs+ 3.8.0 for xp_or_better please do it, and after try better (saying for what) compilations of these versions.

[pinterf]

Originally Posted by tormento

As I am —still— an AVX user, do you think an Intel AVX build could be of any utility to have a small speed bump?

No.
AVX is floating point only.
Unless you have a full-32-bit float workflow, which is using exclusively Avisynth internal filters.

[pinterf]

Originally Posted by tebasuna51

For me, and for users even more ignorant than me, please can you explain the limits and advantages of each compilation of Avs+?

There are the xp_or_better, the intel_icx (with 4 variants) but also Clang and intelLLVM builds.

If there are a stable build of Avs+ 3.8.0 for xp_or_better please do it, and after try better (saying for what) compilations of these versions.

You might only see a slight improvement, perhaps just a few percentage points. A typical script, which is a bit more complex than:

ColorBars.ConvertBits(32).ThisAndThatResize(4096,2048).ConvertBits(8, dither=1)
and is probably using many external filters, won't be processed visibly quicker. Personally, I wouldn't bother with them (though I don't use Avisynth myself; I'm just a developer). However, since using a faster option is free, why not give it a try?

I just note, since the additional builds require more time (5-30 minutes per build type) and computer power, I don't bother creating versions other than the stock XP-to-Win11 regular version in the early tests. More untested options lead to more user reports. The more choices given, the more requests: "Why not a special build for my i7-k18236812 or ZX-Spectrum?"

[Jamaika]

Originally Posted by pinterf

The variants are as follows (see folder names):
SSE2
SSE2 + AVX2
AVX2
AVX2 + AVX512 (for Ice Lake - 10th/11th gen i7 processors, for example)

Little green man. In avisynth and many add-ons, ALIGN is set for 64 memory, i.e. only for AVX512. What variants for older computers?
I wonder what will be soon for AVX10 and ALIGN 128.
As for Intel add-ons, I am surprised that I managed to add for gcc/mingw64. The general ones are for MSVCRT and the add-ons are paid.

[Emulgator]

Success here !
Win10P64, i9-11900K (AVX512) 128GB, RTX3080 16GB
Feeding AvsPmod64 2.7.9.2, or VD64 44282, or Topaz 2.6.4 all AviSynth64 builds 4198 work nice here:
20250224 WinXP or better, Intel ICX
20250225 ICXBase, ICXBase+AVX2, ICX AVX2, ICX AVX2+AVX512.
Untested by me so far: WinXP32, Win7x64
Under my environment all build versions seem compatible, no speed differences worth mentioning.
(I wasn't expecting any, given that my scripts and called plugins may not use higher AVX at all.)
Many thanks again, Ferenc !

P.S. That successfully testing system had MSVC Runtimes 14.42.34433.0
As found out by others in following posts, it may well be that these AviSynth+ICX builds only run under these more recent runtimes.
Will repeat tests soon with a similar mid-2024 frozen Win10P64 system (hopefully still) containing earlier runtimes.
P.P.S. An older Win7U64 system with runtimes from 2022 immediately reports access violation with the ICX Base build.

[tebasuna51]

My speed test:

W10 v1607, Ryzen 5 1600X, RAM 8 GB
Simple QTGMC(Preset="Fast", EZDenoise=2.0) over a DV.avi

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4198, master, x86_64) (3.7.3.0)

Number of frames:             40430
Length (hh:mm:ss.ms):  00:13:28.600
Frame width:                    720
Frame height:                   572
Framerate:                   50.000 (50/1)
Colorspace:                    YV12

                            xp-in-W10 r4198    icx-avx2  r4198    Clang     r4198    intelLLVM r4198
                            -----------------  -----------------  -----------------  -----------------
Frames processed:           40430 (0 - 40429)  40430 (0 - 40429)  40430 (0 - 40429)  40430 (0 - 40429)
FPS (min | max | average):  27.18|91.18|58.84  36.49|89.11|59.39  34.46|88.18|58.40  35.10|91.90|59.18
Process memory usage (max): 365 MiB            357 MiB            367 MiB            364 MiB
Thread count:               29                 29                 29                 29
CPU usage (average):        28.6%              28.7%              28.5%              28.5%

Time (elapsed):             00:11:27.124       00:11:20.760       00:11:32.247       00:11:23.202

Seems for me the icx-avx2 is the winner, but only by 1% fast over the xp.

[StvG]

Originally Posted by tebasuna51

My speed test: ...

I hope you tested every variant at least 3 times (or at least twice) and used average/median for the final results in order to have more reliable test.

[pinterf]

Originally Posted by StvG

I hope you tested every variant at least 3 times (or at least twice) and used average/median for the final results in order to have more reliable test.

Sometimes, I can see more than 1% difference between runs. Note also that the processor clock is not constant either. It's strange, but it also depends on how the memory was allocated, how the cache behaved, and how lucky the stars were at that moment of allocation. When the average starts showing a consistent 2% or more difference, one can be happy.

[StvG]

Originally Posted by pinterf

Sometimes, I can see more than 1% difference between runs. Note also that the processor clock is not constant either. It's strange, but it also depends on how the memory was allocated, how the cache behaved, and how lucky the stars were at that moment of allocation. When the average starts showing a consistent 2% or more difference, one can be happy.

You can add antivirus soft (if any), Windows SysMain (SuperFetch) to the equitation.

In some PC hardware forums when doing benches (Cinebench, Geekbench...) - antivirus is stopped and the bench app is assigned to the highest CPU priority. Several runs and the average/mean is taken.
Some folks go further and use a clean Windows installation just for the benches.

But when one see more than 5% difference, it's more likely caused by the different builds.

[DTL]

Originally Posted by pinterf

I've created ReleaseWithDebug builds.
I've put together a zip file with four Intel ICX builds of Avisynth.dll and Avisynth.pdb. Each build comes with its corresponding PDB debug info file. Please copy both the DLL and PDB files into the System32 directory.

Some good test results and some not very good:

1. At the 'fresh and rarely used' Win 7 x64 installation Base versions are working. The AVX2 and AVX2+AVX512 not crash but return some not very clear error in VirtualDub:

File open error (window title)
AVI Import Filter error: (Unknown) (80040154)


Also the 'main' release r4198 from 'x64_intel_icx' working too (in this Win 7 installation).

I use this Win7 installation mostly for rare things with MSVC2019 (and 2017) installed.

2. After reboot to my everyday used Win 7 x64 :
Base and initial release r4198 from 'x64_intel_icx' cause VirtualDub crash and AVX2 and AVX512 do not crash and display same
File open error (window title)
AVI Import Filter error: (Unknown) (80040154)


error message.

Unfortunately I do not have modern Visual Studio with x64 debugger installed in my 'everyday used' Win7 so can not use provided .pdb files. Any small and possibly portable x64 debugger for Win 7 can be recommended ? I do not have space to install Visual Studio in that Win 7 installation or it even can not run because of some damaging of system files (?). I do not remember why I uninstall it.

So the main test result: ICX builds can run in some 'fresh or very low/rare used' installations of Win 7 x64 but can cause Virtual Dub crash in some 'some time used or even some damaged' Win 7 x64 installations.

[DTL]

Originally Posted by Jamaika

In avisynth and many add-ons, ALIGN is set for 64 memory, i.e. only for AVX512. What variants for older computers?
I wonder what will be soon for AVX10 and ALIGN 128.

It is not only for AVX512. It is up to AVX512 (and the case you have 8bit single byte samples in some planar format).

It is back compatible with AVX256 and SSE.

The more alignment used - the more RAM wasted at the end of rows for some row widths. But 64bytes alignment also still not enough for AVX512 if you process 16 or 32bit per sample formats.

Also it is not enough if we have row processing loops reading/storing >1 512bit dataword per loop iteration.

It was old idea to have plugin-requested row stride and alignment for frame buffers so the plugin can use faster and more simple in design SIMD loops without special end part for processing remaining samples not possible to read/write with main loop using many SIMD datawords read-writes if single SIMD dataword is long enough.

Any increased row stride and alignment (by power of 2) is back compatible with old plugins (I hope). But too large stride and alignment will waste too much RAM with small frame sizes.

So other idea was to make user-configurable from script command row stride and alignment. But it must be supported by internal plugin design to get some benefit on fast hosts with AVX(all families) CPUs or modern CPUs. So plugin can check at plugin init the provided by AVS core row stride and alignment and can select better SIMD processing functions (processing larger data blocks if possible for single data burst exchange between register file and caches or host RAM).

[gispos]

None of the 3 icx variants work for me, all programs crash.
I have no problems with xp_version, IntelLVM and Clang.

Also cannot use the pdb file. VDub2 shows the same RAX error with all three variants.

[Jamaika]

Originally Posted by DTL

It is not only for AVX512. It is up to AVX512 (and the case you have 8bit single byte samples in some planar format).

It is back compatible with AVX256 and SSE.

The more alignment used - the more RAM wasted at the end of rows for some row widths. But 64bytes alignment also still not enough for AVX512 if you process 16 or 32bit per sample formats.

Also it is not enough if we have row processing loops reading/storing >1 512bit dataword per loop iteration.

It was old idea to have plugin-requested row stride and alignment for frame buffers so the plugin can use faster and more simple in design SIMD loops without special end part for processing remaining samples not possible to read/write with main loop using many SIMD datawords read-writes if single SIMD dataword is long enough.

Any increased row stride and alignment (by power of 2) is back compatible with old plugins (I hope). But too large stride and alignment will waste too much RAM with small frame sizes.

So other idea was to make user-configurable from script command row stride and alignment. But it must be supported by internal plugin design to get some benefit on fast hosts with AVX(all families) CPUs or modern CPUs. So plugin can check at plugin init the provided by AVS core row stride and alignment and can select better SIMD processing functions (processing larger data blocks if possible for single data burst exchange between register file and caches or host RAM).

There is no possibility of automatic alignment in Avisynth.
There is no record for different processors. And it is not only about the alignment value in the malloc function.
This value in avisynth is constant and is 64. In other functions it is converted to 64. For AVX2/AVX it is 32. So old processors do not have to work.

Example plugins RIFE:

#if NCNN_AVX512
#define NCNN_MALLOC_ALIGN 64
#elif NCNN_AVX
#define NCNN_MALLOC_ALIGN 32
#else
#define NCNN_MALLOC_ALIGN 16
#endif

static NCNN_FORCEINLINE void* fastMalloc(size_t size)
{
#if _MSC_VER
    return _aligned_malloc(size, NCNN_MALLOC_ALIGN);
#elif (defined(__unix__) || defined(__APPLE__)) && _POSIX_C_SOURCE >= 200112L || (__ANDROID__ && __ANDROID_API__ >= 17)
    void* ptr = 0;
    if (posix_memalign(&ptr, NCNN_MALLOC_ALIGN, size + NCNN_MALLOC_OVERREAD))
        ptr = 0;
    return ptr;
#elif __ANDROID__ && __ANDROID_API__ < 17
    return memalign(NCNN_MALLOC_ALIGN, size + NCNN_MALLOC_OVERREAD);
#else
    unsigned char* udata = (unsigned char*)malloc(size + sizeof(void*) + NCNN_MALLOC_ALIGN + NCNN_MALLOC_OVERREAD);
    if (!udata)
        return 0;
    unsigned char** adata = alignPtr((unsigned char**)udata + 1, NCNN_MALLOC_ALIGN);
    adata[-1] = udata;
    return adata;
#endif
}