Printable View
I had a little trouble getting it to build and link into my system but now that I have, I gotta say, I really like it. The ability to auto-magically generate tests is pretty amazing. I definitely recommend giving it a shot if you haven't already.
Mandatory link
Bah. Your "Mandatory link" looks so much like certain spam links that I almost reached for the ban hammer, lol
Which is even more ironic because the link takes you to github lol XD
We have been having a lot of weird spammers recently though. And I suppose my post did model that format.
But I can assure you, I'm not a bot trying to spam these forums.
I've come a bit farther with Windows and development now. About Visual Studio, it doesn't know how to automatically track dependencies in .cu files which is problematic to say the least because all my code is headers and very few source files so the fact that my code doesn't recompile upon header change is huge. So I've switched to CMake. I've learned a bit more about CMake and how awesome it is so now I'm using CMake + MSBuild which is working out pretty well. Someday I'll learn how to compile it in Release mode :P
Visual Studio isn't ideal for CUDA like I was hoping it'd be. I can use the .sln files that CMake spits out with Visual Studio but honestly, if I'm already going to be using CMake at the command-line, I feel like it doesn't matter what IDE I use anymore.
That being said, VS is great because I couldn't get GTest to link right away. First, I encountered bitness errors. MSBuild seems to fetishize 32 bit builds and what's even more frustrating is that you can't link 32 bit object files to 64 bit ones. So I learned `cmake -G "Visual Studio 14 2015 Win64". One problem solved. Now I had more linking errors out the wazoo. Now apparently, GTest's .lib files were built using a different C runtime than what I was building my software with. I didn't know how to fix it on my end with the CMakeLists.txt file that I was using.
So I broke down, opened up the GTest solution file and built everything in Visual Studio which was nice. I went nuts. Debug mode, Release mode, 64 bit mode, genderating code with /MDd because that's a thing now... Visual Studio was there when I needed a savior. The command line had let me down. I was lost, frustrated and just scared of what my future with C++ might look like. Then Visual Studio saved the day.
I was able to link back GTest into my project and now I have a working test suite! I'm going to sort of focus on just writing tests and updating my codebase vs getting Release mode to work. When I was testing my code on Linux before all this mess, it was freakishly fast (compared to what I had written in the past) so I'm going to push ahead, putting correctness and robustness ahead of performance. After all, it's easier to optimize correct code than it is to correct optimized code.
So yeah, my journey with Windows has been interesting. I love CMake to death now. I like MSBuild. I'm still digging the Windows CLI and I haven't been bitten yet my MSVC's weirdness.
So, go build GTest. Integrate into your CMake-based project and profit!
If you're using Visual Studio, how about giving C++ AMP a try? It's Microsoft's solution to trying to get C++ onto GPUs (as opposed to OpenCL and CUDA which insists on being C).
Also, also, try the latest 2017 RC. From what I hear, it has CMake support! Fun times.
Wow, I'm impressed by MS's AMP O_o
I like how they're wholeheartedly embracing the view abstraction that's becoming popular. Even MongoDB is jumping on-board with that as well. It's good to see! And CMake support is nice. I think they're starting to jump ship as well because MS is attempting cross-platform development.
I'm scared of trying the RC though T_T
I finally got things to work at home and I'm scared of breaking it :P
I guess I learned how to put it all together so I shouldn't be afraid but last night was the first night in awhile where I came home and actually got to program.
One thing I'm wondering about now is C++'s AMP vs CUDA. I also wouldn't say that CUDA insists on being C. nvcc supports C++11. But there is a CUDA C API (basically just C written in C++ :P) which some naive fools like to use instead of the Thrust library. I feel like CUDA is the poster child of why C++ is, um, "better" than C. Not like C is bad. Just... It's lack of higher-level constructs can really become a PITA for something like CUDA.
Which is why we're using C++ over C in the first place, so yeah, I'd say it's a bit lacking. C hasn't really been the best of computing languages for the desktop, so I am really mystified why they chose something like C for GPUs.Quote:
Originally Posted by MutantJohn
Anyway, be careful with AMP. I've tried it, and it crashed my graphics drivers a few times while I tried :P
Thankfully they in user mode.
Because C can be faster.
Tests have shown that C++ can be faster than C too, so that argument holds no weight.
Can be, but C ends up being faster more than 50% of the time. The Computer Language Benchmarks Game has always been my standard.
That's a load of nonsense. It all depends on how you write your code, your compiler and your CPU.
Yeah. You are right Elysia. C++ is faster than C.
I did not say that. "C is faster than C++ 50% of the time" being false does not imply "C++ is faster than C."
So, what are you saying exactly?
I think Mario was trolling lol XD
The C++ implementations can honestly just be poor ones though, full of needless abstraction that is not zero-cost.
Some of the issues with C++ is that it's a very complex language. Like yesterday I was finally learning about lvalues of type rvalue reference and how forwarding references are different than normal rvalue references and all that jazz. The whole thing is very easy to get wrong.
Or maybe the C++ compiler can't make as many performance guarantees and that's why it's slower?
Let me help you Elysia:
- "Because C can be faster", said Epy
- "Tests have shown that C++ can be faster than C too, so that argument holds no weight.", retorted Elysia
He says can be, you say can be not. Which is implied when one says "can be". But other than giving you a medal for stating the obvious, what exactly did you want to say with that? That the makers of CUDA (an highly performant and optimized library) decided on purpose to program it in a slower C language? Or that maybe C++ wasn't the best option performance-wise for a low-level API?
- Epy said, "Can be, but C ends up being faster more than 50% of the time. The Computer Language Benchmarks Game has always been my standard."
- Elysia replied, "That's a load of nonsense. It all depends on how you write your code, your compiler and your CPU."
He says half of the time it is faster, you says it all depends. So, here is your second medal for mastering the obvious. But again, what do you mean? You mean to say that if the CUDA developers had used C++ correctly with the correct compiler and the correct CPU they would have created an API that would be faster than developed in C under the same conditions (correct use of the language, correct compiler and correct CPU)?
(And how the heck a correct CPU and correct compiler fits in a cross-platform library? But, whatever)