I'm attempting to isolate some problems with a Theano/Windows/GPU setup (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano latest git) . I isolated the theano nvcc call and separated that out. Standalone, from a VS2010 command prompt, the nvcc command gives the following output:
which produces the following error: ./cuda_ndarray.cu(480): warning: conversion from pointer to smaller integer
./cuda_ndarray.cu(769): warning: statement is unreachable
./cuda_ndarray.cu(850): error: expression must have a constant value
./cuda_ndarray.cu(865): error: no instance of function template "CudaNdarray_alloc_contiguous" matches the argument list argument types are: (CudaNdarray *, int, <error-type>)
./cuda_ndarray.cu(2258): warning: conversion from pointer to smaller integer
2 errors detected in the compilation of "C:/Users/mfenner/AppData/Local/Temp/tmp xft_0000060c_00000000-6_cuda_ndarray.cpp1.ii".
On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> wrote:
> Hi folks,
> I'm attempting to isolate some problems with a Theano/Windows/GPU setup
> (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano latest git) .
> I isolated the theano nvcc call and separated that out. Standalone, from a
> VS2010 command prompt, the nvcc command gives the following output:
> which produces the following error:
> ./cuda_ndarray.cu(480): warning: conversion from pointer to smaller integer
> ./cuda_ndarray.cu(769): warning: statement is unreachable
> ./cuda_ndarray.cu(850): error: expression must have a constant value
> ./cuda_ndarray.cu(865): error: no instance of function template
> "CudaNdarray_alloc_contiguous" matches the argument list
> argument types are: (CudaNdarray *, int, <error-type>)
> ./cuda_ndarray.cu(2258): warning: conversion from pointer to smaller integer
> 2 errors detected in the compilation of
> "C:/Users/mfenner/AppData/Local/Temp/tmp
> xft_0000060c_00000000-6_cuda_ndarray.cpp1.ii".
I'm working with the development version of Theano. The specific git commit id is:
% git log --oneline | more
b672a3a Merge pull request #758 from goodfeli/doc
The follow should get the version of cuda_ndarray.cu that I'm working against (from a working directory of Theano/theano/sandbox/cuda):
% git show b672a3a:./cuda_ndarray.cu
On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
> witch verison of theano do you use? Also, can you join your version of > cuda_ndarray.cu file? That way, I can know what the line number mean.
> This line you give: > > argument types are: (CudaNdarray *, int, <error-type>)
> the last parameter don't seam good. But this is working on linux. So > it is probably something that is different on linux and windows.
> thanks for the report.
> Fred
> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> wrote: > > Hi folks,
> > I'm attempting to isolate some problems with a Theano/Windows/GPU setup > > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano latest > git) . > > I isolated the theano nvcc call and separated that out. Standalone, > from a > > VS2010 command prompt, the nvcc command gives the following output:
> > which produces the following error: > > ./cuda_ndarray.cu(480): warning: conversion from pointer to smaller > integer
> > ./cuda_ndarray.cu(769): warning: statement is unreachable
> > ./cuda_ndarray.cu(850): error: expression must have a constant value
> > ./cuda_ndarray.cu(865): error: no instance of function template > > "CudaNdarray_alloc_contiguous" matches the argument list > > argument types are: (CudaNdarray *, int, <error-type>)
> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to smaller > integer
> > 2 errors detected in the compilation of > > "C:/Users/mfenner/AppData/Local/Temp/tmp > > xft_0000060c_00000000-6_cuda_ndarray.cpp1.ii".
On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> wrote:
> Fred,
> Hi. Thanks for your interest in my problem.
> I'm working with the development version of Theano. The specific git commit
> id is:
> % git log --oneline | more
> b672a3a Merge pull request #758 from goodfeli/doc
> The follow should get the version of cuda_ndarray.cu that I'm working
> against (from a working directory of Theano/theano/sandbox/cuda):
> % git show b672a3a:./cuda_ndarray.cu
> Let me know if I can provide anything else.
> Best,
> Mark
> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>> witch verison of theano do you use? Also, can you join your version of
>> cuda_ndarray.cu file? That way, I can know what the line number mean.
>> This line you give:
>> > argument types are: (CudaNdarray *, int, <error-type>)
>> the last parameter don't seam good. But this is working on linux. So
>> it is probably something that is different on linux and windows.
>> thanks for the report.
>> Fred
>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> wrote:
>> > Hi folks,
>> > I'm attempting to isolate some problems with a Theano/Windows/GPU setup
>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano latest
>> > git) .
>> > I isolated the theano nvcc call and separated that out. Standalone,
>> > from a
>> > VS2010 command prompt, the nvcc command gives the following output:
>> > which produces the following error:
>> > ./cuda_ndarray.cu(480): warning: conversion from pointer to smaller
>> > integer
>> > ./cuda_ndarray.cu(769): warning: statement is unreachable
>> > ./cuda_ndarray.cu(850): error: expression must have a constant value
>> > ./cuda_ndarray.cu(865): error: no instance of function template
>> > "CudaNdarray_alloc_contiguous" matches the argument list
>> > argument types are: (CudaNdarray *, int, <error-type>)
>> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to smaller
>> > integer
>> > 2 errors detected in the compilation of
>> > "C:/Users/mfenner/AppData/Local/Temp/tmp
>> > xft_0000060c_00000000-6_cuda_ndarray.cpp1.ii".
On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> wrote:
> I found the reason,
> This microsoft compiler don't support variable len array in there c++
> compilier. So this line is not accepted:
> I made a new PR and David just reviewed it. So if you update your
> version of Theano, it should work.
> thanks for the report. If there is other problem(i hope not), don't
> hesitate to tell us.
> Fred
> On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> wrote:
>> Fred,
>> Hi. Thanks for your interest in my problem.
>> I'm working with the development version of Theano. The specific git commit
>> id is:
>> % git log --oneline | more
>> b672a3a Merge pull request #758 from goodfeli/doc
>> The follow should get the version of cuda_ndarray.cu that I'm working
>> against (from a working directory of Theano/theano/sandbox/cuda):
>> % git show b672a3a:./cuda_ndarray.cu
>> Let me know if I can provide anything else.
>> Best,
>> Mark
>> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>>> witch verison of theano do you use? Also, can you join your version of
>>> cuda_ndarray.cu file? That way, I can know what the line number mean.
>>> This line you give:
>>> > argument types are: (CudaNdarray *, int, <error-type>)
>>> the last parameter don't seam good. But this is working on linux. So
>>> it is probably something that is different on linux and windows.
>>> thanks for the report.
>>> Fred
>>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> wrote:
>>> > Hi folks,
>>> > I'm attempting to isolate some problems with a Theano/Windows/GPU setup
>>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano latest
>>> > git) .
>>> > I isolated the theano nvcc call and separated that out. Standalone,
>>> > from a
>>> > VS2010 command prompt, the nvcc command gives the following output:
>>> > which produces the following error:
>>> > ./cuda_ndarray.cu(480): warning: conversion from pointer to smaller
>>> > integer
>>> > ./cuda_ndarray.cu(769): warning: statement is unreachable
>>> > ./cuda_ndarray.cu(850): error: expression must have a constant value
>>> > ./cuda_ndarray.cu(865): error: no instance of function template
>>> > "CudaNdarray_alloc_contiguous" matches the argument list
>>> > argument types are: (CudaNdarray *, int, <error-type>)
>>> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to smaller
>>> > integer
>>> > 2 errors detected in the compilation of
>>> > "C:/Users/mfenner/AppData/Local/Temp/tmp
>>> > xft_0000060c_00000000-6_cuda_ndarray.cpp1.ii".
On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
> My first merge fix introduced a bug. Now it is fixed. So you should > reupdate.
> Fred
> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> > wrote: > > I found the reason,
> > This microsoft compiler don't support variable len array in there c++ > > compilier. So this line is not accepted:
> > I made a new PR and David just reviewed it. So if you update your > > version of Theano, it should work.
> > thanks for the report. If there is other problem(i hope not), don't > > hesitate to tell us.
> > Fred
> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> wrote: > >> Fred,
> >> Hi. Thanks for your interest in my problem.
> >> I'm working with the development version of Theano. The specific git > commit > >> id is:
> >> % git log --oneline | more > >> b672a3a Merge pull request #758 from goodfeli/doc
> >> The follow should get the version of cuda_ndarray.cu that I'm working > >> against (from a working directory of Theano/theano/sandbox/cuda): > >> % git show b672a3a:./cuda_ndarray.cu
> >> Let me know if I can provide anything else.
> >> Best, > >> Mark
> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
> >>> witch verison of theano do you use? Also, can you join your version of > >>> cuda_ndarray.cu file? That way, I can know what the line number mean.
> >>> This line you give: > >>> > argument types are: (CudaNdarray *, int, <error-type>)
> >>> the last parameter don't seam good. But this is working on linux. So > >>> it is probably something that is different on linux and windows.
> >>> thanks for the report.
> >>> Fred
> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> > wrote: > >>> > Hi folks,
> >>> > I'm attempting to isolate some problems with a Theano/Windows/GPU > setup > >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano latest > >>> > git) . > >>> > I isolated the theano nvcc call and separated that out. Standalone, > >>> > from a > >>> > VS2010 command prompt, the nvcc command gives the following output:
On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
> Fred,
> Thank you very much for working on this. I will update my repository and > try it again sometime today.
> Best,
> Mark
> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>> My first merge fix introduced a bug. Now it is fixed. So you should >> reupdate.
>> Fred
>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >> wrote: >> > I found the reason,
>> > This microsoft compiler don't support variable len array in there c++ >> > compilier. So this line is not accepted:
>> > I made a new PR and David just reviewed it. So if you update your >> > version of Theano, it should work.
>> > thanks for the report. If there is other problem(i hope not), don't >> > hesitate to tell us.
>> > Fred
>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> wrote: >> >> Fred,
>> >> Hi. Thanks for your interest in my problem.
>> >> I'm working with the development version of Theano. The specific git >> commit >> >> id is:
>> >> % git log --oneline | more >> >> b672a3a Merge pull request #758 from goodfeli/doc
>> >> The follow should get the version of cuda_ndarray.cu that I'm working >> >> against (from a working directory of Theano/theano/sandbox/cuda): >> >> % git show b672a3a:./cuda_ndarray.cu
>> >> Let me know if I can provide anything else.
>> >> Best, >> >> Mark
>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>> >>> witch verison of theano do you use? Also, can you join your version >> of >> >>> cuda_ndarray.cu file? That way, I can know what the line number >> mean.
>> >>> This line you give: >> >>> > argument types are: (CudaNdarray *, int, <error-type>)
>> >>> the last parameter don't seam good. But this is working on linux. So >> >>> it is probably something that is different on linux and windows.
>> >>> thanks for the report.
>> >>> Fred
>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> >> wrote: >> >>> > Hi folks,
>> >>> > I'm attempting to isolate some problems with a Theano/Windows/GPU >> setup >> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano >> latest >> >>> > git) . >> >>> > I isolated the theano nvcc call and separated that out. >> Standalone, >> >>> > from a >> >>> > VS2010 command prompt, the nvcc command gives the following output:
Most likely won't help, but just in case, run "python theano-cache clear"
(theano-cache can be found in the bin subfolder). Sometimes outdated
compiled code can lead to weird linking errors.
> The patch seems to have fixed the nvcc compilation error. Thanks again!
> Now, I'm getting a large number of link errors. I will try to debug and
> isolate what's going on there.
> Best,
> Mark
> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>> Fred,
>> Thank you very much for working on this. I will update my repository and
>> try it again sometime today.
>> Best,
>> Mark
>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>> My first merge fix introduced a bug. Now it is fixed. So you should
>>> reupdate.
>>> Fred
>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org>
>>> wrote:
>>> > I found the reason,
>>> > This microsoft compiler don't support variable len array in there c++
>>> > compilier. So this line is not accepted:
>>> > I made a new PR and David just reviewed it. So if you update your
>>> > version of Theano, it should work.
>>> > thanks for the report. If there is other problem(i hope not), don't
>>> > hesitate to tell us.
>>> > Fred
>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com>
>>> wrote:
>>> >> Fred,
>>> >> Hi. Thanks for your interest in my problem.
>>> >> I'm working with the development version of Theano. The specific git
>>> commit
>>> >> id is:
>>> >> % git log --oneline | more
>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>> >> The follow should get the version of cuda_ndarray.cu that I'm
>>> working
>>> >> against (from a working directory of Theano/theano/sandbox/cuda):
>>> >> % git show b672a3a:./cuda_ndarray.cu
>>> >> Let me know if I can provide anything else.
>>> >> Best,
>>> >> Mark
>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>>> >>> witch verison of theano do you use? Also, can you join your version
>>> of
>>> >>> cuda_ndarray.cu file? That way, I can know what the line number
>>> mean.
>>> >>> This line you give:
>>> >>> > argument types are: (CudaNdarray *, int, <error-type>)
>>> >>> the last parameter don't seam good. But this is working on linux. So
>>> >>> it is probably something that is different on linux and windows.
>>> >>> thanks for the report.
>>> >>> Fred
>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com>
>>> wrote:
>>> >>> > Hi folks,
>>> >>> > I'm attempting to isolate some problems with a Theano/Windows/GPU
>>> setup
>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano
>>> latest
>>> >>> > git) .
>>> >>> > I isolated the theano nvcc call and separated that out.
>>> Standalone,
>>> >>> > from a
>>> >>> > VS2010 command prompt, the nvcc command gives the following
>>> output:
Notice the important addition of "--machine 32" at the tail end. This resolved a large number (10s? 100s?) of LNK2019, unresolved external symbol errors that look like this:
tmpxft_000005a0_00000000-15_cuda_ndarray.obj : error LNK2019: unresolved external symbol __imp_PyErr_Format referenced in function "void * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
I'm personally a little confused as to what "bit-ness" my toolchain is -- I initially thought I was aiming for an "all 64-bit" toolchain (from python to python libs to nvidia components to compiled/linked nvcc code). However, it appears I was mistaken and/or I decided/realized I needed to move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how the internal theano/nvcc compilation goes.
Also: I saw a comment that talked about unrecognized "<" and the need to register ".cu" files (I think) in Visual Studio. It's the last comment (currently) on this SO thread. Incidentally, that thread deals with some of the issues in using CUDA 4 with VS2010.
http://stackoverflow.com/questions/3778799/how-do-i-start-a-cuda-app-...
On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
> Most likely won't help, but just in case, run "python theano-cache clear" > (theano-cache can be found in the bin subfolder). Sometimes outdated > compiled code can lead to weird linking errors.
>> The patch seems to have fixed the nvcc compilation error. Thanks again!
>> Now, I'm getting a large number of link errors. I will try to debug and >> isolate what's going on there.
>> Best,
>> Mark
>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>> Fred,
>>> Thank you very much for working on this. I will update my repository >>> and try it again sometime today.
>>> Best,
>>> Mark
>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>> My first merge fix introduced a bug. Now it is fixed. So you should >>>> reupdate.
>>>> Fred
>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >>>> wrote: >>>> > I found the reason,
>>>> > This microsoft compiler don't support variable len array in there c++ >>>> > compilier. So this line is not accepted:
>>>> > I made a new PR and David just reviewed it. So if you update your >>>> > version of Theano, it should work.
>>>> > thanks for the report. If there is other problem(i hope not), don't >>>> > hesitate to tell us.
>>>> > Fred
>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> >>>> wrote: >>>> >> Fred,
>>>> >> Hi. Thanks for your interest in my problem.
>>>> >> I'm working with the development version of Theano. The specific >>>> git commit >>>> >> id is:
>>>> >> % git log --oneline | more >>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>> >> The follow should get the version of cuda_ndarray.cu that I'm >>>> working >>>> >> against (from a working directory of Theano/theano/sandbox/cuda): >>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>> >> Let me know if I can provide anything else.
>>>> >> Best, >>>> >> Mark
>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>>>> >>> witch verison of theano do you use? Also, can you join your version >>>> of >>>> >>> cuda_ndarray.cu file? That way, I can know what the line number >>>> mean.
>>>> >>> This line you give: >>>> >>> > argument types are: (CudaNdarray *, int, >>>> <error-type>)
>>>> >>> the last parameter don't seam good. But this is working on linux. >>>> So >>>> >>> it is probably something that is different on linux and windows.
>>>> >>> thanks for the report.
>>>> >>> Fred
>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> >>>> wrote: >>>> >>> > Hi folks,
>>>> >>> > I'm attempting to isolate some problems with a Theano/Windows/GPU >>>> setup >>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano >>>> latest >>>> >>> > git) . >>>> >>> > I isolated the theano nvcc call and separated that out. >>>> Standalone, >>>> >>> > from a >>>> >>> > VS2010 command prompt, the nvcc command gives the following >>>> output:
Thanks for the info. Please let us know if adding "--machine 32" is enough to solve your problem.
It would also be interesting to know which part of your toolchain is 32 bit:
- Python?
- Cuda?
- Visual Studio?
-=- Olivier
Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
> Notice the important addition of "--machine 32" at the tail end. This resolved a large number (10s? 100s?) of LNK2019, unresolved external symbol errors that look like this:
> tmpxft_000005a0_00000000-15_cuda_ndarray.obj : error LNK2019: unresolved external symbol __imp_PyErr_Format referenced in function "void * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
> I'm personally a little confused as to what "bit-ness" my toolchain is -- I initially thought I was aiming for an "all 64-bit" toolchain (from python to python libs to nvidia components to compiled/linked nvcc code). However, it appears I was mistaken and/or I decided/realized I needed to move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how the internal theano/nvcc compilation goes.
> Also: I saw a comment that talked about unrecognized "<" and the need to register ".cu" files (I think) in Visual Studio. It's the last comment (currently) on this SO thread. Incidentally, that thread deals with some of the issues in using CUDA 4 with VS2010.
> http://stackoverflow.com/questions/3778799/how-do-i-start-a-cuda-app-...
> Best,
> Mark
> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
> Most likely won't help, but just in case, run "python theano-cache clear" (theano-cache can be found in the bin subfolder). Sometimes outdated compiled code can lead to weird linking errors.
> -=- Olivier
> 2012/7/23 Mark <mark.fen...@coveros.com>
> The patch seems to have fixed the nvcc compilation error. Thanks again!
> Now, I'm getting a large number of link errors. I will try to debug and isolate what's going on there.
> Best,
> Mark
> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
> Fred,
> Thank you very much for working on this. I will update my repository and try it again sometime today.
> Best,
> Mark
> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
> My first merge fix introduced a bug. Now it is fixed. So you should reupdate.
> Fred
> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> wrote: > > I found the reason,
> > This microsoft compiler don't support variable len array in there c++ > > compilier. So this line is not accepted:
> > I made a new PR and David just reviewed it. So if you update your > > version of Theano, it should work.
> > thanks for the report. If there is other problem(i hope not), don't > > hesitate to tell us.
> > Fred
> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> wrote: > >> Fred,
> >> Hi. Thanks for your interest in my problem.
> >> I'm working with the development version of Theano. The specific git commit > >> id is:
> >> % git log --oneline | more > >> b672a3a Merge pull request #758 from goodfeli/doc
> >> The follow should get the version of cuda_ndarray.cu that I'm working > >> against (from a working directory of Theano/theano/sandbox/cuda): > >> % git show b672a3a:./cuda_ndarray.cu
> >> Let me know if I can provide anything else.
> >> Best, > >> Mark
> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
> >>> witch verison of theano do you use? Also, can you join your version of > >>> cuda_ndarray.cu file? That way, I can know what the line number mean.
> >>> This line you give: > >>> > argument types are: (CudaNdarray *, int, <error-type>)
> >>> the last parameter don't seam good. But this is working on linux. So > >>> it is probably something that is different on linux and windows.
> >>> thanks for the report.
> >>> Fred
> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> wrote: > >>> > Hi folks,
> >>> > I'm attempting to isolate some problems with a Theano/Windows/GPU setup > >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano latest > >>> > git) . > >>> > I isolated the theano nvcc call and separated that out. Standalone, > >>> > from a > >>> > VS2010 command prompt, the nvcc command gives the following output:
This might be too obvious and you may be already doing it, but were you using the x64/Win64 command prompt?
I remember having a number of issues compiling other software because I was using the "Visual Studio Command Prompt (2010)" instead of the "Visual Studio x64 Win64 Command Prompt (2010)". If you don't use the latter then all sorts of wrong libraries will be used.
> Notice the important addition of "--machine 32" at the tail end. This > resolved a large number (10s? 100s?) of LNK2019, unresolved external > symbol errors that look like this:
> tmpxft_000005a0_00000000-15_cuda_ndarray.obj : error LNK2019: unresolved > external symbol __imp_PyErr_Format referenced in function "void * __cdecl > device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
> I'm personally a little confused as to what "bit-ness" my toolchain is -- > I initially thought I was aiming for an "all 64-bit" toolchain (from python > to python libs to nvidia components to compiled/linked nvcc code). > However, it appears I was mistaken and/or I decided/realized I needed to > move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how > the internal theano/nvcc compilation goes.
> Also: I saw a comment that talked about unrecognized "<" and the need to > register ".cu" files (I think) in Visual Studio. It's the last comment > (currently) on this SO thread. Incidentally, that thread deals with some > of the issues in using CUDA 4 with VS2010.
> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>> Most likely won't help, but just in case, run "python theano-cache clear" >> (theano-cache can be found in the bin subfolder). Sometimes outdated >> compiled code can lead to weird linking errors.
>>> The patch seems to have fixed the nvcc compilation error. Thanks again!
>>> Now, I'm getting a large number of link errors. I will try to debug and >>> isolate what's going on there.
>>> Best,
>>> Mark
>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>> Fred,
>>>> Thank you very much for working on this. I will update my repository >>>> and try it again sometime today.
>>>> Best,
>>>> Mark
>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>> My first merge fix introduced a bug. Now it is fixed. So you should >>>>> reupdate.
>>>>> Fred
>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >>>>> wrote: >>>>> > I found the reason,
>>>>> > This microsoft compiler don't support variable len array in there >>>>> c++ >>>>> > compilier. So this line is not accepted:
>>>>> > I made a new PR and David just reviewed it. So if you update your >>>>> > version of Theano, it should work.
>>>>> > thanks for the report. If there is other problem(i hope not), don't >>>>> > hesitate to tell us.
>>>>> > Fred
>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> >>>>> wrote: >>>>> >> Fred,
>>>>> >> Hi. Thanks for your interest in my problem.
>>>>> >> I'm working with the development version of Theano. The specific >>>>> git commit >>>>> >> id is:
>>>>> >> % git log --oneline | more >>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm >>>>> working >>>>> >> against (from a working directory of Theano/theano/sandbox/cuda): >>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>> >> Let me know if I can provide anything else.
>>>>> >> Best, >>>>> >> Mark
>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>>>>> >>> witch verison of theano do you use? Also, can you join your >>>>> version of >>>>> >>> cuda_ndarray.cu file? That way, I can know what the line number >>>>> mean.
>>>>> >>> This line you give: >>>>> >>> > argument types are: (CudaNdarray *, int, >>>>> <error-type>)
>>>>> >>> the last parameter don't seam good. But this is working on linux. >>>>> So >>>>> >>> it is probably something that is different on linux and windows.
>>>>> >>> thanks for the report.
>>>>> >>> Fred
>>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> >>>>> wrote: >>>>> >>> > Hi folks,
>>>>> >>> > I'm attempting to isolate some problems with a >>>>> Theano/Windows/GPU setup >>>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano >>>>> latest >>>>> >>> > git) . >>>>> >>> > I isolated the theano nvcc call and separated that out. >>>>> Standalone, >>>>> >>> > from a >>>>> >>> > VS2010 command prompt, the nvcc command gives the following >>>>> output:
>>>>> >>> > which produces the following error: >>>>> >>> > ./cuda_ndarray.cu(480): warning: conversion from pointer to >>>>> smaller >>>>> >>> > integer
>>>>> >>> > ./cuda_ndarray.cu(769): warning: statement is unreachable
>>>>> >>> > ./cuda_ndarray.cu(850): error: expression must have a constant >>>>> value
>>>>> >>> > ./cuda_ndarray.cu(865): error: no instance of function template >>>>> >>> > "CudaNdarray_alloc_contiguous" matches the argument list >>>>> >>> > argument types are: (CudaNdarray *, int, >>>>> <error-type>)
>>>>> >>> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to >>>>> smaller >>>>> >>> > integer
>>>>> >>> > 2 errors detected in the compilation of >>>>> >>> > "C:/Users/mfenner/AppData/**Local/Temp/tmp >>>>> >>> > xft_0000060c_00000000-6_cuda_**ndarray.cpp1.ii".
Ok, so, here's the latest. I can't figure out how to pass the "--machine 32" parameter through .theanorc to the internal nvcc command line. I've tried several permutations, but the parameter isn't being sent to the command in a way that makes the command happy. Here's my latest attempt:
from .theanorc:
[nvcc]
compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin
flags=--machine 32
I've also tried:
flags="--machine 32" and flags=--"machine 32" and some others. How is the right-hand side of the assignment interpreted and how is that passed along to (I'm assuming) -- eventually -- a subprocess.Popen?
*********************************
As far as versions go, here's what I found (and the evidence as to why I think it):
Python (from mingw32/msys): $ which python
/c/python27/python.exe
$ python
>>> import platform; platform.architecture()
('32bit', 'WindowsPE')
CUDA:
NVIDIA 64-bit driver/toolkit/sdk
PyCUDA (working):
amd64
VS2010:
the compilations I've done are with the Visual Studio Command Prompt (2010) [non-x64 Win64]
On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
> Thanks for the info. Please let us know if adding "--machine 32" is enough > to solve your problem.
> It would also be interesting to know which part of your toolchain is 32 > bit:
> - Python?
> - Cuda?
> - Visual Studio?
> -=- Olivier
> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
> Olivier,
> Thanks for that hint. I wouldn't have tried that otherwise: however, it > didn't help.
> Notice the important addition of "--machine 32" at the tail end. This > resolved a large number (10s? 100s?) of LNK2019, unresolved external > symbol errors that look like this:
> tmpxft_000005a0_00000000-15_cuda_ndarray.obj : error LNK2019: unresolved > external symbol __imp_PyErr_Format referenced in function "void * __cdecl > device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
> I'm personally a little confused as to what "bit-ness" my toolchain is -- > I initially thought I was aiming for an "all 64-bit" toolchain (from python > to python libs to nvidia components to compiled/linked nvcc code). > However, it appears I was mistaken and/or I decided/realized I needed to > move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how > the internal theano/nvcc compilation goes.
> Also: I saw a comment that talked about unrecognized "<" and the need to > register ".cu" files (I think) in Visual Studio. It's the last comment > (currently) on this SO thread. Incidentally, that thread deals with some > of the issues in using CUDA 4 with VS2010.
> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>> Most likely won't help, but just in case, run "python theano-cache clear" >> (theano-cache can be found in the bin subfolder). Sometimes outdated >> compiled code can lead to weird linking errors.
>>> The patch seems to have fixed the nvcc compilation error. Thanks again!
>>> Now, I'm getting a large number of link errors. I will try to debug and >>> isolate what's going on there.
>>> Best,
>>> Mark
>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>> Fred,
>>>> Thank you very much for working on this. I will update my repository >>>> and try it again sometime today.
>>>> Best,
>>>> Mark
>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>> My first merge fix introduced a bug. Now it is fixed. So you should >>>>> reupdate.
>>>>> Fred
>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >>>>> wrote: >>>>> > I found the reason,
>>>>> > This microsoft compiler don't support variable len array in there >>>>> c++ >>>>> > compilier. So this line is not accepted:
>>>>> > I made a new PR and David just reviewed it. So if you update your >>>>> > version of Theano, it should work.
>>>>> > thanks for the report. If there is other problem(i hope not), don't >>>>> > hesitate to tell us.
>>>>> > Fred
>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> >>>>> wrote: >>>>> >> Fred,
>>>>> >> Hi. Thanks for your interest in my problem.
>>>>> >> I'm working with the development version of Theano. The specific >>>>> git commit >>>>> >> id is:
>>>>> >> % git log --oneline | more >>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm >>>>> working >>>>> >> against (from a working directory of Theano/theano/sandbox/cuda): >>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>> >> Let me know if I can provide anything else.
>>>>> >> Best, >>>>> >> Mark
>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>>>>> >>> witch verison of theano do you use? Also, can you join your >>>>> version of >>>>> >>> cuda_ndarray.cu file? That way, I can know what the line number >>>>> mean.
>>>>> >>> This line you give: >>>>> >>> > argument types are: (CudaNdarray *, int, >>>>> <error-type>)
>>>>> >>> the last parameter don't seam good. But this is working on linux. >>>>> So >>>>> >>> it is probably something that is different on linux and windows.
>>>>> >>> thanks for the report.
>>>>> >>> Fred
>>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> >>>>> wrote: >>>>> >>> > Hi folks,
>>>>> >>> > I'm attempting to isolate some problems with a >>>>> Theano/Windows/GPU setup >>>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano >>>>> latest >>>>> >>> > git) . >>>>> >>> > I isolated the theano nvcc call and separated that out. >>>>> Standalone, >>>>> >>> > from a >>>>> >>> > VS2010 command prompt, the nvcc command gives the following >>>>> output:
>>>>> >>> > which produces the following error: >>>>> >>> > ./cuda_ndarray.cu(480): warning: conversion from pointer to >>>>> smaller >>>>> >>> > integer
>>>>> >>> > ./cuda_ndarray.cu(769): warning: statement is unreachable
>>>>> >>> > ./cuda_ndarray.cu(850): error: expression must have a constant >>>>> value
>>>>> >>> > ./cuda_ndarray.cu(865): error: no instance of function template >>>>> >>> > "CudaNdarray_alloc_contiguous" matches the argument list >>>>> >>> > argument types are: (CudaNdarray *, int, >>>>> <error-type>)
>>>>> >>> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to >>>>> smaller >>>>> >>> > integer
>>>>> >>> > 2 errors detected in the compilation of >>>>> >>> > "C:/Users/mfenner/AppData/**Local/Temp/tmp >>>>> >>> > xft_0000060c_00000000-6_cuda_**ndarray.cpp1.ii".
I've had success with command line nvcc from VS2010's non-x64 command prompt (I just posted some other details of my environment).
I'm curious, how do you get around the missing g++ problem when you are using a VS prompt? I end up using mingw/msys as my command prompt so I can access g++.
On Wednesday, July 25, 2012 10:03:29 AM UTC-4, Gabe Schwartz wrote:
> This might be too obvious and you may be already doing it, but were you > using the x64/Win64 command prompt?
> I remember having a number of issues compiling other software because I > was using the "Visual Studio Command Prompt (2010)" instead of the "Visual > Studio x64 Win64 Command Prompt (2010)". If you don't use the latter then > all sorts of wrong libraries will be used.
> On Tuesday, July 24, 2012 10:53:07 AM UTC-4, Mark wrote:
>> Olivier,
>> Thanks for that hint. I wouldn't have tried that otherwise: however, it >> didn't help.
>> Notice the important addition of "--machine 32" at the tail end. This >> resolved a large number (10s? 100s?) of LNK2019, unresolved external >> symbol errors that look like this:
>> tmpxft_000005a0_00000000-15_cuda_ndarray.obj : error LNK2019: unresolved >> external symbol __imp_PyErr_Format referenced in function "void * __cdecl >> device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>> I'm personally a little confused as to what "bit-ness" my toolchain is -- >> I initially thought I was aiming for an "all 64-bit" toolchain (from python >> to python libs to nvidia components to compiled/linked nvcc code). >> However, it appears I was mistaken and/or I decided/realized I needed to >> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how >> the internal theano/nvcc compilation goes.
>> Also: I saw a comment that talked about unrecognized "<" and the need to >> register ".cu" files (I think) in Visual Studio. It's the last comment >> (currently) on this SO thread. Incidentally, that thread deals with some >> of the issues in using CUDA 4 with VS2010.
>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>> Most likely won't help, but just in case, run "python theano-cache >>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated >>> compiled code can lead to weird linking errors.
>>>> The patch seems to have fixed the nvcc compilation error. Thanks >>>> again!
>>>> Now, I'm getting a large number of link errors. I will try to debug >>>> and isolate what's going on there.
>>>> Best,
>>>> Mark
>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>> Fred,
>>>>> Thank you very much for working on this. I will update my repository >>>>> and try it again sometime today.
>>>>> Best,
>>>>> Mark
>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should >>>>>> reupdate.
>>>>>> Fred
>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >>>>>> wrote: >>>>>> > I found the reason,
>>>>>> > This microsoft compiler don't support variable len array in there >>>>>> c++ >>>>>> > compilier. So this line is not accepted:
>>>>>> > I made a new PR and David just reviewed it. So if you update your >>>>>> > version of Theano, it should work.
>>>>>> > thanks for the report. If there is other problem(i hope not), don't >>>>>> > hesitate to tell us.
>>>>>> > Fred
>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> >>>>>> wrote: >>>>>> >> Fred,
>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>> >> I'm working with the development version of Theano. The specific >>>>>> git commit >>>>>> >> id is:
>>>>>> >> % git log --oneline | more >>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm >>>>>> working >>>>>> >> against (from a working directory of Theano/theano/sandbox/cuda): >>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>> >> Let me know if I can provide anything else.
>>>>>> >> Best, >>>>>> >> Mark
>>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>>>>>> >>> witch verison of theano do you use? Also, can you join your >>>>>> version of >>>>>> >>> cuda_ndarray.cu file? That way, I can know what the line number >>>>>> mean.
>>>>>> >>> This line you give: >>>>>> >>> > argument types are: (CudaNdarray *, int, >>>>>> <error-type>)
>>>>>> >>> the last parameter don't seam good. But this is working on linux. >>>>>> So >>>>>> >>> it is probably something that is different on linux and windows.
>>>>>> >>> thanks for the report.
>>>>>> >>> Fred
>>>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> >>>>>> wrote: >>>>>> >>> > Hi folks,
>>>>>> >>> > I'm attempting to isolate some problems with a >>>>>> Theano/Windows/GPU setup >>>>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano >>>>>> latest >>>>>> >>> > git) . >>>>>> >>> > I isolated the theano nvcc call and separated that out. >>>>>> Standalone, >>>>>> >>> > from a >>>>>> >>> > VS2010 command prompt, the nvcc command gives the following >>>>>> output:
>>>>>> >>> > which produces the following error: >>>>>> >>> > ./cuda_ndarray.cu(480): warning: conversion from pointer to >>>>>> smaller >>>>>> >>> > integer
>>>>>> >>> > ./cuda_ndarray.cu(769): warning: statement is unreachable
>>>>>> >>> > ./cuda_ndarray.cu(850): error: expression must have a constant >>>>>> value
>>>>>> >>> > ./cuda_ndarray.cu(865): error: no instance of function >>>>>> template >>>>>> >>> > "CudaNdarray_alloc_contiguous" matches the argument list >>>>>> >>> > argument types are: (CudaNdarray *, int, >>>>>> <error-type>)
>>>>>> >>> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to >>>>>> smaller >>>>>> >>> > integer
>>>>>> >>> > 2 errors detected in the compilation of >>>>>> >>> > "C:/Users/mfenner/AppData/**Local/Temp/tmp >>>>>> >>> > xft_0000060c_00000000-6_cuda_**ndarray.cpp1.ii".
>>>>>> >>> > Any thoughts?
>>>>>> >>> > Best, >>>>>> >>> > Mark
On Wednesday, July 25, 2012 10:03:29 AM UTC-4, Gabe Schwartz wrote:
> This might be too obvious and you may be already doing it, but were you > using the x64/Win64 command prompt?
> I remember having a number of issues compiling other software because I > was using the "Visual Studio Command Prompt (2010)" instead of the "Visual > Studio x64 Win64 Command Prompt (2010)". If you don't use the latter then > all sorts of wrong libraries will be used.
> On Tuesday, July 24, 2012 10:53:07 AM UTC-4, Mark wrote:
>> Olivier,
>> Thanks for that hint. I wouldn't have tried that otherwise: however, it >> didn't help.
>> Notice the important addition of "--machine 32" at the tail end. This >> resolved a large number (10s? 100s?) of LNK2019, unresolved external >> symbol errors that look like this:
>> tmpxft_000005a0_00000000-15_cuda_ndarray.obj : error LNK2019: unresolved >> external symbol __imp_PyErr_Format referenced in function "void * __cdecl >> device_malloc (unsigned __int64)"
Looks like you found a bug in the parsing of nvcc flags ;)
Use instead:
flags=-m32
This should work for now (I made an issue for this bug:
https://github.com/Theano/Theano/issues/785)
I'm not sure using 64 bit Cuda with 32 bit Python works, but you can give
it a shot...
> Ok, so, here's the latest. I can't figure out how to pass the "--machine
> 32" parameter through .theanorc to the internal nvcc command line. I've
> tried several permutations, but the parameter isn't being sent to the
> command in a way that makes the command happy. Here's my latest attempt:
> from .theanorc:
> [nvcc]
> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin
> flags=--machine 32
> I've also tried:
> flags="--machine 32" and flags=--"machine 32" and some others. How is the
> right-hand side of the assignment interpreted and how is that passed along
> to (I'm assuming) -- eventually -- a subprocess.Popen?
> *********************************
> As far as versions go, here's what I found (and the evidence as to why I
> think it):
> VS2010:
> the compilations I've done are with the Visual Studio Command Prompt
> (2010) [non-x64 Win64]
> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>> Thanks for the info. Please let us know if adding "--machine 32" is
>> enough to solve your problem.
>> It would also be interesting to know which part of your toolchain is 32
>> bit:
>> - Python?
>> - Cuda?
>> - Visual Studio?
>> -=- Olivier
>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>> Olivier,
>> Thanks for that hint. I wouldn't have tried that otherwise: however, it
>> didn't help.
>> Notice the important addition of "--machine 32" at the tail end. This
>> resolved a large number (10s? 100s?) of LNK2019, unresolved external
>> symbol errors that look like this:
>> tmpxft_000005a0_00000000-15_**cuda_ndarray.obj : error LNK2019:
>> unresolved external symbol __imp_PyErr_Format referenced in function "void
>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>> I'm personally a little confused as to what "bit-ness" my toolchain is --
>> I initially thought I was aiming for an "all 64-bit" toolchain (from python
>> to python libs to nvidia components to compiled/linked nvcc code).
>> However, it appears I was mistaken and/or I decided/realized I needed to
>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how
>> the internal theano/nvcc compilation goes.
>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>> Most likely won't help, but just in case, run "python theano-cache
>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated
>>> compiled code can lead to weird linking errors.
>>>> The patch seems to have fixed the nvcc compilation error. Thanks
>>>> again!
>>>> Now, I'm getting a large number of link errors. I will try to debug
>>>> and isolate what's going on there.
>>>> Best,
>>>> Mark
>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>> Fred,
>>>>> Thank you very much for working on this. I will update my repository
>>>>> and try it again sometime today.
>>>>> Best,
>>>>> Mark
>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should
>>>>>> reupdate.
>>>>>> Fred
>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org>
>>>>>> wrote:
>>>>>> > I found the reason,
>>>>>> > This microsoft compiler don't support variable len array in there
>>>>>> c++
>>>>>> > compilier. So this line is not accepted:
>>>>>> > I made a new PR and David just reviewed it. So if you update your
>>>>>> > version of Theano, it should work.
>>>>>> > thanks for the report. If there is other problem(i hope not), don't
>>>>>> > hesitate to tell us.
>>>>>> > Fred
>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com>
>>>>>> wrote:
>>>>>> >> Fred,
>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>> >> I'm working with the development version of Theano. The specific
>>>>>> git commit
>>>>>> >> id is:
>>>>>> >> % git log --oneline | more
>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm
>>>>>> working
>>>>>> >> against (from a working directory of Theano/theano/sandbox/cuda):
>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>> >> Let me know if I can provide anything else.
>>>>>> >> Best,
>>>>>> >> Mark
>>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien wrote:
>>>>>> >>> witch verison of theano do you use? Also, can you join your
>>>>>> version of
>>>>>> >>> cuda_ndarray.cu file? That way, I can know what the line number
>>>>>> mean.
>>>>>> >>> This line you give:
>>>>>> >>> > argument types are: (CudaNdarray *, int,
>>>>>> <error-type>)
>>>>>> >>> the last parameter don't seam good. But this is working on linux.
>>>>>> So
>>>>>> >>> it is probably something that is different on linux and windows.
>>>>>> >>> thanks for the report.
>>>>>> >>> Fred
>>>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com>
>>>>>> wrote:
>>>>>> >>> > Hi folks,
>>>>>> >>> > I'm attempting to isolate some problems with a
>>>>>> Theano/Windows/GPU setup
>>>>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano
>>>>>> latest
>>>>>> >>> > git) .
>>>>>> >>> > I isolated the theano nvcc call and separated that out.
>>>>>> Standalone,
>>>>>> >>> > from a
>>>>>> >>> > VS2010 command prompt, the nvcc command gives the following
>>>>>> output:
>>>>>> >>> > which produces the following error:
>>>>>> >>> > ./cuda_ndarray.cu(480): warning: conversion from pointer to
>>>>>> smaller
>>>>>> >>> > integer
>>>>>> >>> > ./cuda_ndarray.cu(769): warning: statement is unreachable
>>>>>> >>> > ./cuda_ndarray.cu(850): error: expression must have a constant
>>>>>> value
>>>>>> >>> > ./cuda_ndarray.cu(865): error: no instance of function
>>>>>> template
>>>>>> >>> > "CudaNdarray_alloc_contiguous" matches the argument list
>>>>>> >>> > argument types are: (CudaNdarray *, int,
>>>>>> <error-type>)
>>>>>> >>> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to
>>>>>> smaller
>>>>>> >>> > integer
>>>>>> >>> > 2 errors detected in the compilation of
>>>>>> >>> > "C:/Users/mfenner/AppData/**Loca**l/Temp/tmp
>>>>>> >>> > xft_0000060c_00000000-6_cuda_**n**darray.cpp1.ii".
> I've had success with command line nvcc from VS2010's non-x64 command
> prompt (I just posted some other details of my environment).
> I'm curious, how do you get around the missing g++ problem when you are
> using a VS prompt? I end up using mingw/msys as my command prompt so I can
> access g++.
> Thanks,
> Mark
> On Wednesday, July 25, 2012 10:03:29 AM UTC-4, Gabe Schwartz wrote:
>> This might be too obvious and you may be already doing it, but were you
>> using the x64/Win64 command prompt?
>> I remember having a number of issues compiling other software because I
>> was using the "Visual Studio Command Prompt (2010)" instead of the "Visual
>> Studio x64 Win64 Command Prompt (2010)". If you don't use the latter then
>> all sorts of wrong libraries will be used.
>> On Tuesday, July 24, 2012 10:53:07 AM UTC-4, Mark wrote:
>>> Olivier,
>>> Thanks for that hint. I wouldn't have tried that otherwise: however,
>>> it didn't help.
>>> Notice the important addition of "--machine 32" at the tail end. This
>>> resolved a large number (10s? 100s?) of LNK2019, unresolved external
>>> symbol errors that look like this:
>>> tmpxft_000005a0_00000000-15_**cuda_ndarray.obj : error LNK2019:
>>> unresolved external symbol __imp_PyErr_Format referenced in function "void
>>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>>> I'm personally a little confused as to what "bit-ness" my toolchain is
>>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from
>>> python to python libs to nvidia components to compiled/linked nvcc code).
>>> However, it appears I was mistaken and/or I decided/realized I needed to
>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how
>>> the internal theano/nvcc compilation goes.
>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>> Most likely won't help, but just in case, run "python theano-cache
>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated
>>>> compiled code can lead to weird linking errors.
>>>>> The patch seems to have fixed the nvcc compilation error. Thanks
>>>>> again!
>>>>> Now, I'm getting a large number of link errors. I will try to debug
>>>>> and isolate what's going on there.
>>>>> Best,
>>>>> Mark
>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>>> Fred,
>>>>>> Thank you very much for working on this. I will update my repository
>>>>>> and try it again sometime today.
>>>>>> Best,
>>>>>> Mark
>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should
>>>>>>> reupdate.
>>>>>>> Fred
>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org>
>>>>>>> wrote:
>>>>>>> > I found the reason,
>>>>>>> > This microsoft compiler don't support variable len array in there
>>>>>>> c++
>>>>>>> > compilier. So this line is not accepted:
>>>>>>> > I made a new PR and David just reviewed it. So if you update your
>>>>>>> > version of Theano, it should work.
>>>>>>> > thanks for the report. If there is other problem(i hope not),
>>>>>>> don't
>>>>>>> > hesitate to tell us.
>>>>>>> > Fred
>>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com>
>>>>>>> wrote:
>>>>>>> >> Fred,
>>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>>> >> I'm working with the development version of Theano. The specific
>>>>>>> git commit
>>>>>>> >> id is:
>>>>>>> >> % git log --oneline | more
>>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm
>>>>>>> working
>>>>>>> >> against (from a working directory of Theano/theano/sandbox/cuda):
>>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>>> >> Let me know if I can provide anything else.
>>>>>>> >> Best,
>>>>>>> >> Mark
>>>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien
>>>>>>> wrote:
>>>>>>> >>> witch verison of theano do you use? Also, can you join your
>>>>>>> version of
>>>>>>> >>> cuda_ndarray.cu file? That way, I can know what the line number
>>>>>>> mean.
>>>>>>> >>> This line you give:
>>>>>>> >>> > argument types are: (CudaNdarray *, int,
>>>>>>> <error-type>)
>>>>>>> >>> the last parameter don't seam good. But this is working on
>>>>>>> linux. So
>>>>>>> >>> it is probably something that is different on linux and windows.
>>>>>>> >>> thanks for the report.
>>>>>>> >>> Fred
>>>>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com>
>>>>>>> wrote:
>>>>>>> >>> > Hi folks,
>>>>>>> >>> > I'm attempting to isolate some problems with a
>>>>>>> Theano/Windows/GPU setup
>>>>>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano
>>>>>>> latest
>>>>>>> >>> > git) .
>>>>>>> >>> > I isolated the theano nvcc call and separated that out.
>>>>>>> Standalone,
>>>>>>> >>> > from a
>>>>>>> >>> > VS2010 command prompt, the nvcc command gives the following
>>>>>>> output:
>>>>>>> >>> > which produces the following error:
>>>>>>> >>> > ./cuda_ndarray.cu(480): warning: conversion from pointer to
>>>>>>> smaller
>>>>>>> >>> > integer
>>>>>>> >>> > ./cuda_ndarray.cu(769): warning: statement is unreachable
>>>>>>> >>> > ./cuda_ndarray.cu(850): error: expression must have a
>>>>>>> constant value
>>>>>>> >>> > ./cuda_ndarray.cu(865): error: no instance of function
>>>>>>> template
>>>>>>> >>> > "CudaNdarray_alloc_contiguous" matches the argument list
>>>>>>> >>> > argument types are: (CudaNdarray *, int,
>>>>>>> <error-type>)
>>>>>>> >>> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to
>>>>>>> smaller
>>>>>>> >>> > integer
>>>>>>> >>> > 2 errors detected in the compilation of
>>>>>>> >>> > "C:/Users/mfenner/AppData/**Loca**l/Temp/tmp
>>>>>>> >>> > xft_0000060c_00000000-6_cuda_**n**darray.cpp1.ii".
>>>>>>> >>> > Any thoughts?
>>>>>>> >>> > Best,
>>>>>>> >>> > Mark
> On Wednesday, July 25, 2012 10:03:29 AM UTC-4, Gabe Schwartz wrote:
>> This might be too obvious and you may be already doing it, but were you
>> using the x64/Win64 command prompt?
>> I remember having a number of issues compiling other software because I
>> was using the "Visual Studio Command Prompt (2010)" instead of the "Visual
>> Studio x64 Win64 Command Prompt (2010)". If you don't use the latter then
>> all sorts of wrong libraries will be used.
>> On Tuesday, July 24, 2012 10:53:07 AM UTC-4, Mark wrote:
>>> Olivier,
>>> Thanks for that hint. I wouldn't have tried that otherwise: however,
>>> it didn't help.
Regarding 64-bit CUDA + 32-bit python ... I'm on my linux workstation, but I -think- (please double check if anything important depends on this) that the 64-bit CUDA libs come with BOTH 32 and 64 bit headers and libs. Thus, you can make 32-bit python happy by pointing the build scripts/configurations at the correct directory, gets you correct behavior. Again, that's from sketchy memory.
Alright, so, I reviewed a few notes and part of my preceeding comments apply directly to installing and testing PyCuda (not theono, directly). However, the following seems relevent:
(1) the python-amd64 that I downloaded and installed actually reports the platform information that I mentioned earlier (indicating 32-bit). I don't understand that and I may have made an error in my installation notes (however, my download directory only has the python-amd64 installer). Perhaps it is an architecture optimized build, but not a 64-bit build. I could definitely be wrong; just a guess.
(2) to make PyCuda happy, I placed these lines in my PYCUDA_SOURCE/siteconf.py (pycuda's configuration) [the $CUDA_ROOT/lib/Win32 could have been $CUDA_ROOT/lib/x64 to select 64-bit libs instead]:
BOOST_INC_DIR = []
BOOST_LIB_DIR = []
BOOST_COMPILER = 'gcc43'
USE_SHIPPED_BOOST = True
BOOST_PYTHON_LIBNAME = ['boost_python']
BOOST_THREAD_LIBNAME = ['boost_thread']
CUDA_TRACE = False
CUDA_ROOT = 'C:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v4.2'
CUDA_ENABLE_GL = False
CUDA_ENABLE_CURAND = True
CUDADRV_LIB_DIR = ['${CUDA_ROOT}/lib/Win32']
CUDADRV_LIBNAME = ['cuda']
CUDART_LIB_DIR = ['${CUDA_ROOT}/lib/Win32']
CUDART_LIBNAME = ['cudart']
CURAND_LIB_DIR = ['${CUDA_ROOT}/lib/Win32']
CURAND_LIBNAME = ['curand']
CXXFLAGS = ['/EHsc']
LDFLAGS = ['/FORCE']
On Wednesday, July 25, 2012 1:23:58 PM UTC-4, Olivier Delalleau wrote:
> Looks like you found a bug in the parsing of nvcc flags ;)
> Use instead:
> flags=-m32
> This should work for now (I made an issue for this bug: > https://github.com/Theano/Theano/issues/785)
> I'm not sure using 64 bit Cuda with 32 bit Python works, but you can give > it a shot...
>> Ok, so, here's the latest. I can't figure out how to pass the "--machine >> 32" parameter through .theanorc to the internal nvcc command line. I've >> tried several permutations, but the parameter isn't being sent to the >> command in a way that makes the command happy. Here's my latest attempt:
>> from .theanorc:
>> [nvcc]
>> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin
>> flags=--machine 32
>> I've also tried:
>> flags="--machine 32" and flags=--"machine 32" and some others. How is >> the right-hand side of the assignment interpreted and how is that passed >> along to (I'm assuming) -- eventually -- a subprocess.Popen?
>> *********************************
>> As far as versions go, here's what I found (and the evidence as to why I >> think it):
>> VS2010:
>> the compilations I've done are with the Visual Studio Command Prompt >> (2010) [non-x64 Win64]
>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>>> Thanks for the info. Please let us know if adding "--machine 32" is >>> enough to solve your problem.
>>> It would also be interesting to know which part of your toolchain is 32 >>> bit:
>>> - Python?
>>> - Cuda?
>>> - Visual Studio?
>>> -=- Olivier
>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>>> Olivier,
>>> Thanks for that hint. I wouldn't have tried that otherwise: however, >>> it didn't help.
>>> Notice the important addition of "--machine 32" at the tail end. This >>> resolved a large number (10s? 100s?) of LNK2019, unresolved external >>> symbol errors that look like this:
>>> tmpxft_000005a0_00000000-15_**cuda_ndarray.obj : error LNK2019: >>> unresolved external symbol __imp_PyErr_Format referenced in function "void >>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>>> I'm personally a little confused as to what "bit-ness" my toolchain is >>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from >>> python to python libs to nvidia components to compiled/linked nvcc code). >>> However, it appears I was mistaken and/or I decided/realized I needed to >>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how >>> the internal theano/nvcc compilation goes.
>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>> Most likely won't help, but just in case, run "python theano-cache >>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated >>>> compiled code can lead to weird linking errors.
>>>>> The patch seems to have fixed the nvcc compilation error. Thanks >>>>> again!
>>>>> Now, I'm getting a large number of link errors. I will try to debug >>>>> and isolate what's going on there.
>>>>> Best,
>>>>> Mark
>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>>> Fred,
>>>>>> Thank you very much for working on this. I will update my repository >>>>>> and try it again sometime today.
>>>>>> Best,
>>>>>> Mark
>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should >>>>>>> reupdate.
>>>>>>> Fred
>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >>>>>>> wrote: >>>>>>> > I found the reason,
>>>>>>> > This microsoft compiler don't support variable len array in there >>>>>>> c++ >>>>>>> > compilier. So this line is not accepted:
>>>>>>> > I made a new PR and David just reviewed it. So if you update your >>>>>>> > version of Theano, it should work.
>>>>>>> > thanks for the report. If there is other problem(i hope not), >>>>>>> don't >>>>>>> > hesitate to tell us.
>>>>>>> > Fred
>>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> >>>>>>> wrote: >>>>>>> >> Fred,
>>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>>> >> I'm working with the development version of Theano. The specific >>>>>>> git commit >>>>>>> >> id is:
>>>>>>> >> % git log --oneline | more >>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm >>>>>>> working >>>>>>> >> against (from a working directory of Theano/theano/sandbox/cuda): >>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>>> >> Let me know if I can provide anything else.
>>>>>>> >> Best, >>>>>>> >> Mark
>>>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien >>>>>>> wrote:
>>>>>>> >>> witch verison of theano do you use? Also, can you join your >>>>>>> version of >>>>>>> >>> cuda_ndarray.cu file? That way, I can know what the line number >>>>>>> mean.
>>>>>>> >>> This line you give: >>>>>>> >>> > argument types are: (CudaNdarray *, int, >>>>>>> <error-type>)
>>>>>>> >>> the last parameter don't seam good. But this is working on >>>>>>> linux. So >>>>>>> >>> it is probably something that is different on linux and windows.
>>>>>>> >>> thanks for the report.
>>>>>>> >>> Fred
>>>>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> >>>>>>> wrote: >>>>>>> >>> > Hi folks,
>>>>>>> >>> > I'm attempting to isolate some problems with a >>>>>>> Theano/Windows/GPU setup >>>>>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano >>>>>>> latest >>>>>>> >>> > git) . >>>>>>> >>> > I isolated the theano nvcc call and separated that out. >>>>>>> Standalone, >>>>>>> >>> > from a >>>>>>> >>> > VS2010 command
Thanks. I was hesitant to try with PATH at the VS2010 prompt b/c I figured everything else (e.g., the toolchain and linking environments) would fail miserably. I'll give that a try also.
>> I've had success with command line nvcc from VS2010's non-x64 command >> prompt (I just posted some other details of my environment).
>> I'm curious, how do you get around the missing g++ problem when you are >> using a VS prompt? I end up using mingw/msys as my command prompt so I can >> access g++.
>> Thanks,
>> Mark
>> On Wednesday, July 25, 2012 10:03:29 AM UTC-4, Gabe Schwartz wrote:
>>> This might be too obvious and you may be already doing it, but were you >>> using the x64/Win64 command prompt?
>>> I remember having a number of issues compiling other software because I >>> was using the "Visual Studio Command Prompt (2010)" instead of the "Visual >>> Studio x64 Win64 Command Prompt (2010)". If you don't use the latter then >>> all sorts of wrong libraries will be used.
>>> On Tuesday, July 24, 2012 10:53:07 AM UTC-4, Mark wrote:
>>>> Olivier,
>>>> Thanks for that hint. I wouldn't have tried that otherwise: however, >>>> it didn't help.
>>>> Notice the important addition of "--machine 32" at the tail end. This >>>> resolved a large number (10s? 100s?) of LNK2019, unresolved external >>>> symbol errors that look like this:
>>>> tmpxft_000005a0_00000000-15_**cuda_ndarray.obj : error LNK2019: >>>> unresolved external symbol __imp_PyErr_Format referenced in function "void >>>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>>>> I'm personally a little confused as to what "bit-ness" my toolchain is >>>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from >>>> python to python libs to nvidia components to compiled/linked nvcc code). >>>> However, it appears I was mistaken and/or I decided/realized I needed to >>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how >>>> the internal theano/nvcc compilation goes.
>>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>>> Most likely won't help, but just in case, run "python theano-cache >>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated >>>>> compiled code can lead to weird linking errors.
>>>>>> The patch seems to have fixed the nvcc compilation error. Thanks >>>>>> again!
>>>>>> Now, I'm getting a large number of link errors. I will try to debug >>>>>> and isolate what's going on there.
>>>>>> Best,
>>>>>> Mark
>>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>>>> Fred,
>>>>>>> Thank you very much for working on this. I will update my >>>>>>> repository and try it again sometime today.
>>>>>>> Best,
>>>>>>> Mark
>>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should >>>>>>>> reupdate.
>>>>>>>> Fred
>>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >>>>>>>> wrote: >>>>>>>> > I found the reason,
>>>>>>>> > This microsoft compiler don't support variable len array in there >>>>>>>> c++ >>>>>>>> > compilier. So this line is not accepted:
>>>>>>>> > I made a new PR and David just reviewed it. So if you update your >>>>>>>> > version of Theano, it should work.
>>>>>>>> > thanks for the report. If there is other problem(i hope not), >>>>>>>> don't >>>>>>>> > hesitate to tell us.
>>>>>>>> > Fred
>>>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> >>>>>>>> wrote: >>>>>>>> >> Fred,
>>>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>>>> >> I'm working with the development version of Theano. The >>>>>>>> specific git commit >>>>>>>> >> id is:
>>>>>>>> >> % git log --oneline | more >>>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm >>>>>>>> working >>>>>>>> >> against (from a working directory of >>>>>>>> Theano/theano/sandbox/cuda): >>>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>>>> >> Let me know if I can provide anything else.
>>>>>>>> >> Best, >>>>>>>> >> Mark
>>>>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien >>>>>>>> wrote:
>>>>>>>> >>> witch verison of theano do you use? Also, can you join your >>>>>>>> version of >>>>>>>> >>> cuda_ndarray.cu file? That way, I can know what the line >>>>>>>> number mean.
>>>>>>>> >>> This line you give: >>>>>>>> >>> > argument types are: (CudaNdarray *, int, >>>>>>>> <error-type>)
>>>>>>>> >>> the last parameter don't seam good. But this is working on >>>>>>>> linux. So >>>>>>>> >>> it is probably something that is different on linux and >>>>>>>> windows.
>>>>>>>> >>> thanks for the report.
>>>>>>>> >>> Fred
>>>>>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> >>>>>>>> wrote: >>>>>>>> >>> > Hi folks,
>>>>>>>> >>> > I'm attempting to isolate some problems with a >>>>>>>> Theano/Windows/GPU setup >>>>>>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano >>>>>>>> latest >>>>>>>> >>> > git) . >>>>>>>> >>> > I isolated the theano nvcc call and separated that out. >>>>>>>> Standalone, >>>>>>>> >>> > from a >>>>>>>> >>> > VS2010 command prompt, the nvcc command gives the following >>>>>>>> output:
>>>>>>>> >>> > which produces the following error: >>>>>>>> >>> > ./cuda_ndarray.cu(480): warning: conversion from pointer to >>>>>>>> smaller >>>>>>>> >>> > integer
>>>>>>>> >>> > ./cuda_ndarray.cu(769): warning: statement is unreachable
>>>>>>>> >>> > ./cuda_ndarray.cu(850): error: expression must have a >>>>>>>> constant value
>>>>>>>> >>> > ./cuda_ndarray.cu(865): error: no instance of function >>>>>>>> template >>>>>>>> >>> > "CudaNdarray_alloc_contiguous" matches the argument list >>>>>>>> >>> > argument types are: (CudaNdarray *, int, >>>>>>>> <error-type>)
>>>>>>>> >>> > ./cuda_ndarray.cu(2258): warning: conversion from pointer to >>>>>>>> smaller >>>>>>>> >>> > integer
>>>>>>>> >>> > 2 errors detected in the compilation of >>>>>>>> >>> > "C:/Users/mfenner/AppData/**Loca**l/Temp/tmp >>>>>>>> >>> > xft_0000060c_00000000-6_cuda_**n**darray.cpp1.ii".
>>>>>>>> >>> > Any thoughts?
>>>>>>>> >>> > Best, >>>>>>>> >>> > Mark
>> On Wednesday, July 25, 2012 10:03:29 AM UTC-4, Gabe Schwartz wrote:
>>> This might be too obvious and you may be already doing it, but were you >>> using the x64/Win64 command prompt?
>>> I remember having a number of issues compiling other software because I >>> was using the "Visual Studio Command Prompt (2010)" instead of the "Visual >>> Studio x64 Win64
Now that's VERY interesting. I didn't notice this before: the -L arg is for CUDA/4.2/lib/x64 and the -m32 seem incompatible. Yet this compiles cleanly (two warnings about unreachable code). Perhaps it would fail at run time.
On Wednesday, July 25, 2012 1:23:58 PM UTC-4, Olivier Delalleau wrote:
> Looks like you found a bug in the parsing of nvcc flags ;)
> Use instead:
> flags=-m32
> This should work for now (I made an issue for this bug: > https://github.com/Theano/Theano/issues/785)
> I'm not sure using 64 bit Cuda with 32 bit Python works, but you can give > it a shot...
>> Ok, so, here's the latest. I can't figure out how to pass the "--machine >> 32" parameter through .theanorc to the internal nvcc command line. I've >> tried several permutations, but the parameter isn't being sent to the >> command in a way that makes the command happy. Here's my latest attempt:
>> from .theanorc:
>> [nvcc]
>> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin
>> flags=--machine 32
>> I've also tried:
>> flags="--machine 32" and flags=--"machine 32" and some others. How is >> the right-hand side of the assignment interpreted and how is that passed >> along to (I'm assuming) -- eventually -- a subprocess.Popen?
>> *********************************
>> As far as versions go, here's what I found (and the evidence as to why I >> think it):
>> VS2010:
>> the compilations I've done are with the Visual Studio Command Prompt >> (2010) [non-x64 Win64]
>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>>> Thanks for the info. Please let us know if adding "--machine 32" is >>> enough to solve your problem.
>>> It would also be interesting to know which part of your toolchain is 32 >>> bit:
>>> - Python?
>>> - Cuda?
>>> - Visual Studio?
>>> -=- Olivier
>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>>> Olivier,
>>> Thanks for that hint. I wouldn't have tried that otherwise: however, >>> it didn't help.
>>> Notice the important addition of "--machine 32" at the tail end. This >>> resolved a large number (10s? 100s?) of LNK2019, unresolved external >>> symbol errors that look like this:
>>> tmpxft_000005a0_00000000-15_**cuda_ndarray.obj : error LNK2019: >>> unresolved external symbol __imp_PyErr_Format referenced in function "void >>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>>> I'm personally a little confused as to what "bit-ness" my toolchain is >>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from >>> python to python libs to nvidia components to compiled/linked nvcc code). >>> However, it appears I was mistaken and/or I decided/realized I needed to >>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how >>> the internal theano/nvcc compilation goes.
>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>> Most likely won't help, but just in case, run "python theano-cache >>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated >>>> compiled code can lead to weird linking errors.
>>>>> The patch seems to have fixed the nvcc compilation error. Thanks >>>>> again!
>>>>> Now, I'm getting a large number of link errors. I will try to debug >>>>> and isolate what's going on there.
>>>>> Best,
>>>>> Mark
>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>>> Fred,
>>>>>> Thank you very much for working on this. I will update my repository >>>>>> and try it again sometime today.
>>>>>> Best,
>>>>>> Mark
>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should >>>>>>> reupdate.
>>>>>>> Fred
>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >>>>>>> wrote: >>>>>>> > I found the reason,
>>>>>>> > This microsoft compiler don't support variable len array in there >>>>>>> c++ >>>>>>> > compilier. So this line is not accepted:
>>>>>>> > I made a new PR and David just reviewed it. So if you update your >>>>>>> > version of Theano, it should work.
>>>>>>> > thanks for the report. If there is other problem(i hope not), >>>>>>> don't >>>>>>> > hesitate to tell us.
>>>>>>> > Fred
>>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> >>>>>>> wrote: >>>>>>> >> Fred,
>>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>>> >> I'm working with the development version of Theano. The specific >>>>>>> git commit >>>>>>> >> id is:
>>>>>>> >> % git log --oneline | more >>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm >>>>>>> working >>>>>>> >> against (from a working directory of Theano/theano/sandbox/cuda): >>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>>> >> Let me know if I can provide anything else.
>>>>>>> >> Best, >>>>>>> >> Mark
>>>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien >>>>>>> wrote:
>>>>>>> >>> witch verison of theano do you use? Also, can you join your >>>>>>> version of >>>>>>> >>> cuda_ndarray.cu file? That way, I can know what the line number >>>>>>> mean.
>>>>>>> >>> This line you give: >>>>>>> >>> > argument types are: (CudaNdarray *, int, >>>>>>> <error-type>)
>>>>>>> >>> the last parameter don't seam good. But this is working on >>>>>>> linux. So >>>>>>> >>> it is probably something that is different on linux and windows.
>>>>>>> >>> thanks for the report.
>>>>>>> >>> Fred
>>>>>>> >>> On Fri, Jul 20, 2012 at 2:17 PM, Mark <mark.fen...@coveros.com> >>>>>>> wrote: >>>>>>> >>> > Hi folks,
>>>>>>> >>> > I'm attempting to isolate some problems with a >>>>>>> Theano/Windows/GPU setup >>>>>>> >>> > (window 7/visual studio 2010/nvidia 4.2 cuda downloads/theano >>>>>>> latest >>>>>>> >>> > git) . >>>>>>> >>> > I isolated the theano nvcc call and separated that out. >>>>>>> Standalone, >>>>>>> >>> > from a >>>>>>> >>> > VS2010 command prompt, the nvcc command gives the following >>>>>>> output:
for the nvcc compiler, we add the -m32 or -m64 code for all platform
except for win32:
if sys.platform != 'win32':
if local_bitwidth() == 64:
cmd.append('-m64')
preargs2.append('-m64')
else:
cmd.append('-m32')
preargs2.append('-m32')
Should we do that also on windows? git blame tell it is me that added
the special case for windows to try to make the gpu code work on
windows. But I never succeded. That was a bad try. Olivier, do you
think I should remove the first if? I think that local_bitwidth() will
return the number of bits for the python version and I think that is
what we need to ask nvcc to generate. Do you agree?
Mark, I saw all you email, but i don't know what else I can do to help
make the mixed 32/64 bits environmant work correctly. Do you think of
something? The -L...x64 add a path when searching for library, but on
linux, if it find a library with the right name, but wrong 32/64 bits,
it just ignore it and continue its search. So adding it is not a
problem on linux. I suppose it is the same in your case as when there
is a problem related to this, the error are a compile time, not at run
time.
> Now that's VERY interesting. I didn't notice this before: the -L arg is
> for CUDA/4.2/lib/x64 and the -m32 seem incompatible. Yet this compiles
> cleanly (two warnings about unreachable code). Perhaps it would fail at run
> time.
> Best,
> Mark
> On Wednesday, July 25, 2012 1:23:58 PM UTC-4, Olivier Delalleau wrote:
>> Looks like you found a bug in the parsing of nvcc flags ;)
>> Use instead:
>> flags=-m32
>> This should work for now (I made an issue for this bug:
>> https://github.com/Theano/Theano/issues/785)
>> I'm not sure using 64 bit Cuda with 32 bit Python works, but you can give
>> it a shot...
>>> Ok, so, here's the latest. I can't figure out how to pass the "--machine
>>> 32" parameter through .theanorc to the internal nvcc command line. I've
>>> tried several permutations, but the parameter isn't being sent to the
>>> command in a way that makes the command happy. Here's my latest attempt:
>>> from .theanorc:
>>> [nvcc]
>>> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio
>>> 10.0\VC\bin
>>> flags=--machine 32
>>> I've also tried:
>>> flags="--machine 32" and flags=--"machine 32" and some others. How is
>>> the right-hand side of the assignment interpreted and how is that passed
>>> along to (I'm assuming) -- eventually -- a subprocess.Popen?
>>> *********************************
>>> As far as versions go, here's what I found (and the evidence as to why I
>>> think it):
>>> VS2010:
>>> the compilations I've done are with the Visual Studio Command Prompt
>>> (2010) [non-x64 Win64]
>>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>>>> Thanks for the info. Please let us know if adding "--machine 32" is
>>>> enough to solve your problem.
>>>> It would also be interesting to know which part of your toolchain is 32
>>>> bit:
>>>> - Python?
>>>> - Cuda?
>>>> - Visual Studio?
>>>> -=- Olivier
>>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>>>> Olivier,
>>>> Thanks for that hint. I wouldn't have tried that otherwise: however,
>>>> it didn't help.
>>>> Notice the important addition of "--machine 32" at the tail end. This
>>>> resolved a large number (10s? 100s?) of LNK2019, unresolved external
>>>> symbol errors that look like this:
>>>> tmpxft_000005a0_00000000-15_cuda_ndarray.obj : error LNK2019: unresolved
>>>> external symbol __imp_PyErr_Format referenced in function "void * __cdecl
>>>> device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>>>> I'm personally a little confused as to what "bit-ness" my toolchain is
>>>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from
>>>> python to python libs to nvidia components to compiled/linked nvcc code).
>>>> However, it appears I was mistaken and/or I decided/realized I needed to
>>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how
>>>> the internal theano/nvcc compilation goes.
>>>> Also: I saw a comment that talked about unrecognized "<" and the need
>>>> to register ".cu" files (I think) in Visual Studio. It's the last comment
>>>> (currently) on this SO thread. Incidentally, that thread deals with some of
>>>> the issues in using CUDA 4 with VS2010.
>>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>>> Most likely won't help, but just in case, run "python theano-cache
>>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated
>>>>> compiled code can lead to weird linking errors.
>>>>>> The patch seems to have fixed the nvcc compilation error. Thanks
>>>>>> again!
>>>>>> Now, I'm getting a large number of link errors. I will try to debug
>>>>>> and isolate what's going on there.
>>>>>> Best,
>>>>>> Mark
>>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>>>> Fred,
>>>>>>> Thank you very much for working on this. I will update my repository
>>>>>>> and try it again sometime today.
>>>>>>> Best,
>>>>>>> Mark
>>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should
>>>>>>>> reupdate.
>>>>>>>> Fred
>>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org>
>>>>>>>> wrote:
>>>>>>>> > I found the reason,
>>>>>>>> > This microsoft compiler don't support variable len array in there
>>>>>>>> > c++
>>>>>>>> > compilier. So this line is not accepted:
>>>>>>>> > I made a new PR and David just reviewed it. So if you update your
>>>>>>>> > version of Theano, it should work.
>>>>>>>> > thanks for the report. If there is other problem(i hope not),
>>>>>>>> > don't
>>>>>>>> > hesitate to tell us.
>>>>>>>> > Fred
>>>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com>
>>>>>>>> > wrote:
>>>>>>>> >> Fred,
>>>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>>>> >> I'm working with the development version of Theano. The specific
>>>>>>>> >> git commit
>>>>>>>> >> id is:
>>>>>>>> >> % git log --oneline | more
>>>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm
>>>>>>>> >> working
>>>>>>>> >> against (from a working directory of Theano/theano/sandbox/cuda):
>>>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>>>> >> Let me know if I can provide anything else.
Ah sorry, I hadn't paid enough attention: it looks like modifying
nvcc.flags actually forwards the option to the compiler (through
-Xcompiler) instead of actually using this option on the command line :(
I guess for now, just to test it, manually edit
theano/sandbox/cuda/nvcc_compiler.py, look for "-shared", and replace that
line with:
cmd = [nvcc_path, '-shared', '-g', '-m32'] + preargs1
to see if that helps. Then later we can figure out how to make it clean :)
> Now that's VERY interesting. I didn't notice this before: the -L arg is
> for CUDA/4.2/lib/x64 and the -m32 seem incompatible. Yet this compiles
> cleanly (two warnings about unreachable code). Perhaps it would fail at
> run time.
> Best,
> Mark
> On Wednesday, July 25, 2012 1:23:58 PM UTC-4, Olivier Delalleau wrote:
>>> Ok, so, here's the latest. I can't figure out how to pass the
>>> "--machine 32" parameter through .theanorc to the internal nvcc command
>>> line. I've tried several permutations, but the parameter isn't being sent
>>> to the command in a way that makes the command happy. Here's my latest
>>> attempt:
>>> from .theanorc:
>>> [nvcc]
>>> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio
>>> 10.0\VC\bin
>>> flags=--machine 32
>>> I've also tried:
>>> flags="--machine 32" and flags=--"machine 32" and some others. How is
>>> the right-hand side of the assignment interpreted and how is that passed
>>> along to (I'm assuming) -- eventually -- a subprocess.Popen?
>>> ***********************************
>>> As far as versions go, here's what I found (and the evidence as to why I
>>> think it):
>>> VS2010:
>>> the compilations I've done are with the Visual Studio Command Prompt
>>> (2010) [non-x64 Win64]
>>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>>>> Thanks for the info. Please let us know if adding "--machine 32" is
>>>> enough to solve your problem.
>>>> It would also be interesting to know which part of your toolchain is 32
>>>> bit:
>>>> - Python?
>>>> - Cuda?
>>>> - Visual Studio?
>>>> -=- Olivier
>>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>>>> Olivier,
>>>> Thanks for that hint. I wouldn't have tried that otherwise: however,
>>>> it didn't help.
>>>> Notice the important addition of "--machine 32" at the tail end. This
>>>> resolved a large number (10s? 100s?) of LNK2019, unresolved external
>>>> symbol errors that look like this:
>>>> tmpxft_000005a0_00000000-15_**cu**da_ndarray.obj : error LNK2019:
>>>> unresolved external symbol __imp_PyErr_Format referenced in function "void
>>>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z
>>>> )
>>>> I'm personally a little confused as to what "bit-ness" my toolchain is
>>>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from
>>>> python to python libs to nvidia components to compiled/linked nvcc code).
>>>> However, it appears I was mistaken and/or I decided/realized I needed to
>>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how
>>>> the internal theano/nvcc compilation goes.
>>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>>> Most likely won't help, but just in case, run "python theano-cache
>>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated
>>>>> compiled code can lead to weird linking errors.
>>>>>> The patch seems to have fixed the nvcc compilation error. Thanks
>>>>>> again!
>>>>>> Now, I'm getting a large number of link errors. I will try to debug
>>>>>> and isolate what's going on there.
>>>>>> Best,
>>>>>> Mark
>>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>>>> Fred,
>>>>>>> Thank you very much for working on this. I will update my
>>>>>>> repository and try it again sometime today.
>>>>>>> Best,
>>>>>>> Mark
>>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should
>>>>>>>> reupdate.
>>>>>>>> Fred
>>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org>
>>>>>>>> wrote:
>>>>>>>> > I found the reason,
>>>>>>>> > This microsoft compiler don't support variable len array in there
>>>>>>>> c++
>>>>>>>> > compilier. So this line is not accepted:
>>>>>>>> > I made a new PR and David just reviewed it. So if you update your
>>>>>>>> > version of Theano, it should work.
>>>>>>>> > thanks for the report. If there is other problem(i hope not),
>>>>>>>> don't
>>>>>>>> > hesitate to tell us.
>>>>>>>> > Fred
>>>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com>
>>>>>>>> wrote:
>>>>>>>> >> Fred,
>>>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>>>> >> I'm working with the development version of Theano. The
>>>>>>>> specific git commit
>>>>>>>> >> id is:
>>>>>>>> >> % git log --oneline | more
>>>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm
>>>>>>>> working
>>>>>>>> >> against (from a working directory of
>>>>>>>> Theano/theano/sandbox/cuda):
>>>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>>>> >> Let me know if I can provide anything else.
>>>>>>>> >> Best,
>>>>>>>> >> Mark
>>>>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien
>>>>>>>> wrote:
>>>>>>>> >>> witch verison of theano do you use? Also, can you join your
>>>>>>>> version of
>>>>>>>> >>> cuda_ndarray.cu file? That way, I can know what the line
>>>>>>>> number mean.
>>>>>>>> >>> This line you give:
>>>>>>>> >>> > argument types are: (CudaNdarray *, int,
>>>>>>>> <error-type>)
>>>>>>>> >>> the last parameter don't seam good. But this is
I can't remember why we didn't need this on Windows in our tests... I
suspect however that adding the "-mX" flag to preargs2 is a bad idea,
because I don't think it's a flag that Visual Studio will understand.
But maybe we indeed need to append it to cmd.
> for the nvcc compiler, we add the -m32 or -m64 code for all platform
> except for win32:
> if sys.platform != 'win32':
> if local_bitwidth() == 64:
> cmd.append('-m64')
> preargs2.append('-m64')
> else:
> cmd.append('-m32')
> preargs2.append('-m32')
> Should we do that also on windows? git blame tell it is me that added
> the special case for windows to try to make the gpu code work on
> windows. But I never succeded. That was a bad try. Olivier, do you
> think I should remove the first if? I think that local_bitwidth() will
> return the number of bits for the python version and I think that is
> what we need to ask nvcc to generate. Do you agree?
> Mark, I saw all you email, but i don't know what else I can do to help
> make the mixed 32/64 bits environmant work correctly. Do you think of
> something? The -L...x64 add a path when searching for library, but on
> linux, if it find a library with the right name, but wrong 32/64 bits,
> it just ignore it and continue its search. So adding it is not a
> problem on linux. I suppose it is the same in your case as when there
> is a problem related to this, the error are a compile time, not at run
> time.
> Fred
> On Wed, Jul 25, 2012 at 3:26 PM, Mark <mark.fen...@coveros.com> wrote:
> > Olivier,
> > This seems to fail for me [tail of python a-theano-script.py]:
> > Now that's VERY interesting. I didn't notice this before: the -L arg is
> > for CUDA/4.2/lib/x64 and the -m32 seem incompatible. Yet this compiles
> > cleanly (two warnings about unreachable code). Perhaps it would fail at
> run
> > time.
> > Best,
> > Mark
> > On Wednesday, July 25, 2012 1:23:58 PM UTC-4, Olivier Delalleau wrote:
> >> Looks like you found a bug in the parsing of nvcc flags ;)
> >> Use instead:
> >> flags=-m32
> >> This should work for now (I made an issue for this bug:
> >> https://github.com/Theano/Theano/issues/785)
> >> I'm not sure using 64 bit Cuda with 32 bit Python works, but you can
> give
> >> it a shot...
> >>> Ok, so, here's the latest. I can't figure out how to pass the
> "--machine
> >>> 32" parameter through .theanorc to the internal nvcc command line.
> I've
> >>> tried several permutations, but the parameter isn't being sent to the
> >>> command in a way that makes the command happy. Here's my latest
> attempt:
> >>> I've also tried:
> >>> flags="--machine 32" and flags=--"machine 32" and some others. How is
> >>> the right-hand side of the assignment interpreted and how is that
> passed
> >>> along to (I'm assuming) -- eventually -- a subprocess.Popen?
> >>> *********************************
> >>> As far as versions go, here's what I found (and the evidence as to why
> I
> >>> think it):
> >>> VS2010:
> >>> the compilations I've done are with the Visual Studio Command Prompt
> >>> (2010) [non-x64 Win64]
> >>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
> >>>> Thanks for the info. Please let us know if adding "--machine 32" is
> >>>> enough to solve your problem.
> >>>> It would also be interesting to know which part of your toolchain is
> 32
> >>>> bit:
> >>>> - Python?
> >>>> - Cuda?
> >>>> - Visual Studio?
> >>>> -=- Olivier
> >>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
> >>>> Olivier,
> >>>> Thanks for that hint. I wouldn't have tried that otherwise: however,
> >>>> it didn't help.
> >>>> Notice the important addition of "--machine 32" at the tail end. This
> >>>> resolved a large number (10s? 100s?) of LNK2019, unresolved external
> >>>> symbol errors that look like this:
> >>>> tmpxft_000005a0_00000000-15_cuda_ndarray.obj : error LNK2019:
> unresolved
> >>>> external symbol __imp_PyErr_Format referenced in function "void *
> __cdecl
> >>>> device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
> >>>> I'm personally a little confused as to what "bit-ness" my toolchain is
> >>>> -- I initially thought I was aiming for an "all 64-bit" toolchain
> (from
> >>>> python to python libs to nvidia components to compiled/linked nvcc
> code).
> >>>> However, it appears I was mistaken and/or I decided/realized I needed
> to
> >>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and
> see how
> >>>> the internal theano/nvcc compilation goes.
> >>>> Also: I saw a comment that talked about unrecognized "<" and the need
> >>>> to register ".cu" files (I think) in Visual Studio. It's the last
> comment
> >>>> (currently) on this SO thread. Incidentally, that thread deals with
> some of
> >>>> the issues in using CUDA 4 with VS2010.
> >>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
> >>>>> Most likely won't help, but just in case, run "python theano-cache
> >>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes
> outdated
> >>>>> compiled code can lead to weird linking errors.
> >>>>>> The patch seems to have fixed the nvcc compilation error. Thanks
> >>>>>> again!
> >>>>>> Now, I'm getting a large number of link errors. I will try to debug
> >>>>>> and isolate what's going on there.
> >>>>>> Best,
> >>>>>> Mark
> >>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
> >>>>>>> Fred,
> >>>>>>> Thank you very much for working on this. I will update my
> repository
> >>>>>>> and try it again sometime today.
> >>>>>>> Best,
> >>>>>>> Mark
> >>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien
> wrote:
> >>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you
> should
> >>>>>>>> reupdate.
> >>>>>>>> Fred
> >>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <
> no...@nouiz.org>
> >>>>>>>> wrote:
> >>>>>>>> > I found the reason,
> >>>>>>>> > This microsoft compiler don't support variable len array in
> there
> >>>>>>>> > c++
> >>>>>>>> > compilier. So this line is not accepted:
> >>>>>>>> > I made a new PR and David just reviewed it. So if you update
> your
> >>>>>>>> > version of Theano, it should work.
> >>>>>>>> > thanks for the report. If there is other problem(i hope
> Regarding 64-bit CUDA + 32-bit python ... I'm on my linux workstation, but
> I -think- (please double check if anything important depends on this) that
> the 64-bit CUDA libs come with BOTH 32 and 64 bit headers and libs. Thus,
> you can make 32-bit python happy by pointing the build
> scripts/configurations at the correct directory, gets you correct behavior.
> Again, that's from sketchy memory.
> Alright, so, I reviewed a few notes and part of my preceeding comments
> apply directly to installing and testing PyCuda (not theono, directly).
> However, the following seems relevent:
> (1) the python-amd64 that I downloaded and installed actually reports the
> platform information that I mentioned earlier (indicating 32-bit). I don't
> understand that and I may have made an error in my installation notes
> (however, my download directory only has the python-amd64 installer).
> Perhaps it is an architecture optimized build, but not a 64-bit build. I
> could definitely be wrong; just a guess.
>>> Ok, so, here's the latest. I can't figure out how to pass the
>>> "--machine 32" parameter through .theanorc to the internal nvcc command
>>> line. I've tried several permutations, but the parameter isn't being sent
>>> to the command in a way that makes the command happy. Here's my latest
>>> attempt:
>>> from .theanorc:
>>> [nvcc]
>>> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio
>>> 10.0\VC\bin
>>> flags=--machine 32
>>> I've also tried:
>>> flags="--machine 32" and flags=--"machine 32" and some others. How is
>>> the right-hand side of the assignment interpreted and how is that passed
>>> along to (I'm assuming) -- eventually -- a subprocess.Popen?
>>> ***********************************
>>> As far as versions go, here's what I found (and the evidence as to why I
>>> think it):
>>> VS2010:
>>> the compilations I've done are with the Visual Studio Command Prompt
>>> (2010) [non-x64 Win64]
>>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>>>> Thanks for the info. Please let us know if adding "--machine 32" is
>>>> enough to solve your problem.
>>>> It would also be interesting to know which part of your toolchain is 32
>>>> bit:
>>>> - Python?
>>>> - Cuda?
>>>> - Visual Studio?
>>>> -=- Olivier
>>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>>>> Olivier,
>>>> Thanks for that hint. I wouldn't have tried that otherwise: however,
>>>> it didn't help.
>>>> Notice the important addition of "--machine 32" at the tail end. This
>>>> resolved a large number (10s? 100s?) of LNK2019, unresolved external
>>>> symbol errors that look like this:
>>>> tmpxft_000005a0_00000000-15_**cu**da_ndarray.obj : error LNK2019:
>>>> unresolved external symbol __imp_PyErr_Format referenced in function "void
>>>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z
>>>> )
>>>> I'm personally a little confused as to what "bit-ness" my toolchain is
>>>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from
>>>> python to python libs to nvidia components to compiled/linked nvcc code).
>>>> However, it appears I was mistaken and/or I decided/realized I needed to
>>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how
>>>> the internal theano/nvcc compilation goes.
>>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>>> Most likely won't help, but just in case, run "python theano-cache
>>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated
>>>>> compiled code can lead to weird linking errors.
>>>>>> The patch seems to have fixed the nvcc compilation error. Thanks
>>>>>> again!
>>>>>> Now, I'm getting a large number of link errors. I will try to debug
>>>>>> and isolate what's going on there.
>>>>>> Best,
>>>>>> Mark
>>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>>>> Fred,
>>>>>>> Thank you very much for working on this. I will update my
>>>>>>> repository and try it again sometime today.
>>>>>>> Best,
>>>>>>> Mark
>>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien wrote:
>>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you should
>>>>>>>> reupdate.
>>>>>>>> Fred
>>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org>
>>>>>>>> wrote:
>>>>>>>> > I found the reason,
>>>>>>>> > This microsoft compiler don't support variable len array in there
>>>>>>>> c++
>>>>>>>> > compilier. So this line is not accepted:
>>>>>>>> > I made a new PR and David just reviewed it. So if you update your
>>>>>>>> > version of Theano, it should work.
>>>>>>>> > thanks for the report. If there is other problem(i hope not),
>>>>>>>> don't
>>>>>>>> > hesitate to tell us.
>>>>>>>> > Fred
>>>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com>
>>>>>>>> wrote:
>>>>>>>> >> Fred,
>>>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>>>> >> I'm working with the development version of Theano. The
>>>>>>>> specific git commit
>>>>>>>> >> id is:
>>>>>>>> >> % git log --oneline | more
>>>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm
>>>>>>>> working
>>>>>>>> >> against (from a working directory of
>>>>>>>> Theano/theano/sandbox/cuda):
>>>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
>>>>>>>> >> Let me know if I can provide anything else.
>>>>>>>> >> Best,
>>>>>>>> >> Mark
>>>>>>>> >> On Friday, July 20, 2012 5:35:33 PM UTC-4, Frédéric Bastien
>>>>>>>> wrote:
>>>>>>>> >>> witch verison of theano do you use? Also, can you join your
>>>>>>>> version of
>>>>>>>> >>> cuda_ndarray.cu file? That way, I can know what the line
>>>>>>>> number mean.
>>>>>>>> >>> This line you give:
>>>>>>>> >>> > argument types are: (CudaNdarray *, int,
>>>>>>>> <error-type>)
>>>>>>>> >>> the last parameter don't seam good. But this is working on
>>>>>>>> linux. So
>>>>>>>> >>> it is probably something that is different on linux and
>>>>>>>> windows.
On Wednesday, July 25, 2012 4:58:05 PM UTC-4, Olivier Delalleau wrote:
> For your Python install, the "bitness" of your architecture should be > available by running:
> python -c "import struct ; print struct.calcsize('P') * 8"
>> Regarding 64-bit CUDA + 32-bit python ... I'm on my linux workstation, >> but I -think- (please double check if anything important depends on this) >> that the 64-bit CUDA libs come with BOTH 32 and 64 bit headers and libs. >> Thus, you can make 32-bit python happy by pointing the build >> scripts/configurations at the correct directory, gets you correct behavior. >> Again, that's from sketchy memory.
>> Alright, so, I reviewed a few notes and part of my preceeding comments >> apply directly to installing and testing PyCuda (not theono, directly). >> However, the following seems relevent:
>> (1) the python-amd64 that I downloaded and installed actually reports >> the platform information that I mentioned earlier (indicating 32-bit). I >> don't understand that and I may have made an error in my installation notes >> (however, my download directory only has the python-amd64 installer). >> Perhaps it is an architecture optimized build, but not a 64-bit build. I >> could definitely be wrong; just a guess.
>>>> Ok, so, here's the latest. I can't figure out how to pass the >>>> "--machine 32" parameter through .theanorc to the internal nvcc command >>>> line. I've tried several permutations, but the parameter isn't being sent >>>> to the command in a way that makes the command happy. Here's my latest >>>> attempt:
>>>> from .theanorc:
>>>> [nvcc]
>>>> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio >>>> 10.0\VC\bin
>>>> flags=--machine 32
>>>> I've also tried:
>>>> flags="--machine 32" and flags=--"machine 32" and some others. How is >>>> the right-hand side of the assignment interpreted and how is that passed >>>> along to (I'm assuming) -- eventually -- a subprocess.Popen?
>>>> ***********************************
>>>> As far as versions go, here's what I found (and the evidence as to why >>>> I think it):
>>>> VS2010:
>>>> the compilations I've done are with the Visual Studio Command Prompt >>>> (2010) [non-x64 Win64]
>>>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>>>>> Thanks for the info. Please let us know if adding "--machine 32" is >>>>> enough to solve your problem.
>>>>> It would also be interesting to know which part of your toolchain is >>>>> 32 bit:
>>>>> - Python?
>>>>> - Cuda?
>>>>> - Visual Studio?
>>>>> -=- Olivier
>>>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>>>>> Olivier,
>>>>> Thanks for that hint. I wouldn't have tried that otherwise: however, >>>>> it didn't help.
>>>>> Notice the important addition of "--machine 32" at the tail end. This >>>>> resolved a large number (10s? 100s?) of LNK2019, unresolved external >>>>> symbol errors that look like this:
>>>>> tmpxft_000005a0_00000000-15_**cu**da_ndarray.obj : error LNK2019: >>>>> unresolved external symbol __imp_PyErr_Format referenced in function "void >>>>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>>>>> I'm personally a little confused as to what "bit-ness" my toolchain is >>>>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from >>>>> python to python libs to nvidia components to compiled/linked nvcc code). >>>>> However, it appears I was mistaken and/or I decided/realized I needed to >>>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how >>>>> the internal theano/nvcc compilation goes.
>>>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>>>> Most likely won't help, but just in case, run "python theano-cache >>>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated >>>>>> compiled code can lead to weird linking errors.
>>>>>>> The patch seems to have fixed the nvcc compilation error. Thanks >>>>>>> again!
>>>>>>> Now, I'm getting a large number of link errors. I will try to debug >>>>>>> and isolate what's going on there.
>>>>>>> Best,
>>>>>>> Mark
>>>>>>> On Monday, July 23, 2012 10:43:26 AM UTC-4, Mark wrote:
>>>>>>>> Fred,
>>>>>>>> Thank you very much for working on this. I will update my >>>>>>>> repository and try it again sometime today.
>>>>>>>> Best,
>>>>>>>> Mark
>>>>>>>> On Saturday, July 21, 2012 11:00:21 AM UTC-4, Frédéric Bastien >>>>>>>> wrote:
>>>>>>>>> My first merge fix introduced a bug. Now it is fixed. So you >>>>>>>>> should reupdate.
>>>>>>>>> Fred
>>>>>>>>> On Fri, Jul 20, 2012 at 7:14 PM, Frédéric Bastien <no...@nouiz.org> >>>>>>>>> wrote: >>>>>>>>> > I found the reason,
>>>>>>>>> > This microsoft compiler don't support variable len array in >>>>>>>>> there c++ >>>>>>>>> > compilier. So this line is not accepted:
>>>>>>>>> > I made a new PR and David just reviewed it. So if you update >>>>>>>>> your >>>>>>>>> > version of Theano, it should work.
>>>>>>>>> > thanks for the report. If there is other problem(i hope not), >>>>>>>>> don't >>>>>>>>> > hesitate to tell us.
>>>>>>>>> > Fred
>>>>>>>>> > On Fri, Jul 20, 2012 at 5:54 PM, Mark <mark.fen...@coveros.com> >>>>>>>>> wrote: >>>>>>>>> >> Fred,
>>>>>>>>> >> Hi. Thanks for your interest in my problem.
>>>>>>>>> >> I'm working with the development version of Theano. The >>>>>>>>> specific git commit >>>>>>>>> >> id is:
>>>>>>>>> >> % git log --oneline | more >>>>>>>>> >> b672a3a Merge pull request #758 from goodfeli/doc
>>>>>>>>> >> The follow should get the version of cuda_ndarray.cu that I'm >>>>>>>>> working >>>>>>>>> >> against (from a working directory of >>>>>>>>> Theano/theano/sandbox/cuda): >>>>>>>>> >> % git show b672a3a:./cuda_ndarray.cu
Success! Well, partial success: My theano script (aka, python script using theano calls) is running happily; however, I'm not sure that it is GPU-enabled and/or accelerated. I'm going to double check that.
Olivier, thank you very much for your help. In return, I'm going to start from a clean slate (uninstall everything I can find) and re-work my steps, document them, and submit it so others can follow it.
On Wednesday, July 25, 2012 4:53:39 PM UTC-4, Olivier Delalleau wrote:
> Ah sorry, I hadn't paid enough attention: it looks like modifying > nvcc.flags actually forwards the option to the compiler (through > -Xcompiler) instead of actually using this option on the command line :(
> I guess for now, just to test it, manually edit > theano/sandbox/cuda/nvcc_compiler.py, look for "-shared", and replace that > line with:
> cmd = [nvcc_path, '-shared', '-g', '-m32'] + preargs1
> to see if that helps. Then later we can figure out how to make it clean :)
>> Now that's VERY interesting. I didn't notice this before: the -L arg is >> for CUDA/4.2/lib/x64 and the -m32 seem incompatible. Yet this compiles >> cleanly (two warnings about unreachable code). Perhaps it would fail at >> run time.
>> Best,
>> Mark
>> On Wednesday, July 25, 2012 1:23:58 PM UTC-4, Olivier Delalleau wrote:
>>>> Ok, so, here's the latest. I can't figure out how to pass the >>>> "--machine 32" parameter through .theanorc to the internal nvcc command >>>> line. I've tried several permutations, but the parameter isn't being sent >>>> to the command in a way that makes the command happy. Here's my latest >>>> attempt:
>>>> from .theanorc:
>>>> [nvcc]
>>>> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio >>>> 10.0\VC\bin
>>>> flags=--machine 32
>>>> I've also tried:
>>>> flags="--machine 32" and flags=--"machine 32" and some others. How is >>>> the right-hand side of the assignment interpreted and how is that passed >>>> along to (I'm assuming) -- eventually -- a subprocess.Popen?
>>>> ***********************************
>>>> As far as versions go, here's what I found (and the evidence as to why >>>> I think it):
>>>> VS2010:
>>>> the compilations I've done are with the Visual Studio Command Prompt >>>> (2010) [non-x64 Win64]
>>>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>>>>> Thanks for the info. Please let us know if adding "--machine 32" is >>>>> enough to solve your problem.
>>>>> It would also be interesting to know which part of your toolchain is >>>>> 32 bit:
>>>>> - Python?
>>>>> - Cuda?
>>>>> - Visual Studio?
>>>>> -=- Olivier
>>>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>>>>> Olivier,
>>>>> Thanks for that hint. I wouldn't have tried that otherwise: however, >>>>> it didn't help.
>>>>> Notice the important addition of "--machine 32" at the tail end. This >>>>> resolved a large number (10s? 100s?) of LNK2019, unresolved external >>>>> symbol errors that look like this:
>>>>> tmpxft_000005a0_00000000-15_**cu**da_ndarray.obj : error LNK2019: >>>>> unresolved external symbol __imp_PyErr_Format referenced in function "void >>>>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@@YAPEAX_K@Z)
>>>>> I'm personally a little confused as to what "bit-ness" my toolchain is >>>>> -- I initially thought I was aiming for an "all 64-bit" toolchain (from >>>>> python to python libs to nvidia components to compiled/linked nvcc code). >>>>> However, it appears I was mistaken and/or I decided/realized I needed to >>>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how >>>>> the internal theano/nvcc compilation goes.
>>>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>>>> Most likely won't help, but just in case, run "python theano-cache >>>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated >>>>>> compiled code can lead to weird linking errors.
> And my architecture is reported as 32-bit: ('32bit', 'WindowsPE'). There
> is always a non-zero possibility that I installed a different python.
> Best,
> Mark
> On Wednesday, July 25, 2012 4:58:05 PM UTC-4, Olivier Delalleau wrote:
>> For your Python install, the "bitness" of your architecture should be
>> available by running:
>> python -c "import struct ; print struct.calcsize('P') * 8"
>>> Regarding 64-bit CUDA + 32-bit python ... I'm on my linux workstation,
>>> but I -think- (please double check if anything important depends on this)
>>> that the 64-bit CUDA libs come with BOTH 32 and 64 bit headers and libs.
>>> Thus, you can make 32-bit python happy by pointing the build
>>> scripts/configurations at the correct directory, gets you correct behavior.
>>> Again, that's from sketchy memory.
>>> Alright, so, I reviewed a few notes and part of my preceeding comments
>>> apply directly to installing and testing PyCuda (not theono, directly).
>>> However, the following seems relevent:
>>> (1) the python-amd64 that I downloaded and installed actually reports
>>> the platform information that I mentioned earlier (indicating 32-bit). I
>>> don't understand that and I may have made an error in my installation notes
>>> (however, my download directory only has the python-amd64 installer).
>>> Perhaps it is an architecture optimized build, but not a 64-bit build. I
>>> could definitely be wrong; just a guess.
>>>>> Ok, so, here's the latest. I can't figure out how to pass the
>>>>> "--machine 32" parameter through .theanorc to the internal nvcc command
>>>>> line. I've tried several permutations, but the parameter isn't being sent
>>>>> to the command in a way that makes the command happy. Here's my latest
>>>>> attempt:
>>>>> from .theanorc:
>>>>> [nvcc]
>>>>> compiler_bindir=C:\Program Files (x86)\Microsoft Visual Studio
>>>>> 10.0\VC\bin
>>>>> flags=--machine 32
>>>>> I've also tried:
>>>>> flags="--machine 32" and flags=--"machine 32" and some others. How is
>>>>> the right-hand side of the assignment interpreted and how is that passed
>>>>> along to (I'm assuming) -- eventually -- a subprocess.Popen?
>>>>> *************************************
>>>>> As far as versions go, here's what I found (and the evidence as to why
>>>>> I think it):
>>>>> VS2010:
>>>>> the compilations I've done are with the Visual Studio Command Prompt
>>>>> (2010) [non-x64 Win64]
>>>>> On Tuesday, July 24, 2012 6:39:24 PM UTC-4, Olivier Delalleau wrote:
>>>>>> Thanks for the info. Please let us know if adding "--machine 32" is
>>>>>> enough to solve your problem.
>>>>>> It would also be interesting to know which part of your toolchain is
>>>>>> 32 bit:
>>>>>> - Python?
>>>>>> - Cuda?
>>>>>> - Visual Studio?
>>>>>> -=- Olivier
>>>>>> Le 2012-07-24 à 10:53, Mark <mark.fen...@coveros.com> a écrit :
>>>>>> Olivier,
>>>>>> Thanks for that hint. I wouldn't have tried that otherwise:
>>>>>> however, it didn't help.
>>>>>> Notice the important addition of "--machine 32" at the tail end.
>>>>>> This resolved a large number (10s? 100s?) of LNK2019, unresolved
>>>>>> external symbol errors that look like this:
>>>>>> tmpxft_000005a0_00000000-15_**cu****da_ndarray.obj : error LNK2019:
>>>>>> unresolved external symbol __imp_PyErr_Format referenced in function "void
>>>>>> * __cdecl device_malloc (unsigned __int64)" (?device_malloc@
>>>>>> @YAPEAX_K@Z)
>>>>>> I'm personally a little confused as to what "bit-ness" my toolchain
>>>>>> is -- I initially thought I was aiming for an "all 64-bit" toolchain (from
>>>>>> python to python libs to nvidia components to compiled/linked nvcc code).
>>>>>> However, it appears I was mistaken and/or I decided/realized I needed to
>>>>>> move to 32-bit. I'm going to add --machine 32 to my .theanorc and see how
>>>>>> the internal theano/nvcc compilation goes.
>>>>>> On Monday, July 23, 2012 12:36:58 PM UTC-4, Olivier Delalleau wrote:
>>>>>>> Most likely won't help, but just in case, run "python theano-cache
>>>>>>> clear" (theano-cache can be found in the bin subfolder). Sometimes outdated
>>>>>>> compiled code can lead to weird linking errors.