I have created my OpenCL code in a dll which I am loading in my application.
Now for my 64 bit application it is crashing for the call getPlatformIds().
However Dependency Walker is showing everything is 64 bit and no errors.
But the same application with 32 bit is working perfectly.
Is it possible that my GPU cannot perform 64 bit tasks?
But C:/Windows/System32/OpenCL.dll is also 64 bit so probably my hardware is ok?
How do I determine what might be causing the crash?
Husshhhh....
The issue is finally resolved...:)
Looks like there is some linker problem with the MinGW 64 bit compiler.
The solution is to link the libopencl.a file instead of OpenCL.dll for building 64 bit applications.
While building for 32 bit applications does not require this i.e. you can link with OpenCL.dll.
Now only if somebody can fix this issue which has been open for past 4 years!
Related
Actually I want to link 64 bit library to my 32 bit application.
I want to use a library which works faster under 64 bits under some circumstances. But i have to link that library to my 32 bit application . Is it possible or not ??
In a word, no. The only way to get compiled 64bit code talking to compiled 32bit code is via some form of IPC (e.g. pipe, named pipe, or network connection). That may well introduce performance bottlenecks of its own, so probably isn't worth the bother.
It is not easy as #robthebloke mentioned. But NVIDIA RTX Remix Runtime does it somehow, making older 32bit games running on 64-bit vulkan driver (bypassing 2-4GB virtual memory limit).
I am developing a web application that contains some features which do not work unless the application is built in 32 bit mode.
This limitation forces me to build the whole application in 32 bit mode, which produces some limitation on memory consumption of the application which is limited to 2 GB.
How can I find a solution for this problem?
You need to split the 32-bit code and 64-bit code into two processes and communicate between the two.
You cannot load and execute 32-bit in a 64-bit process or vice versa.
Or, you can change the code that has memory constraints to use and process data differently.
Assuming you have a 64 bit capable processor running a 32 bit operating system. Would it be possible to run some 64 bit assembly instructions in a 32 bit program? Can't see why not if you have a 64 bit capable processor, but there are so many stingy technical issues in computing, especially the operating system.
NOTE I am not talking about running a 64 bit program on a 32 bit os, just using 64 bit assembly instructions embedded in a 32 bit program.
The thing you would most need to know on this is to make sure you make your processor mode transitions correctly. You need to do some basic work to transition from 32 bit mode into 64 bit mode (also called long mode). The biggest issue would be making sure you set up the descriptor table correctly. Some more info is here:
http://www.codeproject.com/Articles/45788/The-Real-Protected-Long-mode-assembly-tutorial-for
Hope this helps.
I am creating a quite simple application which reads and display text files and search through them.
I am asking myself if there is any interest for me to propose 32 and 64 bits version to the user.
Is the difference only in having access to more memory heap size with the 64 bit version or is there any other interest ?
Will a 32 bit compiled program work on a 64 bits JVM (I assume yes)
The only differences between 32-bit and 64-bit builds of any program are the sizes of machine words, the amount of addressable memory, and the Operating System ABI in use. With Java, the language specification means that the differences in machine word size and OS ABI should not matter at all unless you're using native code as well. (Native code must be built to be the same as the word-size of the JVM that will load it; you can't mix 32-bit and 64-bit builds in the same process without very exotic coding indeed, and you shouldn't be doing that with Java about.)
The only times that have swung it for me is when there have been native libraries involved that have pushed it one way or the other. If you're just in Java land then realistically, unless you need >4GB of heap size, there's very little difference.
EDIT: The differences include things like it uses slightly more memory than 32 bit, significantly more if you're using a version before 6u23 and aren't using -XX:+UseCompressedOops. There may also be a slight performance difference between the two, but again nothing huge.
SandCastle is unable to process our class library because it crashes with an OutOfMemoryException exception during XSL transformation.
What can we do about that, except for the obvious, buy more memory? The problem is that this is our developer machines with 3.3GB memory on a 32-bit OS so basically we either have to upgrade to 64-bit and more memory (which won't happen for a while) or set up a virtual server to do this with lots of memory (which will impact production servers).
I seriously doubt we have the biggest class library in the world that requires help files, so what options do we have? Is there a magic "Do not crash with out of memory errors" setting that we forgot to turn off?
If you're on 32 bit Windows, your user process will only be able to address 2 GB memory per default (3 GB is run as large address aware). The 2 GB are used for everything in the process, so the .NET runtime, standard libraries, booking and so forth all take their chuck. In my experience that leaves about 1.5 GB for .NET applications on 32 bit.
You can get access to more memory by using the large address aware switch, but it doesn't come for free if you're on 32 bit Windows. Moving to 64 bit Windows will let your 32 bit application access the entire 32 bit address space and thus give you 4 GB addressable space.
I've recently written a blog entry with details about memory usage for .NET applications, but since I blog in Danish, you may not be able to read it. However, if you want to have a look, the link is: http://kodehoved.dk/?p=156
You may also find this MSDN blog post relevant: http://blogs.msdn.com/maoni/archive/2007/05/15/64-bit-vs-32-bit.aspx