OpenCL... ¡lanzamiento!

Ayer mismo nVidia lanzó sus drivers con soporte para OpenCL. Sorprendentemente, de forma simultánea para windous y Linux!

OpenCL es el estándar del grupo Chronos para computación GPGPU, no sólo especializada en cálculo numérico sino también para programación de uso general. Supongo que por ser tan ambicioso, tardará en sustituir a CUDA, mucho más maduro a estas alturas. Aunque a la vez pienso que finalmente lo hará. Primero porque auna distintas técnicas de programación y, segundo y más importante, porque es el lenguaje que apoyan tanto fabricantes de GPUs, de ordenadores y desarrolladores de software importantes.

A la espera de la implementación de ATI de este estándar en sus drivers, ya son Apple--de forma nativa en su Snow Leopard--, Adobe en su potochop y ahora nVidia, las que están impulsándolo. Los de Phoronix ya han anunciado que cuando tengan los drivers de ATI definitivos, compararan ambas implementaciones... que les gusta hacer sangre, viciosillos.

En la página de descargas tenemos disponibles tanto los drivers (32 y 64 bits) como "profilers", documentación y ejemplos.

Al final me van a obligar a cambiar mi macbook con su integrada Intel...

GNU/Linux, el sistema más usado

Eso es lo que dicen las estadísticas, concretamente las de visitas a este blog...

Empuje

Thrust es el nuevo descubrimiento. Para los que desarrollamos en C++, CUDA se hace un poco cuesta arriba, demasiado parecido a C...

Esta biblioteca implementa algoritmos similares a la STL, con una sintaxis casi igual, pero con la ventaja de que se ejecutan en paralelo en nuestra GPU. Se tiene total control sobre la memoria del ordenador y la GPU, y el código es lo más legible que he visto para computación en gráficas.

Un ejemplo sencillo:

#include <thrust/host_vector.h>
#include <thrust/device_vector.h>
#include <thrust/generate.h>
#include <thrust/sort.h>
#include <thrust/copy.h>
#include <cstdlib>

int main(void)
{
  // generate 16M random numbers on the host
  thrust::host_vector<int> h_vec(1 << 24);
  thrust::generate(h_vec.begin(), h_vec.end(), rand);

  // transfer data to the device
  thrust::device_vector<int> d_vec = h_vec;

  // sort data on the device (145M keys per second on a GTX 280)
  thrust::sort(d_vec.begin(), d_vec.end());

  // transfer data back to host
  thrust::copy(d_vec.begin(), d_vec.end(), h_vec.begin());

  return 0;
}

Konichiwa!

De camino al Imperio del Sol Naciente, con un Macbook en el que sólo funciona Ubuntu. El Leopard petó. Me pregunto, ¿serán más frikis que yo? y lo que me anima es que sé la respuesta... ¡y me gusta!

Cula shaker

Uy que bien que estaba yo en la playita... bueno, al lío.

Creo que me estoy convirtiendo en el único desarrollador de CUDA que no ha programado una sola línea, jeje. La verdad es que ganas sobran pero tiempo falta. Aún así yo sigo al loro de las novedades por lo que pueda venir.



En este caso acabo de leer algo que puede hacerme dar el paso. Una empresa ha portado LAPACK a CUDA, añadiendo algunas cosillas más. La librería tiene el sesudo nombre de CULA. Trabaja tanto en simple con en doble precisión y dan el código libre en dos versiones. También tienen otra licencia para programas comerciales.

Pues eso, que ganas hay ya de darle un bocadito con LMX.

de particiones y compatibilidad

Qué razón tienen los que afirman que Apple compite contra M$ pero teme a Linux.

Windows será el malvado sistema que con calidad ínfima se apodera de la gente usando tácticas de dudosa ética... ejem... blablabla. Lo que sea, por la comunidad, porque los desarrolladores no ponen trabas o--muy probablemente--por ambas cosas; pero la compatibilidad de windows con linux es magnífica. Los sistemas de archivos se montan entre ambos con posibilidad de lectura y escritura usando drivers libres. Incluso las aplicaciones son cada vez más compatibles gracias a cygwin por un lado y a wine, mono o mingw por el otro. Y eso por no mentar las virtualizaciones.

Bueno, pues así de mal están las cosas con el malvado imperio de mocosoft... nada que ver por supuesto con nuestros colegas guays de la manzana:

• Intenta montar HFS+ en linux, podrás pero sólo para leer.
• Prueba a montar ext4 en el mac, upps no, demasiado moderno.
• Intenta montar ext2 ó ext3 en OS X... suerte, mucha suerte. Parece que con ext2fsx se podía... antes. Una de las actualizaciones de Leopard hizo que dejara de funcionar.
• Ah, que había una cosa que se llamaba FUSE, que nació en linux y han portado a mac. Pues con esas credenciales, seguro que es capaz de montar ext3 en espacio de usuario. ¿Seguro? pues no!
• Bueno, pues descartadas las opciones para compartir archivos entre ambos sistemas mediante formatos POSIX, probaremos suerte con los de windows... ¿NTFS? en linux sin problema pero, espera, en mac hay que instalar una extensión de FUSE que dice la gente que funciona. Vale, pues a mí no.
• ¿Y fat32? Ese maravilloso, moderno y potente estándar de sistemas de ficheros. Pues mira, con éste ha habido suerte. Claro que como mac es taaaaaan fácil, el botoncito para montar no funciona, sólo ha habido que tirar de la terminal, usar el comando "mount_msdos" y listo. El motivo, pues que a partir de la cuarta partición, la gui del OS X se hace la picha un lío.
  

Lo dicho, fácil, compatible y tremendamente intuitivo. Anda y que les den.

Problemas instalando Fink

He instalado un disco duro nuevo de 500GB al macbook. Realmente son 465GB, pero vamos, que no me faltará espacio.

Estoy intentando tener todas las aplicaciones de Linux nativas en mac para usar la virtualización lo mínimo posible (Salome-meca y poco más). Para ello necesito Fink, que ya lo tuve durante un tiempo pero me harté de los cambios de path entre qt3 de fink y qt4 de mac. Ahora, como fink tiene los binarios de qt4, cmake y todo lo que implique kde4, pues lo mismo uso sólo esos y me olvido de los nativos de mac.

Pero lo primero es instalar fink. Por algún motivo el instalador no me funcionaba, dándome un problema a la hora de seleccionar el disco de destino. El mesaje de error invoca un "índice 22" sin aportar más información. Por si acaso tiene que ver con los permisos, como recomiendan en las faq, me pongo a reparar permisos del disco y nada... hago lo del "sudo chmod 1755 /" y nada...

Así que sigo buscando por internet y me encuentro a un pollo que le pasa lo mismo. Solución a lo bestia, cambiar el contenido del script VolumeCheck (dentro del .pkg) para que siempre devuelva "0". Oye, pues de momento funciona. Si os interesa, seguid sus instrucciones aquí.