wxWidgets used in VTune: bring into Intel's attention

[Marián__VooDooMan__M]

Greetings,

This is just an attempt to bring into Intel's attention my project.

I have just realised nice VTune front-end (at least under Windows) is made with support of wxWidgets library.

I am user of this library, and I am distributing "patched for ICC" version of this library via github.

The basics are simple: my patcher just adds

[cpp]

#if defined(__INTEL_COMPILER) // VDM auto patch

# pragma ivdep

#endif

[/cpp]

before any loop.

Command-line operation is simple: run either with command-line option "-p" (stands for "patch"), or "-u" (stands for "unpatch", i.e. remove changes done with "-p" option). It will first chdir to ".." and then starts its operation by traversing sub-dirs and seeking for *.c, *.cpp, *.cxx, and so on, and do its work on them (patch/unpatch).

I have tested this-patched code, it is working well, since it seems there are no obvious vector dependencies inside of loops in wxWidgets library.

My wxWidgets' fork is hosted @ github, it called "wxWidgets-ICC-patch" and the patcher is inside "wxWidgets_vdm_patch" sub-dir.

It is released under "wxWindows License" (the same license as the original library), so you can freely try and possibly use it in VTune front-end, to speed-up the GUI.

[Marián__VooDooMan__M]

PS: I was trying to not give direct URL to github since I guess I would hit the spam filter... Everyone interested is able to make URL manually with instructions given in the post.

[Bernard]

Thanks for sharing.

Can actually measure any speed up of UI rendering when the patch is executed?

[Marián__VooDooMan__M]

@ iliyapolak

Actually, the UI is the bottleneck and always be the slowest part, since it depends on how fast Windows is manipulating shown controls.

The library has its own STL-like list container for e.g. combo box, and also the library has its port of zlib, jpg, tiff, and few others, so I guess there would we see the speed improvements.

[Bernard]

Thanks, I will give a try.

Btw.do you still have a BSOD?

[Marián__VooDooMan__M]

Actually, this code can work on ANY code and it will patch it.

iliyapolak wrote:

Btw.do you still have a BSOD?

Yes, I do, even with the latest patches from Microsoft (Microsoft's Tuesday). But please, use the original thread on this forum to retain consistency of posts.

[Bernard]

OK.I will post my answers on BSOD related thread.

[Marián__VooDooMan__M]

I have updated my patcher tool to the new version. Please, pull from git repo the latest (pretty stable) version.

[Marián__VooDooMan__M]

@ Intel staff:

ping?

[Bernard]

Thanks.

[David_A_Intel1]

Hi VooDooMan!

Thanks for your post.  We have no plans to incorporate your changes and would not be able to confirm it, anyway.

Personally, I think your "patch" is too simplistic and assumes that there are NO dependencies.  If there *are* dependencies, then your patch would break the code and result in problems.  It would require much testing to confirm that the patch does not break anything.  Problems could range from artifacts on the screen to crashes.

If the development team is interested, they may investigate.  Again, however, we would not be able to acknowledge whether or not we incorporated any changes based on your post.  Have you provided your enhancements to the open source project?

Thanks for your interest and participation in the forums!

[Marián__VooDooMan__M]

MrAnderson (Intel) wrote:

Have you provided your enhancements to the open source project?

I am using it in my project (visual programming as a front-end, real-time sound generation) and I have not encountered any problems. I plan to release my mature project as open source in the future.

[Marián__VooDooMan__M]

MrAnderson (Intel) wrote:

Personally, I think your "patch" is too simplistic and assumes that there are NO dependencies.  If there *are* dependencies, then your patch would break the code and result in problems.

But this is challenge for ICC to detect these dependencies in code analysis. "#pragma ivdep" is not so aggressive as "#pragma simd".

[Marián__VooDooMan__M]

MrAnderson (Intel) wrote:

Personally, I think your "patch" is too simplistic and assumes that there are NO dependencies.  If there *are* dependencies, then your patch would break the code and result in problems.

Actually, wxWidgets library does not use external dependencies, like pointer aliasing inside loops that are patched by my "patcher". I am extensively testing my-patched wxWidgets for few years, and I have not encountered any problems.

Anyways, I still thing ICC is so intelligent and could detect these kinds of dependencies (like pointer aliasing outside of loop) when it encounters "#pragma ivdep", and thus ignore "'#pragma ivdep" with warning like "ignoring ivdep: vector dependency detected".

[Marián__VooDooMan__M]

MrAnderson (Intel) wrote:

Personally, I think your "patch" is too simplistic and assumes that there are NO dependencies.  If there *are* dependencies, then your patch would break the code and result in problems.  It would require much testing to confirm that the patch does not break anything.  Problems could range from artifacts on the screen to crashes.

yes, of course, but it is up to compiler (Intel's one) to detect such issues (e.g. intrinsic dependencies of loops...).

MrAnderson (Intel) wrote:

If the development team is interested, they may investigate.  Again, however, we would not be able to acknowledge whether or not we incorporated any changes based on your post.  Have you provided your enhancements to the open source project?

Yes, with my patch it seems the measurements shows better results via bench-markings, except for JPG handling part library of wxWidgets library, where bench-markings shows a little bit slower execution.