1

I want to interface a C library with matlab with Mex-files, so I built and compiled the library, and then I wrote each mex-file and compiled too, with the help of Visual Studio. I did that for x32, and it worked fine in Matlab (x32). The problem is that I need more memory in Matlab, so I need to use Matlab (x64). I did the same process, but compiling in x64, and now I can execute this mex functions in Matlab. The problem is that, the same mex function, in Matlab x32 takes about 0.07sec, and in Matlab x64, 41 seconds. Anyone has any idea about what is failling, or what could I do for solve the problem?

Thanks in advance

Blanca Quingal
  • 19
  • 3
  • are you running with the same inputs, same sizes? is it possible that other processes running on your machine while you run the benchmark? – Shai May 05 '15 at 12:57
  • 3
    That's wild. Is the MEX source code small enough that you could post it? Same source code for x32 and x64, just compiled under a different architecture? What C library are you interfacing with? – Andrew Janke May 05 '15 at 13:00
  • 3
    Did you compile with optimizations on with the 64 bit version? – NathanOliver May 05 '15 at 13:46
  • 2
    800x? That's rather strange. Please post any code that helps exemplify your point. I'm rather skeptical. – rayryeng May 05 '15 at 14:50
  • First of all thank you for your rapid responses. I've been doing new tests and I've tried a different compiler, in this case Visual Studio 2012. I've test again the mex files, and now matlab x32 takes about 10 times less than matlab x64, it depends on the mex function and on the input. I think this is because of configuration of Visual Studio 2010 for x64, and algo because of the optimization configuration. – Blanca Quingal May 06 '15 at 07:56
  • @Shai , Yes, I'm running with the same inputs and the same sizes and I think that is no problem of other processes running on my machine, because I compile the different matlabs in the same computer. Thanks – Blanca Quingal May 06 '15 at 07:58
  • @NathanOliver You were right. I'm new in the use of Visual Studio and I didn't change this parameter. Now I've chaged this in Visual Studio 2012 and the execution is faster, but still slower than with x32. Thank you – Blanca Quingal May 06 '15 at 07:59
  • Sorry @AndrewJanke, the code is not small enough, and moreover I have too many codes with the same problem, so I think it's not a code problem, I dont know. The code is the same for x32 and x64, just compiled under a different architecture. Thank you! – Blanca Quingal May 06 '15 at 08:01
  • I'm sorry @rayryeng, but the are too many scripts and the code is not very small to post here, if I could give you another relevant information that could me exemplify better, let's me know. Thanks – Blanca Quingal May 06 '15 at 08:03
  • you can take a script that can reproduce the problem or create an [MCVE](http://stackoverflow.com/help/mcve)/[SSCCE](http://sscce.org/) and post it here. And also remember to compile in release mode with both `/O2` and `/O3` and compare – phuclv May 06 '15 at 09:27
  • Thank you, i'll try to post some code here. About compile in release mode, I've tried that, but when I use in Matlab the mex function compiled for x64 in release mode, this crashes, but this doesn't happen with debud mode, I dont know why. In the case of the x32 mex functions, matlab work's fine with the release mode. Thank @LưuVĩnhPhúc – Blanca Quingal May 06 '15 at 09:59
  • that means your code is using some non portable properties, for example assuming pointers to be 32 bits. There are some differences in release and debug mode, for example [uninitialized variables will be set to 0xCCCCCCCC... in debug mode](http://stackoverflow.com/q/370195/995714) but not in release mode, and `assert`s are disabled in release mode, so some bug will appear – phuclv May 06 '15 at 10:02

0 Answers0