cublas: very slow init

[morris]

I use the C:\Cula as it avoids the blank space in Program Files and/or Program file x86. I work with cygwin _and_ the VS Win64 console and spaces require different quoting.

I can only guess that I did not unistall 1.1 correcly and then installed 1.1b. I wish I had not deleted 1.1, as I can only download 1.0 or 1.1b.

Here is question:

For what reason are these shared libraries copied to the executable directory in benchmark_vc9 (taken from "post-link events")?

copy "$(CULA_BIN_PATH_64)\cudart.dll" "$(OutDir)"
copy "$(CULA_BIN_PATH_64)\cublas.dll" "$(OutDir)"
copy "$(CULA_BIN_PATH_64)\cula.dll" "$(OutDir)"

The paths are set in the env. vars, so why have the demo copy them, and when these are not copied, does culaInitialize() take 5 seconds?

Morris

[morris]

It looks like the cula.dll reference inside benchmark.exe has ver. 1.0.0.0. Here is what I did:

-Ran uninstall.exe in C:\Cula
-Deleted Cula env vars and on PATH
-Rebooted
-Fresh install of cula_1.1b-win64.exe
-Built benchmark_vc9.sln, main only calls status = culaInitialize(); and culaShutdown();(still exhibits 5 sec delay if dlls are not in pwd)
-Examined benchmark.exe under Dependency Walker:

Module Real Checksum CPU File Ver

CUBLAS.DLL 0x013F5BFB x64 6.14.11.2030
CUDART.DLL 0x00096F8E x64 6.14.11.2030
CULA.DLL 0x00A50207 x64 1.0.0.0

------------------------------------------------------------------------
System Information Summary
------------------------------------------------------------------------

Host Name: NUMBERCRUNCHER
OS Name: Microsoft© Windows VistaT Business
OS Version: 6.0.6002 Service Pack 2 Build 6002
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor Free
(...)

[dan]

What path does dependency walker say that cula.dll is located in? I think it's an older copy.

Also, what are the values of these variables?

$PATH
$CULA_BIN_PATH_32
$CULA_BIN_PATH_64
$CULA_LIB_PATH_32
$CULA_LIB_PATH_64

The CULA examples copy over the relevant shared libraries so that the user can still run them without adding CULA to their path. Also, this allows the user to run cross-compiled configurations (e.g. 32-bit configuration on 64-bit machine) without having to change their path for each configuration. Note that this is only relevant for Windows machines.

Dan

[morris]

Sadly, DependencyWalker shows cula.dll as a child of benchmark.exe, regardless of whether cula.dll exists in the same dir as benchmark.exe.

However, once I deleted the local copy of cula.dll (in Release), and double-clicked cula.dll inside DependencyWalker, an error msg came up saying there was an error with C:/programfiles/accelereyes/bin/cula.dll: So you were right: I still had a version 1.0 still lingering.

Indeed, you suggested to print out my path and it had no mention of my Cula directory.

Lessons learned: Watch for multiple paths to cula.dll included from not just previous versions of Cula but from other programs.

Thanks for your patient tutoring of my somewhat pedantic problem.

Morris

[dan]

I'm glad to hear that you were able to figure out the problem. It's a common one, , so hopefully other users who accidentally run into the same problem as yourself will be able to learn from this thread.

Best of luck,

Dan