|
|
|
Secciones
Login Barrapunto
mig21 (7781)
reversethis-{moc.liamg} {ta} {pb12gim}
https://twitter.com/yapw
Hola, soy Miguel. Algo que pueda ser relevante aquí... Uhmm... Me gusta escribir en mi bitácora de BP [barrapunto.com] y en su clon en blogspot: Yet Another Programming Weblog [blogspot.com]
Me gustaría que Barrapunto fuese un sitio con más discusiones técnicas y trato de hacer lo que está en mi mano. De todos modos, también me gusta leer flames
No creo que te interese, pero en Lecturas aleatorias [blogspot.com] dejo registro de los libros que voy leyendo...
Esta es toda mi información de usuario
Publicidad
Publicidad
Programación funcional implícitamente paralela
Otra opción es que la paralelización sea implícita, que el lenguaje paralelize transparentemente las tareas y de como resultado una mejora de rendimiento sin el aumento de esfuerzo del programador. Esto ahora es ciencia-ficción en su aplicación práctica diaria, pero ¿se puede conseguir?
Vía Lambda the Ultimate me he encontrado con un debate en la lista de Haskell sobre este tema, aunque no demasiado optimista en general: "Implicit parallel functional programming". Se parte de la facilidad que en principio dan los lenguajes funcionales para paralelizar las tareas y se pregunta ¿es la hora de ese tipo de lenguajes? Un resumen, para mi clarificador,sobre el debate:
First, there is a claim that functional languages facilitate parallel execution, which is undeniably true if the implementation is something like that of Haskell (no assignment statements mean no memory contention, etc.).Then there is the claim that it is difficult (if not impossible) to analyze a piece of code and parallelize it optimally automatically, which is a point that was conceded long ago.
Third, there is the issue of whether "reasonable" parallelization can be obtained, and the answer to this problem is that it has been done before, and it can be done again. The open question is whether or not the parallelization thus achieved is sufficiently "good" in some sense.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Yo me apunto.
(Puntos:1)( Última bitácora: Viernes, 03 Febrero de 2012, 15:18h )
Lo que tambien quiero esplicitamente es reciclar lo que ya se, a ser posible :D
bueno bueno
(Puntos:1)( http://www.angelfire.com/co2/muzaraque/index.html | Última bitácora: Domingo, 02 Noviembre de 2008, 19:37h )
He oido ultimamente la palabra "paralelización" con mucha alegría. Todos sabemos que hay cosas que no se pueden paralelizar.
scanf("%d",a);
x=a+3;
y=x+x;
Y ahora que me digan como hacer que el resultado de y salga a la vez que el de x, que me lo digan.....estoy escuchando......
En pruebas que hice algunos años en laboratio, algoritmos muy paralelizables lograban realizar las tareas en un 75-80% menos de tiempo que un algoritmo secuencial. Pero como os he dicho, eran algoritmos muy paralelizables, en algoritmos aleatorios, quedaba reducido el tiempo de ejecución en torno a un 20-30%, poniendo una capacidad hardware de paralelizacin infinita (nada de 4 cpus, todas las que nos diera la gana). Así que bueno,si el experimento fue mas o menos aproximado, cuando ya parezca que no den mas de si los micros, aún podemos arañarles un 30% mas.
Un 30% mas no es despreciable, pero no es la octava maravilla del mundo, o al menos eso creo, os imaginais que desde los tiempos del 8086, cada año los micros hubiesen sido un 30% mas rapidos, me parece que todavía andaríamos por el 386. Además es una solución finita, cuando tengamos el procesador mas rápido, diremos "un 30% mas y se acabó"
He oido campanas sobre la computación cuántica, no se de que va, pero todos hemos oido cosas como que si un fotón, lo pones a correr mucho mucho (mas allá de la velocidad de la luz), llega al destino antes de que se pusiera a correr, ¿os parece suficientemente rápido?A mi sí. Esto que nos puede parecer un absurdo hoy, quizá no lo sea dentro de 15 años y tengamos una fuente para seguir mejorando las prestaciones....
Muzaraque