You are currently browsing the tag archive for the ‘compilador’ tag.

Los lenguajes de programación nos van a permitir escribir programas, es decir, escribir algoritmos en un lenguaje capaz de ser procesado por un computador.

Los lenguajes de programación son lenguajes y, por lo tanto, constan de un léxico, una sintaxis y una semántica.

El léxico es el conjunto de palabras que forman el lenguaje (en C++, por ejemplo, tenemos if, else, +, -, 2, 7.89, etc). La sintaxis es el conjunto de reglas que nos indican como construir frases (C++: if (i>0) { i--;}). La semántica es lo que dota de significado a cada una de esas frases.

Podemos clasificar los lenguajes de programación de diferentes maneras.

En función de su proximidad a la computadora, su arquitectura, o al programador, tenemos lenguajes de bajo nivel y lenguajes de alto nivel.

Los lenguajes de bajo nivel son muy cercanos a la arquitectura del computador (su juego de instrucciones) lo que los hace muy difíciles de programar a la vez que poco portables. Dos ejemplos son el lenguaje máquina (es en binario) y el ensamblador (se utilizan mnemotécnicos en lugar de secuencias de ceros y unos).

Los lenguajes de alto nivel son independientes de la arquitectura (basados en máquinas abstractas) y son mucho más próximos (en cuanto a léxico, sintaxis y semántica) a las personas. Todo esto los hace mas sencillos, flexibles y potentes. Sin embargo, como el computador no los entiende directamente, necesitamos de un traductor (interprete o compilador).

En función del paradigma, la filosofía que hay detrás, tenemos lenguajes de programación procedurales y lenguajes de programación declarativos. En los primeros se describe la secuencia de pasos para resolver el problema (COMO) mientras que en los segundos simplemente se describen los mismos (QUE). Para los primeros tenemos lenguajes imperativos (prima el procedimiento) y lenguajes orientados a objetos (prima el dato). Para los segundos tenemos los funcionales (funciones matemáticas) y los lógicos (predicados lógicos).

Finalmente, en función de si se traducen todas las sentencias de golpe para su posterior ejecución, compilados, o si se va traduciendo y ejecutando instrucción a instrucción, interpretados.

¿Qué elementos forman el léxico de un lenguaje? En primer lugar, las palabras reservadas: tienen un significado especial dentro del lenguaje, son sus instrucciones más básicas, y no se pueden utilizar para nada mas (listas para C#, C++ y Java). En segundo lugar, los símbolos, que pueden ser operadores (C++: =, +, -, …), delimitadores (C++: [, ], (, ), {,…), comentarios (C++: /* */, //) o directivas de preprocesado, que son ordenes especiales para el compilador (C++: #). En tercer lugar, los identificadores, que nos permiten dar nombres a constantes, variables y procedimientos (en C++ aparecen caracteres alfanuméricos, es decir, letras y números junto con el símbolo _. Han de empezar por una letra o por _ y se distinguen las mayúsculas de las minúsculas). Finalmente, tenemos los valores constantes: numéricos (3.56), carácter ('b') o cadena ("hola").

Las variables son “cajas” donde vamos a poder almacenar datos. El tipo de dato que almacenan va a ser fijo, pero el valor puede ser “variable”, de aquí su nombre. Estas cajas se corresponden con zonas de memoria accesibles mediante nombre. Se identifican con un nombre y tienen cuatro atributos: su tipo, su valor, su ámbito y su tiempo de vida. Con ella podemos consultar (indirección) su valor o modificarlo (asingación). En la mayoria de lenguajes se tienen que declarar (se fija el tipo y el nombre) antes de utilizarlas (C++: float a, b=1.2, c;).

Las constantes, a diferencia de las variables, almacenan un valor de un tipo que ya no se podrá modificar (C++: const double PI = 3.141592;). Ayudan a la legibilidad del programa, a su mantenimiento…

 

Anuncios

Ayer asistí al primer Friday’s miniWorkshop del IVICFA (L’institut Valencià d’Investigació Coorporativa de Física Avançada) que trataba sobre supercomputación y computación GRID. Forma parte de un ciclo de seminarios sobre “Fronteras de la Física” y contaba ayer, entre otros atractivos, con la apertura de los mismo por parte de Ian Bird, Project Leader of the Worldwide LHC Computing GRID (WLCG), con “Petabyte scale computing for the LHC”, o el seminario “Modeling complex solar magnetodynamical phenomena using supercomputing and visualization techniques” de Fernando Moreno Insertis, del Instituto de Astrofísica de Canarias (IAC) y PI of the European Solaire Network.

Aunque ya hicimos algunos comentarios en un post anterior, aprovechamos la ocasión para volver a hablar sobre estos temas y así aclararnos las ideas.

Un computador computa, por lo que un supercomputador supercomputa ;-). Como el elemento fundamental para computar en la arquitectura Von Neumann son las CPUs, en un supercomputador dispondremos de multiples de éstas. El otro elemento fundamental en la arquitectura Von Neumann, que es la que las convierte en máquinas de proposito general, es la memoria. En función de como las CPUs comparten esta memoria, nos encontramos con dos modelos de supercomputación: memoria compartida y memoria distribuida. Las dos interfaces que nos permiten programar en estos ambientes son OpenMP y MPI respectivamente.

Tenemos que aclarar que, cuando hablamos de supercomputación, nos estamos refiriendo a que estas entidades, múltiples procesadores y memorias, existen físicamente, pues podemos encontrarnos todos estos elementos de manera virtual en ordenadores mas sencillos con sistemas operativos multiproceso.

La última tendencia en arquitecturas paralelas son las arquitecturas vectoriales, arquitecturas SIMD: una instrucción múltiples datos, debido a su enorme desarrollo en la evolución de las tarjetas gráficas, que es donde aparecen de manera natural al tener que aplicar la misma operación a múltiples píxeles. CUDA es un estandar de facto en la extensión de estas operaciones a cualquier tipo de datos no necesariamente gráficos.

Por tanto, en el mundo de los supercomputadores actuales es fácil encontrarnos con arquitecutras paralelas heterogeneas en donde conviven simultanemente la memoria compartida con la memoria distribuida de múltiples unidades de proceso que soportan un juego de instrucciones vectorial. La paralelización de estos códigos se realiza ad-hoc, pero, al igual que sucedió con el triunfo de las arquitecturas RISC sobre las CISC, la última palabra es posible que la tengan los compiladores, aunque es un hecho objetivo que la paralelización automática es instrínsecamente muy compleja.

Un compilador, aunque se suele asociar a los traductores de lenguajes de alto nivel a lenguaje máquina, en realidad son traductores entre dos lenguajes, sean del tipo que sean, por lo que es totalmente lógico pensar en compiladores de programas secuenciales en un lenguaje determinado a programas paralelos heterogeneos en el mismo lenguaje. Mientras se programó en lenguaje máquina, las arquitecturas CISC dominaron el mercado. Con la aparición de los lenguajes de alto nivel y de compiladores potentes para los mismos que solo utilizaban un subconjunto muy reducido del amplísimo conjunto de instrucciones disponibles, entraron en escena las arquitecturas RISC y desplazaron a las primeros.

Por otra parte, ¿cúal es la propuesta del GRID computing? Pués su aparición es, al igual que por ejemplo los protocolos TCP/IP de Internet, una solución de facto a un problema existente y es, por una parte, el hecho de que existan en un momento determinado multitud de recursos repartidos a lo largo del planeta, y por otra, a la posibilidad de compartirlos de manera transparente por multitud de usuarios igualmente dispersos.

Por ejemplo, la realidad es que un grupo de la Universidad de las Palmas de Gran Canaria tiene un supercomputador fruto de sus necesidades en un determinado momento y otro grupo de la University of Tasmania tiene otro con los mismos recursos. Si en un momento dado se dan cuenta de que podrían compartir sus recursos, lo cual a priori siempre es positivo desde el punto de vista de la teoría de juegos, la tecnología grid ofrece una capa de abstracción, la middleware grid, gracias a la cual pasamos a tener un único sistema con el total de los recursos.

Pensando trivialmente, solo por aclarar ideas, y sabiendo que es un caso totalmente irreal, si ambas máquinas solo se utilizasen durante las ocho horas laborables locales, supongamos de 8h a 18h, obviamente los dos grupos salen muy beneficiados, pués con una diferencia horaria de 10 horas no habría conflictos de acceso y los dos pasarían a disponer del doble de recursos de los que tenían.

Por tanto, los supercomputadores existen y existirán, pues son la mejor solución a nivel local, pero la tecnología GRID, sin entrar en consideraciones sobre Cloud, es la mejor solución a nivel global, ya que permite la interconexión transparente de estos óptimos locales que pueden llegar a ser muy heterogéneos.

octubre 2019
L M X J V S D
« Oct    
 123456
78910111213
14151617181920
21222324252627
28293031  
Anuncios