Opened 4 years ago

Closed 4 years ago

#55 closed defect (fixed)

#pragma optimize("", off) in JEM7.0

Reported by: anjicheng Owned by:
Priority: minor Milestone: HM-16.6-JEM-7.1
Component: JEM Version: HM-16.6-JEM-7.0
Keywords: #pragma optimize("", off) Cc: ksuehring, XiangLi, jvet@…

Description

In the JEM7.0, the following code is added in the “TComTrQuant.cpp”

#if 1800 < _MSC_VER && _MSC_VER < 2000
#pragma optimize("", off)
#endif

The macro value “_MSC_VER”= 1900 for visual studio 2015. So for the VS2015, the above code makes the encoding time double for AI, and around 20-30% higher for RA and LD configurations.
Maybe the purpose of that code is to prevent some potential compiler failure for VS2015. But for our VS2015, there is no problem found to remove that code. So, if you use VS2015, you may try to speedup JEM7.0 by remove that code.

Change history (3)

comment:1 Changed 4 years ago by XiangLi

There seems a bug with VS2015 compiler optimization. It was reported that the default optimization option in release mode leads to encoding crash when EMT is off (--EMT=0). Therefore the optimization was disabled around function partialButterflyInverse4() to fix this issue. There also were similar issues with certain versions of gcc compilers (for example, please refer to "#if GCC_VERSION > 40600 && GCC_VERSION < 40700" in the code).

Regarding to the slower than expected encoding speed on Windows, we will try to find a better solution. Volunteer for the fix is absolutely welcomed.

comment:2 Changed 4 years ago by Chernyak

The issue was discussed on ticket 1463 of JCT-VC bug tracker few months ago. I made couple of tests on local PC and also obtain about 25% time increase for JEM7.0-workaround (#pragma optimize("", off)) on RA. Using 2nd workaround from HEVC ticket (volatile qualifier) I observe negligible time increase --- less than 1%.

It was reported that issue occurs for(since?) MSVC 2015 Update 3 (and only for x64 build in my experiments), so from my understanding 2nd workaround from HEVC tracker is better than 1st, because 1) it may be applied only for couple of problem variables (doesn't affect whole module); 2) only for certain complier(s), using precise preprocessor condition.

comment:3 Changed 4 years ago by XiangLi

  • Milestone set to HM-16.6-JEM-7.1
  • Priority changed from major to minor
  • Resolution set to fixed
  • Status changed from new to closed
  • Version set to HM-16.6-JEM-7.0

Thanks for the suggestion. /d2Qvec-sse2only (the same solution to HM) was applied to solve the issue in r575.

Note: See TracTickets for help on using tickets.