Archives de catégorie : Dev

CUDA

Voici la seconde partie de mon article sur les GPU.
Celui-ci vous permettra de découvrir CUDA de NVIDIA

1      Présentation

CUDA ou Computer Unified Device Architecture est une librairie de développement créée par NVIDIA en 2007. Celle-ci associée à une carte graphique compatible, permet d’utiliser la puissance de calculs des GPU d’architectureG80 et plus de NVidia (à partir des GeForce 8800 et déclinaisons).
Par abus de langage nous parlerons aussi de langage CUDA.
CUDA est aussi le premier langage à exploiter l’unification des shaders : les processeurs de la carte ne sont pas différentiés en unités pour le traitement des vertex ou des fragments, chacun de ceux-ci peut être assigné à n’importe quelle tâche.

L’API CUDA supporte plusieurs langages tels que le C, le C++ et le Fortran.
Ces trois langages peuvent être utilisés simultanément pour écrire diverses fonctions exécutées par le GPU.

Il existe cependant des « wrapper », des passerelles, servant de liaison entre ces langages bas-niveau et des langages de plus haut niveaux tels que Python, Java et .Net.

CUDA est constitué d’un pilote (driver), déjà intégré aux drivers les plus récents, d’un runtime, et de quelques librairies.

Les différents composants de CUDA
Les différents composants de CUDA

Il existe 3 niveaux de programmation pour CUDA, chacune disposant de sa propre API :

–       Utilisation d’une librairie externe.
Celle-ci, possède le code de toute les fonctions à exécuter par le GPU, et sert de liaison entre le programme et le GPU.
Le développeur ne peut utiliser que certaines fonctions prédéfinies, et ne peut contrôler directement le GPU.
Les deux librairies les plus connues sont CUBLAS qui offre un ensemble d’éléments pour réaliser des calculs d’algèbre linéaires sur le GPU, ainsi que CUFFT qui permet le calcul de transformée de Fourrier.

–       l’API de haut niveau : l’API CUDA Runtime ou appelée plus communément C for CUDA.
Cette API est implémentée « au dessus » de l’API bas niveau. Chaque appel à une fonction du runtime est décomposé en instructions plus basiques gérées par l’API driver.
Ces 2 API sont exclusives : le programmeur doit utiliser soit l’une soit l’autre. Il est impossible de mélanger des appels de fonctions de l’une et de l’autre.
Lorsque l’on parle d’API de haut niveau, il convient de relativiser : l’API runtime reste ce que beaucoup considèreraient comme déjà de très bas niveau. Cependant elle offre des fonctions bien pratiques pour l’initialisation ou la gestion des contextes.
Cette API sera la plus couramment utilisée.

–       l’API de bas niveau : l’API CUDA Driver.
Cette API est plus complexe à gérer, elle demande plus de travail pour lancer un traitement sur le GPU, mais en contrepartie elle est plus flexible, offrant un contrôle supplémentaire au programmeur qui le désire.
Cette API a l’avantage de pouvoir charger des portions de code en tant que module à partir de code binaires CUDA ou de code assembleur, et permet aussi d’inspecter les paramètres, …
Cette API est beaucoup plus difficile à écrire, à débugger et nécessite beaucoup plus de lignes de code à écrire, mais elle offre de meilleure performances.

Les API Runtime et Driver sont capables toutes les deux de communiquer avec des ressources OpenGL ou Direct3D. L’utilité est évidente : CUDA pourrait être utilisé pour générer des ressources (géométrie, textures procédurales, etc.) qui seraient ensuite passées à l’API graphique ou à l’inverse on pourrait imaginer que l’API 3D pourrait envoyer le résultat du rendu à CUDA qui serait dans ce cas utilisé pour effectuer un post traitement. Les exemples d’interactions sont nombreux et l’avantage est que les ressources restent stockées dans la mémoire RAM du GPU sans avoir à passer par le goulot d’étranglement du bus PCI-Express.

CUDA est fourni avec un « émulateur » : le code devant s’exécuter sur le GPU est en fait exécuté sur le GPU. Les performances sont alors bien moindres, mais permettent de débugger l’application et de tester celle-ci lorsqu’on ne dispose pas de GPU compatible.

Authentification Kerberos en JNDI

La documentation officiel java au sujet de l’authentification kerberos en JNDI est très bien faite. Mais je vais quand même me faire un petit mémo à ce sujet.

Le but du jeu est de mettre en place un processus d’authentification sécurisé entre une application java sur un poste en Windows XP et un controleur de domaine active directory sur Windows 2003. Le login et mot de passe utilisé sont ceux de l’utilisateur définis dans l’AD. Tout ceci en utilisant JNDI pour les requêtes LDAP.

Il existe plusieurs méthode d’authentification sécurisé SASL pour JNDI. Je vais ici parler uniquement de l’authentification en Kerberos v5 à travers la GSSAPI.

Continuer la lecture de Authentification Kerberos en JNDI

Problème de case des noms de tables MySQL

Bonjour,

Aujourd’hui j’aimerais vous faire part d’un problème courant en ce qui concerne le développement via MySQL sous Windows et sous Unix. La configuration par défaut du serveur MySQL n’est pas la même selon le système d’exploitation. Dans mon cas, le problème vient de la variable lower_case_table_names. Cette dernière est configurée à 1 sous Windows et à 0 sous Unix.Vous pourrez trouver tous les détails dans la documentation officielle sur ce sujet et ainsi mieux comprendre les problème engendrés.logo_mysql

Mais les explications pour modifier cette variable ou vérifier qu’elle est sa valeur actuelle ne sont pas forcément fournies au même endroit. Je vous livre donc ici, la marche à suivre complète …

Continuer la lecture de Problème de case des noms de tables MySQL

Sajax et l’URL Rewritting

Re-bonjour, voici le 2ième « hacks » pour Sajax (voir mon précédent post sur Sajax et les Cookies).

Alors soyons cours mais efficace.

Sajax appel ses requêtes asynchrones par l’adresse courante de la page.

exemple :

Si nous sommes sur la page index.php, les requêtes auront pour adresse :

http://www.bisiere.fr/index.php?rs=nom_de_la_fonction&rst=&rsrnd=1220887954407&rsargs[]=arg1&rsargs[]=arg2

Le problème s’impose lorsque l’on souhaite utiliser l’URL Rewritting et accéder à la page index.php via l’adresse :

http://www.bisiere.fr/home

ce qui nous donnera une « requête Sajax » vers cette adresse :

http://www.bisiere.fr/home?rs=nom_de_la_fonction&rst=&rsrnd=1220887954407&rsargs[]=arg1&rsargs[]=arg2

Et au mieux, vous aurez en retour de cette requête la page Html elle même (sans intérêt donc) sinon une erreur.

Le problème se situe dans la fonction sajax_get_my_uri() servant à récupérer l’adresse courante.

Continuer la lecture de Sajax et l’URL Rewritting

Sajax et les Cookies

Bonjour à tous, aujourd’hui je vous propose deux « hacks » pour Sajax (Simple Ajax Toolkit).

Un problème se pose lors de l’utilisation d’un script appelé via une XMLHttpRequest de Sajax (requêtes dites « asynchrones ») qui exécute un enregistrement de cookie :

function vote_cookie($id) {
	setcookie("MonCookie", $id, time() + 86400);
}

Dans notre cas, impossible de faire marcher ce script car à chaque appel nous avons droit à cette erreur :

Warning:  Cannot modify header information - headers already sent...

Continuer la lecture de Sajax et les Cookies

Installation d’un serveur Ubuntu 9.04 64bits virtualisé via VirtualBox pour le développement d’applications Java / Flex.

Bonjour à tous,

GlassFish Logo

pré-requis pour lire cette documentation :

  • Aimer Java / Flex
  • Aimer coder
  • Détester les admins sys

Introduction

Cette documentation a pour objectif de reprendre pas à pas l’installation d’un serveur Ubuntu 9.04 64bits. Nous qualifierons ce serveur de pre-prod car son but est de supporter la mise en béta test de nos applications. De plus ce serveur sera vitualisé via VirtualBox.

Le tutorial débute après l’installation de Ubuntu Server 9.04 64bits. Lors de cette installation aucun service n’a été pré-installé.

Continuer la lecture de Installation d’un serveur Ubuntu 9.04 64bits virtualisé via VirtualBox pour le développement d’applications Java / Flex.