1. Create a ".cu" file for your kernels;
2. For each kernel you would like to call from C++, create a wrapper that can be called from inside your class;
3. Inside this wrapper, call your kernel function;
4. Include the prototype for your wrapper in the header file of your class, but not inside the class definition.

An example of the ".cu" file and the class header are shown below. One thing you apparently do not need to do (particularly in Visual Studio 2010) is include the ".cu" file in your class. As long as it is part of your project, everything should work just fine.

#ifndef _PROJECT_KERNELS
#define _PROJECT_KERNELS

__global__ void kernel(double Param1, double Param2){
    // Do Kernel Stuff here
}
extern "C" void functionName(double Param1, double Param2){

    kernel<<<Nb, Nt>>kernel(Param1, Param2);
}
#endif

#ifndef MYCLASS_H_
#define MYCLASS_H_

#include <cuda.h>
#include "cuda_runtime.h"

extern "C" void functionName(double Param1, double Param2);

class myClass{
    myClass();
}
#endif

While at pragprog.com, I stumbled across their magazine, PragPub. In the September 2009 magazine there is a wonderful article titled, "Beauty in Code." The entire article deals with understanding the function and meaning of these unique snippets of code. While this is a fun challenge (I may use this in the classroom someday), it makes a solid point regarding development that is very well stated in the article:

We translate user stories into source code. How much of it survives the operation? More importantly, how much of it gets lost in the translation?

The issue being dealt with here is clarity. Clarity in code is vital and adds directly to the beauty of what is being developed in both form in function. While I could rant on this topic for quite some time, I will simply let this simmer for a while.

I leave you with two excellent quotes. The first is from the article I've discussed and the other is from Java.next #4: Immutability.

If you do it right, the beauty you see is multifaceted. If the code (as it runs) is as beautiful as the code (as it is written), then you are singing it just right.

Languages are not about what they make possible, but about what they make beautiful.

There’s 60 years of existing scientific knowledge buried in code and it’s extremely difficult to extract. As scientists write new code, they need to clearly ex­press intent in a way that doesn’t affect code performance.

This reinforces the idea that there is a huge issue concerning the writing of clear, concise, and understandable code in industry and academics. In light of this idea, I've recently published an article with Henry Ledgard titled "Coding Guidelines: Finding the Art in the Science" that can be found here and here. The article itself is focused on the idea that there is a role that aesthetics plays when writing code. This is perhaps summed up best by the first few lines of the article:

Computer science is both a science and an art. Its scientific aspects range from the theory of computation and algorithmic studies to code design and program architecture. Yet, when it comes time for implementation, there is a combination of artistic flare, nuanced style, and technical prowess that separates good code from great code.

This article, as opposed to those that layout strict coding guidelines to increase performance and maintainability, is focused on developing code that is easier to read by focusing on the aesthetic appeal of the code. And, while it has not been studied yet, code that appeals to developers in this fashion should lead to 1) Easier maintenance, 2) Increased productivity, and 3) A shorter period of acclimation when working with an unfamiliar code base.

In the paper, we present 6 distinct guidelines that should be followed as much is possible:

1. Consider a program as a table;
2. Let simple English be your guide;
3. Rely on context to simplify code;
4. Use white space to show structure;
5. Let decision structures speak for themselves; and
6. Focus on the code, not the comments.

Some of these ideas are controversial and some people will see a few things that we have presented as impractical. That is why we have presented our ideas as "guidelines", not "standards". This is a flexible set of ideas that can be molded to fit individuals and corporations alike.

Beyond this, the use of aesthetics in coding suggests that there are some general principles that will aid in making code appealing to nearly everyone, though there will be some nuances between different developers.

One thing I would like to mention is that some folks have pointed out some errors in the Figures (particularly Figure 1). I would encourage readers not to lose sight of the "forest for the trees" in this situation as requests have been made to fix these minor errors. This is particularly true as the guidelines are intended to be IDE, language, and syntax neutral. Thus, the visual appeal (and the point) of the examples should be apparent regardless.

First, the clarity and the ability of code to communicate intent clearly are very important. If I could only find a way to articulate how important clarity and communication are for code stability, I would, but I find that anything I say does not express this clearly enough. So, from the article:

"There’s 60 years of existing scientific knowledge buried in code and it’s extremely difficult to extract. As scientists write new code, they need to clearly ex­press intent in a way that doesn’t affect code performance. Code structures are one way to help capture intent and knowledge, yet they don’t impede performance."

Second, results of what you code must be verified somehow. Again, from the article:

"One panelist pointed out that testing results in “reviewing the output instead of reviewing the code.”Everyone agrees that code review is a good idea. However, it’s difficult to incorporate code review into work practices without the large overhead it commonly entails."

So, if you are writing code, please consider the clarity and intent of what you are writing. This is important and will save many developers, scientists, and others hours of wasted time. Also, if you write scientific code, please share it with the community. Critiquing code, verifying results, and extending algorithms would be much easier if there was a real atmosphere of cooperation out there.

The code below is intended to get you started working with PSO in Matlab or Octave. Best efforts were made to keep the code clean and easy to understand. Feel free to play with it and contact me with any questions.

Click Here to Download PSO.m

Downloads: PDF | Bibtex

[1] Q. Yu, C. Chen, and Z. Pan, “Parallel genetic algorithms on programmable graphics hardware,” in Lecture Notes in Computer Science
3612. Springer, 2005, p. 1051.

[2] P. Pospichal and J. Jaros, “GPU-based Acceleratino of the Genetic Algorithm,” in Proceedings of GECCO 2009, 2009.

[3] A. Munawar, M. Wahib, M. Munetomo, and K. Akama, “Hybrid of genetic algorithm and local search to solve max-sat problem using NVIDIA CUDA framework,” Genetic Programming and Evolvable Machines, vol. 10, pp. 391–415, 2009.

[4] S. Debattistic, N. Marlat, L. Mussi, and S. Cagnoni, “Implementatino of a Simple Genetic Algorithm within the CUDA Architecture,” in Proceedings of GECCO 2009, 2009.

[5] S. Zhang and Z. He, “Implementation of parallel genetic algorithm based on cuda,” in Advances in Computation and Intelligence, ser. Lecture Notes in Computer Science, Z. Cai, Z. Li, Z. Kang, and Y. Liu, Eds. Springer Berlin / Heidelberg, 2009, vol. 5821, pp. 24–30.

[6] S. Tsutsui and N. Fujimoto, “Solving quadratic assignment problems by genetic algorithms with gpu computation: a case study,” in Proceedings of the 11th Annual Conference Companion on Genetic and Evolutionary Computation Conference: Late Breaking Papers, ser. GECCO ’09. New York, NY, USA: ACM, 2009, pp. 2523–2530.

[7] P. Vidal and E. Alba, “A multi-gpu implementation of a cellular genetic algorithm,” in 2010 IEEE Congress on Evolutionary Computation (CEC), July 2010, pp. 1–7.

[8] ——, “Cellular genetic algorithm on graphic processing units,” in Nature Inspired Cooperative Strategies for Optimization (NICSO 2010), ser. Studies in Computational Intelligence, J. Gonzlez, D. Pelta, C. Cruz, G. Terrazas, and N. Krasnogor, Eds. Springer Berlin/Heidelberg, 2010, vol. 284, pp. 223–232.

[9] R. Arora, R. Tulshyan, and K. Deb, “Parallelization of binary and real-coded genetic algorithms on GPU using CUDA,” in IEEE Congress on Evolutionary Computation, 2010, pp. 1–8.

[10] N. Fujimoto and S. Tsutsui, “A highly-parallel tsp solver for a gpu computing platform,” in Proceedings of the 7th international conference on Numerical methods and applications, ser. NMA’10. Berlin, Heidelberg: Springer-Verlag, 2011, pp. 264–271.

Downloads: PDF | Bibtex

[1] J. Zhao, Q. Liu, W. Wang, Z. Wei, and P. Shi, “A parallel immune algorithm for traveling salesman problem and its application on cold
rolling scheduling,” Information Sciences, vol. 181, no. 7, pp. 1212 – 1223, 2011.
[2] J. Li, L. Zhang, and L. Liu, “A Parallel Immune Algorithm Based on Fine-grained Model with GPU-Acceleration,” in Foruth International
Conference on Innovative Computing, Information, and Control, 2009, pp. 683–686.

Downloads: PDF | Bibtex

[1] J. Li, X. Hu, Z. Pang, and K. Qian, “A Parallel Ant Colony Optimization Algorithm based on Fine-Grained Model with GPU-Acceleration,” Internation Journal of Innovative Computing, Information, and Control, vol. 5, no. 11(A), November 2009.

[2] Y.-S. You, “Parallel ant system for traveling salesman problem on GPUs,” in Proceedings of GECCO 2009, 2009.

[3] S. Sanci, “A Parallel Algorithm for Flight Route Planning on GPU using CUDA,” Master’s thesis, Middle East Technical University,
Turkey, 2010.

[4] J. M. Cecilia, J. M. Garca, M. Ujaldon, A. Nisbet, and M. Amos, “Parallelization strategies for ant colony optimisation on GPUs,”
Computing Research Repository, pp. –1–1, 2011.

Downloads: PDF | Bibtex

[1] G. A. Laguna-Snchez, M. Olgun-Carbajal, N. Cruz-Corts, and R. B.-F. J. A. Alvarez-Cedillo, “Comparative study of parallel variants for a particle swarm optimization,” Journal of Applied Research and Technology, vol. 7, no. 3, pp. 292–309, 2010.

[2] Y. Zhou and Y. Tan, “GPU-based parallel particle swarm optimization,” in Proceedings of the Eleventh conference on Congress on Evolutionary Computation, ser. CEC '09. Piscataway, NJ, USA: IEEE Press, 2009, pp. 1493–1500.

[3] L. Mussi, S. Cagnoni, and F. Daolio, “GPU-based road sign detection using particle swarm optimization,” in Ninth International Conference on Intelligent Systems Design and Applications, December 2009, pp. 152 –157.

[4] W. Zhu and J. Curry, “Particle swarm with graphics hardware acceleration and local pattern search on bound constrained problems,” in IEEE Swarm Intelligence Symposium, 2009. SIS ’09, April 2009, pp. 1–8.

[5] L. de P. Veronese and R. Krohling, “Swarm’s flight: Accelerating the particles using C-CUDA,” in IEEE Congress on Evolutionary Computation, 2009. CEC ’09., May 2009, pp. 3264 –3270.

[6] B. Rymut and B. Kwolek, “Gpu-supported object tracking using adaptive appearance models and particle swarm optimization,” in Proceedings of the 2010 international conference on Computer vision and graphics: Part II, ser. ICCVG’10. Berlin, Heidelberg: Springer-Verlag, 2010, pp. 227–234.

[7] C. Bastos-Filho, M. Oliveira, D. Nascimento, and A. Ramos, “Impact of the random number generator quality on particle swarm optimization algorithm running on graphic processor units,” in Hybrid Intelligent Systems (HIS), 2010 10th International Conference on, August 2010, pp. 85–90.

[8] L. Mussi, F. Daolio, and S. Cagnoni, “Evaluation of parallel particle swarm optimization algorithms within the CUDA(TM) architecture,” Information Sciences, vol. In Press, Corrected Proof, 2010.

[9] L. Mussi, S. Ivekovic, and S. Cagnoni, “Markerless articulated human body tracking from multi-view video with gpu-pso,” in Proceedings of the 9th international conference on Evolvable systems: from biology to hardware, ser. ICES’10. Berlin, Heidelberg:Springer-Verlag, 2010, pp. 97–108.

[10] Y. Tan and Y. Zhou, “Parallel particle swarm optimization algorithm based on graphic processing units,” in Handbook of Swarm Intelligence, ser. Adaptation, Learning, and Optimization, L. M. Hiot, Y. S. Ong, B. K. Panigrahi, Y. Shi, and M.-H. Lim, Eds. Springer Berlin Heidelberg, 2010, vol. 8, pp. 133–154.

[11] Y. Zhou and Y. Tan, “Particle swarm optimization with triggered mutation and its implementation based on GPU,” in Proceedings of the 12th annual conference on Genetic and evolutionary computation, ser. GECCO ’10. New York, NY, USA: ACM, 2010, pp. 1–8.

This is where all the hardware excitement meets the cold reality of parallel programming. We are all familiar with “Moore’s Law” (the transistor density doubles every two years). Many people have probably not heard of “May’s Law.” (for the purist, you can substitute “trend” for “law”). In any case, David May states his law as follows, “Software efficiency halves every 18 months, compensating for Moore’s Law.” Think about it. Every new generation of hardware

Moore's Law - The number of transistors on a chip doubles roughly every 2 years

May's Law - Software efficiency halves every 18 months, compensating for Moore’s Law.

Chew on that.