Mostrando entradas con la etiqueta informatica. Mostrar todas las entradas
Mostrando entradas con la etiqueta informatica. Mostrar todas las entradas

martes, agosto 02, 2011

Denuncia admitida contra Oracle II



Nota de prensa de la Comisión Nacional de la Competencia:



¿De qué le acusan? Del Artº 2 de la Ley 15/2007: ABUSO DE POSICIÓN DOMINANTE.


1. Queda prohibida la explotación abusiva por una o varias empresas de su posición de dominio en todo o en parte del mercado nacional.

2. El abuso podrá consistir, en particular, en:

La imposición, de forma directa o indirecta, de precios u otras condiciones comerciales o de servicios no equitativos.

La limitación de la producción, la distribución o el desarrollo técnico en perjuicio injustificado de las empresas o de los consumidores.

La negativa injustificada a satisfacer las demandas de compra de productos o de prestación de servicios.

La aplicación, en las relaciones comerciales o de servicios, de condiciones desiguales para prestaciones equivalentes, que coloque a unos competidores en situación desventajosa frente a otros.

La subordinación de la celebración de contratos a la aceptación de prestaciones suplementarias que, por su naturaleza o con arreglo a los usos de comercio no guarden relación con el objeto de dichos contratos.

3. La prohibición prevista en el presente artículo se aplicará en los casos en los que la posición de dominio en el mercado de una o varias empresas haya sido establecida por disposición legal.

Saludos.

lunes, agosto 01, 2011

Denuncia admitida contra ORACLE


Ya adelantaba el pasado 5 de abril que "Empieza la siguiente guerra informática".

La noticia es que la Comisión Nacional de la Competencia (CNC) ha decidido incoar la denuncia contra ORACLE por posibles prácticas abusivas.

Podéis leer más detalles en el diario económico "cinco días": http://www.cincodias.com/articulo/empresas/cnc-abre-expediente-oracle-posibles-practicas-abusivas/20110730cdscdiemp_2/

Saludos.

miércoles, septiembre 08, 2010

Para la reflexión

Esto lo escribí muy probablemente en 1994 en un libro con el título "Virus informáticos" de G. González.

Estoy repasando la historia de los virus de la pelotita y el viernes13 para una charla, y me pareció un cita interesante entonces, y también ahora 16 años después:

"LAS APLICACIONES QUE HOY TIENE LOS ORDENADORES SON FASCINANTES. QUIÉN SABE SI LAS DE MAÑANA NO TRASCENDERÁN LITERALMENTE DE NUESTRA COMPRENSIÓN".

La cita aparece en la edición en castellano en "Alianza Editorial", aunque el original inglés es "The Penguin Computing Book".

Los autores: Susan Curran y Ray Curnow.

Saludos.

martes, febrero 02, 2010

Z520 vs N270


Mi amiga Bo necesita un portátil a ser posible ligerito porque viaja mucho. Me pregunta por dos modelos concretos. Voy a darle el consejito, pero por supuesto se admiten sugerencias.

Ha mirado un poco lo que hay y le gustan dos modelos (que conste que a mí no me gustan tan pequeñitos):

1.-ASUS EEE PC 1001 HA. Me dice que viene con Windows 7 y cuesta 269 euros.
2.-ACER ASPIRE ONE 751. No me dice el S.O., aunque en el enlace que me ha enviado pone que Windows XP Home Edition. Bo me indica que la diferencia con el anterior son 30 euros, pero no me dice si más barato o más caro :-(

Esto es lo que dicen las cifras:

Pantalla Asus: 10,1 pulgadas.
Pantalla Acer: 11,6 pulgadas.

Peso Asus: <>
Peso Acer: 1,25-1,35 kg dependiendo de la batería que lleve.

Procesador y placa Asus: Intel Atom N270 de 1.6 GHz.
Procesador y placa Acer: Intel Atom Z520.

Disco duro Asus: 160 Gb.
Disco duro Acer: 160 Gb.

Memoria Asus: 1024 Mb DDR2.
Memoria Acer: DDR2 667/800 MHz 1Gb.

La chuleta para comparar los procesadores: http://ark.intel.com/ProductCollection.aspx?familyID=29035

Viendo estos datos yo te diría esto, Bo:

1.-La pantalla del Acer es mayor. No sé si esto es mejor o peor para tí. Mirando las medidas veo que el Acer es más ancho y largo, pero algo más fino que el Asus (muy muy poco).

2.-El procesador del Asus (N270) es ligeramente diferente al del Acer (Z520) y tienes que entender las diferencias para elegir el que prefieras.

  • En principio son de la misma fecha (2008).
  • Los dos tienen 1 core (nucleo) y 2 threads.
  • El Z520 funciona a 1,33 GHz en lugar de los 1,6 GHz del N270. Esto confunde un poco a la gente que puede pensar que el Z520 es inferior. Digamos que la ventaja de que funcione con una frecuencia menor es que consume menos watios y por lo tanto se calienta menos y las baterías duran más.
  • El Z520 trabajo con menos voltaje (0,75-1,1) que el N270 (0,9-1,1625).
  • Los dos incorporan tecnología Hyper-threading.
  • El Z520 incorpora Virtualization Technology (VT-x) y el N270 no. Esto a ti te da igual, pero para un informático puede ser importante. Aquí hay una lista de programas "especiales" que requieren el Intel VT o AMD-V.
  • El Z520 tiene "Idle States" y el N270 no. Esto sí te puede interesar cuando tiras de batería y el PC está bastante tiempo con poco uso. Se trata de entrar en la BIOS del aparato y activar un estado de bajo consumo. Me imagino que el procesador "tirará" menos, pero la batería durará más.
  • El z520 tiene una cosa llamada "Intel Demand Based Switching" y el N270 no. No creo que lo vayas a utilizar. Se trata de forzar por software una mayor frecuencia de reloj para mejorar el rendimiento del procesador. Lógicamente aumentarías el consumo.
3.-Con estas cosas que te he dicho creo que te estarás decantando por el Acer, pero tienes que tener en cuenta la última cosa: A mí me daría igual si no tuviera Sistema Operativo, si trajera un Linux, si viniera con XP, Vista,... Pero si vas a comprarlo con Windows creo que a estas alturas deberías elegir algo con el 7.

El Asus me decías que venía con Windows 7, pero en el enlace que me has pasado el Acer viene con XP. No creo que cueste mucho encontrarlo actualizado.

Saludos, y ahora sí, me tienes que decir que pone en el letrero Chino ese que me has regalado.

martes, septiembre 01, 2009

¿Hay algo peor que un monopolio?

Nota: En este post hago referencia al euskera, pero puedes hacerlo extensivo a cualquier otro idioma marginado por Apple (unos 6.700 idiomas).

La respuesta al titulo de este post es que Sí. Es el abuso. Todo el mundo conoce las 4 libertades del software, pero es que hay software que además de no darte esas libertades te imponen absurdas prohibiciones.

En las navidades del año pasado entró en mi casa un mac mini. La experiencia ha sido positiva en general. Con software suficiente de serie, programas sencillos pero muy prácticos como el iphoto, el iMovie, etc. todo ello a un precio asequible (unos 450 euros).

Ahora bien, en el trabajo he instalado un equipo de sobremesa Debian en euskera. Mi antiguo Ubuntu de casa estaba en euskera. Mi XP del trabajo también en euskera.
Ahora tenía ganas de poner utilizar el Mac OSX en euskera en lugar de castellano. Sin más. Porque me apetecía.

La sorpresa es que no hay opción de Mac OSX en euskera. Tampoco lo hay si me actualizo al nuevo SnowLeopard 10.6 y seguramente no lo habrá nunca por los siglos de los siglos.

Después de constatar el hecho me puse a buscar. Es habitual que no puedas elegir el idioma que te de la gana, pero puede haber algún grupo de usuarios que haya dedicado su valioso tiempo en hacer ese trabajo que el fabricante no ha realizado.

Pues esos usuarios voluntariosos existieron e hicieron un gran trabajo desarrollando un parche que traducía un programa concreto al euskera. Publicaron en la web su trabajo y ¿Qué ocurrio?

Les llegó una carta de Apple diciendo que no podían hacer eso y que lo quitaran inmediatamente. Después de la primera hubo una segunda y el proyecto se abandonó.


También se retransmitió en ETB1 (está en euskera).


No sólo es el euskera. Mac OSX se distribuye sólo en 15 idiomas. A comunidades de hablantes amplias como el Catalán también se les prohibe hacer labores de localización:

Otros bloggers también han recogido el testigo y explican el tema:

Y respecto al futuro, estos idiomas no entran en los planes de Apple:

¿El Sistema Operativo más avanzado del mundo?

Es lo que dice Apple, pero la realidad es que parece mucho más avanzado cualquier proyecto software libre con su especial habilidad para lograr productos multilingües.

Incluso el software propietario tiende a tener en cuenta lenguas minoritarias como por ejemplo:

Microsoft
Ha desarrollado interfaces en euskera para múltiples paquetes como por ejemplo Windows XP.

Microsoft fue premiado, ya que hizo las localizaciones de forma totalmente gratuita y desinteresada:



Adobe: Ha realizado el esfuerzo de poner el Reader en euskera.

Google:
Tradujo GMAIL al euskera:

Apple tendría que darse cuenta de que todo no se mide en dinero, y que aunque fuera así, y no pudiera asumir un coste tan grande, otra gente le estaba haciendo el trabajo gratis.

Además, la Legislación se va adaptando, como la Ley 11/2007, de acceso electrónico de los ciudadanos a los Servicios Públicos. Este tipo de Leyes pretende garantizar el derecho a los ciudadanos a utilizar entre otras cosas la lengua oficial que le de la gana cuando va a una biblioteca, al colegio, a su trabajo de funcionario, etc.

Les estaría bien empleado que su prohibición supusiera al final perdidas económicas y menor cuota de mercado.

Saludos.

domingo, agosto 30, 2009

El mayor enemigo del consumidor


Hola amig@s,

Llevo bastantes días sin escribir, pero es algo bastante justificado. Ya no veo la tele, y antes, con los anuncios, podía dedicar mucho más tiempo al blog. En lugar de estar sentado delante de la "caja tonta", ahora voy 40 minutos a correr y después leo. Así de sencillo, ese es todo el misterio.

Siguiendo con el tema anterior, el de los navegadores y exploradores gratuitos de los años 90, quiero explicar por qué productos gratuitos incorporados a Windows, puede perjudicar al consumidor.

Un argumento falaz que se emplea habitualmente en webs afines a Microsoft es decir: "Coñó, ahora resulta que quitar el Windows Media Player y el Explorer es beneficiar al consumidor. Lo que ocurre es que la Unión Europea quiere aprovecharse y recaudar unas pasta a Microsoft".

Leer tiene sus ventajas... Por ejemplo he conocido este bonito parrafillo del libro "Libertad de Elegir" de la pareja Milton y Rose Friedman. Milton ganó el premio novel de economía en 1976 y Rose era su mujer. Los dos han fallecido recientemente, Milton en 2006 y Rose en agosto de este año (2009).
"El peligro más importante para el consumidor es el monopolio, ya sea el privado o bien estatal.

Su protección más eficaz es la competencia libre a nivel nacional y la libertad de comercio a nivel mundial.

Se protege al consumidor de la explotación a que puede someterle un vendedor a quien pueda comprar y que está impaciente por venderle.

Las fuentes alternativas de oferta protegen al consumidor mucho más eficazmente que todos los Ralph Nader del mundo".


Conviente recordar que según wikipedia...

Ralph Nader (nacido el 27 de febrero de 1934) es un activista y abogado estadounidense que se opone al poder de las grandes corporaciones y ha trabajado durante décadas cuestiones de medio ambiente, los derechos del consumidor y asuntos pro-democracia. Nader también ha sido un fuerte crítico de la política exterior estadounidense, que él ve como corporativista, imperialista, y contraria a los valores fundamentales de la democracia y los derechos humanos.

Ya no me voy a extender mucho más. Todo está explicado en perfecto castellano en la página oficial de la Comisión Europea donde el 24 de marzo de 2004 sanciona por primera vez a Microsoft.

El texto completo lo tenéis aquí.

Por si algún día lo quitan lo pego en este mismo post:

Saludos.

TEXTO INTEGRO DE LA RESOLUCIÓN DE LA COMISIÓN EUROPEA:

Bruselas, 24 de marzo de 2004

La Comisión concluye la investigación sobre Microsoft, le impone medidas correctivas para que modifique su conducta y le aplica una multa.

La Comisión Europea, tras una investigación de cinco años, ha llegado a la conclusión de que Microsoft infringió la legislación de competencia de la Unión Europea utilizando su cuasi monopolio en el mercado de sistemas operativos (SO) para PC con el fin de afianzarse en los mercados de sistemas operativos para servidores de grupos de trabajo(1) y de reproductores multimedia(2). Al no haber cesado este comportamiento ilegal, la Comisión ha ordenado a Microsoft a que divulgue a sus competidores, en el plazo de 120 días, las interfaces(3) necesarias para que sus productos puedan 'dialogar' con el omnipresente SO Windows. También se exige a Microsoft que, en el plazo de 90 días, ofrezca una versión de su SO Windows sin Windows Media Player a los fabricantes de PC (o al venderlo directamente a los usuarios finales). Además, se impone una multa de 497 millones de € a Microsoft por abusar de su poder de mercado en la UE.

"Las empresas dominantes tienen la responsabilidad particular de garantizar que la forma de ejercer su actividad no obstaculiza la competencia basada en los méritos y no perjudica a los consumidores ni la innovación" ha declarado Mario Monti, Comisario europeo de competencia. "Esta decisión de hoy restablece las condiciones de competencia leal en los mercados afectados y fija unos principios claros para el futuro comportamiento de una empresa con una posición dominante tan sólida", añadió.

Tras una exhaustiva y amplia investigación de más de cinco años y tres pliegos de cargos(4), la Comisión ha tomado hoy la decisión de declarar que la empresa estadounidense de software Microsoft Corporation ha infringido las normas de competencia del Tratado de la UE al abusar de su cuasi monopolio(5) (artículo 82) en el ámbito de los sistemas operativos para PC.

Microsoft ha abusado de su poder de mercado restringiendo deliberadamente la interoperabilidad entre los PC Windows y los servidores de grupos de trabajo que de sus competidores y vinculando su Windows Media Player (WMP), un producto en el que había competencia, a su omnipresente sistema operativo Windows,

Esta conducta ilegal ha permitido a Microsoft conquistar una posición dominante en el mercado de sistemas operativos para grupos de trabajo, que forman el núcleo de las redes informáticas de las empresas. Además, la conducta de Microsoft ha debilitado considerablemente la competencia en el mercado de reproductores multimedia.

Esta situación abusiva ha frenado la innovación y ha perjudicado el proceso de competencia y a los consumidores, que en definitiva tienen menos elección y se enfrentan a precios más elevados.

Por todas estas prácticas abusivas, que se han producido durante cinco años y medio, la Comisión ha impuesto una multa de 497.2 millones de €.

Medidas correctivas

Con el fin de restablecer las condiciones de competencia leal, la Comisión ha impuesto las siguientes medidas correctivas:

Por lo que respecta a la interoperabilidad, se exige a Microsoft que en el plazo de 120 días divulgue la documentación completa y precisa sobre las interfaces que permita a los servidores para grupos de trabajo competidores garantizar una interoperabilidad total con los PC y servidores Windows. Ello permitirá a los vendedores de la competencia desarrollar productos que puedan competir en condiciones equitativas en el mercado de los sistemas operativos para servidores de grupos de trabajo. La información divulgada deberá actualizarse cada vez que Microsoft ponga en el mercado nuevas versiones de los correspondientes productos.

En la medida en que alguna información sobre las interfaces pueda estar protegida por la propiedad intelectual en el Espacio Económico Europeo(6), Microsoft estará autorizado a recibir una remuneración razonable. La orden de divulgación se refiere sólo a la documentación sobre las interfaces y no al código fuente de Windows ya que éste no es necesario para desarrollar productos interoperables.

Por lo que respecta a la vinculación, se exige a Microsoft a que, en el plazo de 90 días, ofrezca a los fabricantes de PC una versión de su sistema operativo Windows para PC clientes sin WMP. Esta medida que pone fin a la vinculación no significa que los consumidores vayan a recibir PC y sistemas operativos sin reproductores multimedia. La mayoría de los consumidores compran PC de fabricantes que ya han montado por su cuenta un conjunto de sistema operativo y reproductor multimedia. Gracias a la solución de la Comisión, la configuración de estos equipos reflejará lo que desean los consumidores y no lo que impone Microsoft.

Microsoft tendrá derecho a ofrecer una versión de su sistema operativo Windows para PC clientes con WMP. Sin embargo, Microsoft deberá abstenerse de utilizar cualquier tipo de medios comerciales, tecnológicos o contractuales que tuvieran como consecuencia hacer que la versión de Windows no vinculada sea menos atractiva o cuente con menos prestaciones. En concreto, no deberá ofrecer a los fabricantes de PC descuentos condicionados a la compra de Windows con WMP.

La Comisión considera que las medidas correctivas pondrán fin a las violaciones de las normativas antimonopolio, que son proporcionadas y que establecen principios claros para el futuro comportamiento de le empresa.

Para garantizar el cumplimiento efectivo y oportuno de esta decisión, la Comisión nombrará un administrador de supervisión que vigilará, entre otras cosas, que las divulgaciones de las interfaces de Microsoft sean completas y precisas y que las dos versiones de Windows sean equivalentes en términos de prestaciones.

Investigación

En diciembre de 1998, la empresa estadounidense Sun Microsystems, denunció que Microsoft no había querido suministrar la información sobre interfaces que necesitaba para desarrollar productos que pudieran "dialogar" correctamente con Windows y poder así competir en igualdad de condiciones en el mercado de sistemas operativos para servidores de grupos de trabajo.

La investigación de la Comisión reveló que Sun no era la única empresa a la que se había negado esta información y que esta negativa de Microsoft a divulgar información formaba parte de una estrategia más amplia pensada para expulsar del mercado a los competidores.

Microsoft podía relegar así a una posición secundaria la competencia en términos de fiabilidad, seguridad y rapidez, entre otros factores, y le garantizaba triunfar en el mercado. Como consecuencia, una gran mayoría de clientes informó a la Comisión que la no divulgación por parte de Microsoft de la información sobre las interfaces alteraba artificialmente su elección a favor de los productos servidor de Microsoft. Las respuestas a los estudios presentados por Microsoft confirmaban el vínculo existente entre la ventaja de la interoperabilidad que Microsoft se reservaba y sus crecientes cuotas de mercado.

En el año 2000, la Comisión amplió su investigación, por propia iniciativa, para analizar los efectos de la vinculación de Windows Media Player de Microsoft con su sistema operativo para PC Windows 2000.

Esta parte de la investigación llegó a la conclusión de que la omnipresencia de que se beneficiaba inmediatamente WMP como resultado de su vinculación al SO Windows PC reducía artificialmente los incentivos de las empresas de contenidos musicales, cinematográficos y multimedia, así como de quienes desarrollan software y suministran contenidos, para desarrollar sus ofertas de reproductores multimedia competitivos.

Como consecuencia, la vinculación del producto reproductor multimedia de Microsoft tenía como efecto cerrar el mercado a los competidores, reduciendo así la posibilidad de elección del consumidor, ya que los productos competidores se encontraban en una desventaja que no tenía que ver con su precio o calidad.

Los datos disponibles muestran ya una clara tendencia a favor de la tecnología WMP y Windows Media. Si no se hubiera producido la intervención de la Comisión, es probable que la vinculación de WMP a Windows hubiera hecho que el mercado se decantara definitivamente a favor de Microsoft. Ello le hubiera permitido controlar los mercados relacionados del sector multimedia digital, tales como la tecnología de codificación, software para la difusión de música por Internet y gestión de derechos digitales, etc.

En un aspecto más general, la Comisión teme que la vinculación que hace Microsoft de WMP sea un ejemplo de un modelo económico de rentabilidad más general que, dado el virtual monopolio de Microsoft sobre los sistemas operativos de PC, elimine la innovación y limite la posibilidad de elección de los consumidores en aquellas tecnologías en las que se puede suponer que Microsoft tenga interés y vincularlas a Windows en el futuro.

Nota para los redactores

La Comisión Europea hace cumplir las normas de competencia de la UE sobre las prácticas comerciales restrictivas y abusos de poder monopolístico para el conjunto de la Unión Europea cuando afectan al comercio transfronterizo y a la competencia.

La Comisión tiene capacidad para imponer cambios en el comportamiento de las empresas y aplicar multas por infracciones a la normativa antimonopolio de hasta el 10% de su volumen de negocios anual a nivel mundial.

Las decisiones de la Comisión se pueden recurrir ante el Tribunal Europeo de Primera Instancia de Luxemburgo.

(1) Se trata de sistemas operativos en los ordenadores centrales de redes que prestan servicios al personal de oficinas de todo el mundo en su trabajo cotidiano, como puede ser compartir ficheros e impresoras y gestionar la identidad de los usuarios.

(2) Un reproductor multimedia es un producto de software que puede reproducir contenidos de música y video por Internet.

(3) Las interfaces no afectan al código fuente de Windows ya que éste no es necesario para desarrollar productos interoperables. Las interfaces son las conexiones de acceso al código fuente gracias a las cuales los productos pueden dialogar entre sí.

(4) El pliego de cargos señala la apertura de una investigación formal, ya que la Comisión comunica sus cargos u objeciones a la empresa o empresas afectadas.

(5) Los sistemas operativos de Microsoft equipan a más del 95% de los ordenadores personales a nivel mundial.

(6) La Unión Europea más Noruega, Islandia y Liechtenstein.

domingo, julio 19, 2009

Casi mejor no tocar la afinidad

Hola a tod@s,
Por fin de vacaciones, pero antes de marchar de viaje me gustaría saber si lo que ocurrió con el programa C le ha pasado a más gente, y por qué.

Recordar que teníamos un programita que ejecutamos marcando la afinidad a un procesador concreto y tardó 11 segundos más que sin toquetear la afinidad.

Primero una pequeña aclaración que analizaremos otro día:
El ordenador que utilicé en esas pruebas es un ADM Phenon x3, el cual tiene un único procesador con 3 cores (o nucleos en castellano). Windows nos dirá que hay tres procesadores y que podemos determinar la afinidad para forzar la ejecución en los procesadores que queramos, pero sólo hay un procesador y los núcleos comparten ancho de banda en el acceso a la caché L3 (memoria compartida por todos los cores). La caché L2 es la memoria que tiene cada core.

Bueno, ahora vamos a leer lo que otro (Iñaki Ayucar) ha analizado:

Artículo original en inglés: http://www.codeproject.com/Articles/35679/Parallel-computing-and-processor-affinity-Never-underestimate-the-Windows-Vista-Scheduler.aspx?display=PrintAll

Y en castellano: http://graphicdna.blogspot.com/2009/01/programacion-paralela-y-processor.html

¿Cual es el resumen?

1.-Al menos habría que abril un hilo por core físico en la máquina. Ya, pero el programa no es mio y el autor metió programación paralelizada en el programa original Fortran, pero no en el C. Esto será una mejora para el después de vacaciones.

2.-Este punto lo voy a poner tal cual está, porque lo explica de maravilla. El autor nos dice: "En un mundo ideal, una tarea simple, que no va a ser paralelizada más y que vive solita (no con las docenas de vecinos que un proceso tiene en un SO moderno), se gestiona mejor con una sola CPU, porque esto incrementa los aciertos de cache y elimina el consumo de la infraestructura de cambio entre hilos. Pero en la vida real, los procesos son interrumpidos por las operaciones del sistema, IO, otros procesos y muchas otras cosas. Una maquina multi-núcleo es perfecta para manejar todas esas interrupciones, porque puede repartirlas por los núcleos existentes, pero si comenzamos a fijar nuestras aplicaciones a CPUs específicas, la capacidad del sistema para evitar bloqueos y esperas se reduce considerablemente".

Uff, este punto número 2 lo podemos separar en otros cuantos:

2.1.-Cuidado, porque puede ocurrir que la ejecución en tu viejo portátil con una CPU pueda ir mejor, ya que hay más aciertos de cache y hay menor consumo por cambio de hilos.

2.2.-El hecho de que hay un montonazo de procesos extra en ejecución con sus respectivas interrupciones, etc. etc. da pie a que en tu nuevo pc multinucleo la cosa funcione mejor.

2.3.-En el caso de que estemos en nuestro pc nuevo multinucleo, fijar las CPU-s puede perjudicar ya que el sistema tiene menos opciones para evitar los bloqueos, esperas, etc.

En el artículo pasa a describir el tema de cómo fijar la afinidad y luego viene lo interesante:

Las pruebas:

Las pruebas se componen por 5 partes:

Parte I: Programa NO multihilo (como el nuestro).
Si se establece la afinidad el programa tarda 28 segundos más que si no se hace nada.
Mejor dejar hacer a Windows.

Parte II: Dos hilos de ejecución (principal + secundario con algún cálculo).
El programa tarda 3 segundos menos si no se establece la afinidad.
Mejor dejar hacer a Windows.

Parte III: Tres hilos de ejecución (principal + dos hilos de cálculo).
El programa tarda 2 segundos menos si no se establece la afinidad.
Mejor dejar hacer a Windows.

Parte IV: Cinco hilos de ejecución (principal + cuatro hilos de cálculo).
Empate técnico (bueno, por décimas gana la afinidad).
Windows ha perdido por la mínima.

Parte V: Nueve hilos de ejecución (principal + ocho hilos de cálculo).
El programa tarda 3 segundos menos si no se establece la afinidad.
Mejor dejar hacer a Windows.

Los resultados cuadran totalmente con lo que nos ocurría en el programita.

Parece que cuando la programación es multihilo es mejor no tocar la afinidad, aunque la diferencia es pequeña. Lo que está claro es que si el programa no es multihilo hay grandes diferencias en tiempo de ejecución siendo más rápido sin tocar la afinidad.

Saludos.

lunes, julio 13, 2009

Siguiendo los consejos recibidos el otro día la semana pasada hice la prueba de ejecución "con afinidad".

No fijé la afinidad por programación. Simplemente lancé la ejecución, y a toda leche modifiqué la afinidad con el Administrador de tareas de Windows.

Estoy con mi viejo portátil con un solo procesador por lo que no os puedo enseñar la opción, pero la explico...



Ahí arriba está el Administrador de tareas. He pinchado en una tarea y tengo opción de subir o bajar la prioridad de un proceso.

Si tuviera más de un procesador, debajo de la opción de prioridad tendríamos algo así como "afinidad". Al pinchar aparecen un check box donde podemos elegir uno o varios procesadores. Yo elegí el procesador 0.

Así fue la ejecución:

El PC estaba ligerito de trabajo:


Lanzo el proceso, pongo en marcha el cronometro y establezco la afinidad:

En la imagen de arriba ya se ve que un procesador se pone al 100% mientras que los otros dos prácticamente vuelven a la situación inicial.

Al final termina el proceso y todo vuelve a su ser:


Ahora lo importante, ¿qué ha pasado con el tiempo de ejecución?

Pues ha tardado 18 minutos 42 segundos. Once segundos más que sin tocar la afinidad.

Creo que vamos a tener que enterarnos de la forma de funcionamiento de estos procesadores AMD64 para entender algo.

Saludos.

lunes, julio 06, 2009

Could faster chips translate into slower computers?

Ya que el otro día mejoramos la ejecución en el super PC-1 (18 minutos 31 segundos), se me ha ocurrido compilar y ejecutar el programa Visual C++ en mi viejo portátil.

Con el Dev C++ sin optimizar tardaba 21 minutos 9 segundos y tenía curiosidad por saber lo que iba a mejorar.

Han sido ni más ni menos 14 minutos 20 segundos, lo que significa que ¿es la máquina más rápida? ¡Imposible!

Algo raro está ocurriendo... el resultado no es lógico, o tal vez sí...

Así es la utilización de la CPU al comenzar la ejecución. 100% de uso del único procesador hasta el final.



Y así la relajación final:


El AMD64 es multinucleo y se comporta diferente. El XP lo ve como si fueran 3 procesadores. El caso es que el uso de la CPU se mantiene bastante constante en un 34% de uso.


Cuando termina:


Esto hay que estudiarlo un poco pero el punto de partida puede ser este:

Could faster chips translate into slower computers?

Esta es la pregunta que se hicieron en este artículo de la revista Fortune e indica una posibilidad que puede estar ocurriendo, o tal vez no.

Saludos.

jueves, julio 02, 2009

Prueba con Visual C++

Seguimos con el programa de generación del primo más grande (del año 1994).

Hicimos una prueba de compilación con Dev C++ en un PC decente. El resultado fue un poco decepcionante porque los 27 minutos que tardaba eran 6 minutos más que en un viejo portátil XP.

Es verdad que no me preocupé demasiado por ajustar los parámetros del compilador. Pero he preferido pasar directamente al compilador comercial por excelencia de Windows XP: Visual C++.

1.-Instalo Visual Studio 2005 (en los próximos días probaremos el Visual Studio 2008).

2.-Iniciamos un nuevo proyecto Visual Studio. Seleccionamos el lenguaje Visual C++ y "Aplicación de consola Win32"



3.-Así tendremos el proyecto vacío:


4.-Añado el programa C original de Slowinski y lo adapto ligeramente para el Visual C++. Concretamente hay que:
  • Modificar la sintaxis de main().
  • Comentar las líneas para el control de tiempos.
  • Comentar la cabecera que Visual C++ ha añadido por defecto: stdafx.h
  • Añadir la cabecera stdlib.h para poder usar la función atoi.

Al final de este post añado el código fuente entero para el que lo quiera probar.

5.-Lanzamos la compilación-ejecución y a esperar. En total ha tardado 23 minutos 45 segundos. Mejor que el Dev C++ pero un resultado bastante pobre. Ahora toca hacer unos pequeños ajustes.

6.-Priorizamos el rendimiento frente al tamaño del ejecutable:

Para ello vamos al Menú Proyecto, propiedades del proyecto, propiedades de configuración, C/C++, Entramos en la sección "Optimización" y seleccionamos "Maximizar velocidad" que se corresponde con la opción /O2.



Ahora intentamos la compilación y...SORPRESA. Se produce un error que dice lo siguiente: "las opciones de líneas de comandos '/O2' y '/RTC1' son incompatibles".


Bueno, pues hay que volver a Proyecto, propiedades del proyecto, propiedades de configuración, C/C++, General. Vamos a "formato de la información de depuración" y seleccionamos "Deshabilitado".

Además de esto, también hay que ir a C/C++, Generación de Código, "Comprobaciones básicas en tiempo de ejecución" y marcarlo como PREDETERMINADO.



Pues aunque volvamos a intentar compilar nos sale un nuevo error: '/Gm' requiere '/Zi' o '/ZI'.


Jeje, ya estaremos un poco aburridos tanto toquetear, pero esta es la última vez (de momento). Volvemos a Proyecto, propiedades del proyecto, propiedades de configuración, C/C++, Generación de código. Vamos a "habilitar regeneración mínima" y ponemos que NO.


7.-Ahora sí, ya podemos compilar y ejecutar tranquilamente. Y el rendimiento mejora bastante. El programa tarda ahora 18 minutos 31 segundos. Nuevo record, aunque todavía insuficiente.

Saludos.

Ahora el código fuente... (cuidado, algunos símbolos se han podido modificar. Cosas de blogger):


// Programa visualizador. 2009-07-02.

//#include "stdafx.h"

#include
#include
#include
#include

//Para que funcione la función atoi es necesario incluir stdlib.h.
#include

// Pequeña modificación en main:
//main(argc, argv)
//int argc;
//char *argv[];

int main(int argc, char* argv[])
{
#define EXP 859433 /* will calculate 2^859433 - 1, the 33rd Mersenne prime */
//Quitamos el cálculo de tiempos:
//double t, ftp0, ftp1;
double c0 = 0, c1 = 0, c2 = 0;
int n;
int *a, *b, *c;
int ddigit = 4; /* number decimal digits per part */
int vdig = (int)pow((double)10, (double)ddigit); /* decimal value of part */
int i, j, k, maxpart, mx;
unsigned int size;
char format[64];

n = EXP;
if (argc == 2) /* command-line param for new n? */
n = (atoi(argv[1]) > 0) ? atoi(argv[1]) : EXP;
printf("calculating 2^%d - 1\n", n);

size = (n+1)*sizeof(int);
printf ("allocating %d bytes for working arrays\n", 3*size);

if ((a = (int *)malloc(size)) == NULL) {
fprintf(stderr, "cannot allocate %d bytes for a\n", size);
exit(1);
}
if ((b = (int *)malloc(size)) == NULL) {
fprintf(stderr, "cannot allocate %d bytes for b\n", size);
exit(1);
}
if ((c = (int *)malloc(size)) == NULL) {
fprintf(stderr, "cannot allocate %d bytes for c\n", size);
exit(1);
}

for (i = 1; i <= n; i++) { a[i] = 0; /* set results array to null */ b[i] = 2; /* load up multiplicand array with n 2s */ c[i] = 0; /* set carry array to null */ } a[1] = 1; /* set initial intermediate result to 1 */ mx = 1; //#ifdef FTIME // ftime(&tp0); //#else // gettimeofday (&tp0, (struct timezone *)NULL); //#endif //#pragma _CRI parallel shared(n, a, b, c, mx, vdig) private(i, j) for (j = 1; j <= n; j++) { //#pragma _CRI taskloop vector for (i = 1; i <= mx; i++) { a[i] *= b[j]; } //#pragma _CRI taskloop vector for (i = 2; i <= mx+1; i++) c[i] = a[i-1]/vdig; //#pragma _CRI guard if (c[mx+1] > 0)
mx++;
//#pragma _CRI endguard

//#pragma _CRI taskloop vector
for (i = 1; i <= mx; i++) { a[i] = (a[i] % vdig) + c[i]; } } //#pragma _CRI endparallel /* propogate carry through one last time */ j = 0; for (i = 1; i <= n; i++) { k = a[i] + j; a[i] = k % vdig; j = k/vdig; } //#ifdef FTIME //ftime(&tp1); //ftp0 = (double)tp0.time+(double)tp0.millitm/(double)1000000; //ftp1 = (double)tp1.time+(double)tp1.millitm/(double)1000000; //#else //gettimeofday (&tp1, (struct timezone *)NULL); //ftp0 = (double)tp0.tv_sec+(double)tp0.tv_usec/(double)1000000; //ftp1 = (double)tp1.tv_sec+(double)tp1.tv_usec/(double)1000000; //#endif //t = (ftp1-ftp0 == 0) ? 0.000001 : ftp1-ftp0; //printf("wall time for main loop: %.5lf seconds\n", t); maxpart = 0; for (i = 0; i <= n; i++) if (a[i] != 0) maxpart = i; printf ("max parts used: %d (each part is %d decimal digits)\n", maxpart, ddigit); /* subtract one from answer and see if we match Slow's number */ a[1]--; if (a[1] < i =" 2;" j =" 0;" i =" maxpart;">= 1; i--) {
printf (format, a[i]);
j++;
if (j % 15 == 0)
printf ("\n");
}
printf ("\n");

return 0;
}

lunes, junio 29, 2009

Pequeña decepción

Os comento la prueba que quería hacer esta tarde.

Tenía dos equipos idénticos. Dos PC-s que le dan mil vueltas a este portátil en el que estoy escribiendo. Voy a poner unos datos para verlo:

1.-Portátil donde realicé la prueba del visualizador.exe:

2.-PC1 y PC2:

  • AMD Phenom X3 64.
  • HP Compaq DC5850.
  • Triple-Core Processor
  • 2,29 GHz,
  • 3,23 Gb Ram.

El PC1 tenía XP instalado y ahí he instalado el Dev C++ 5.0 beta 9.2 con el compilador Mingw/GCC 3.4.2

En el PC2 tenía Ubuntu 9.04 que trae instalado un compilador FORTRAN.

La idea era esa... Compilar el programa C en PC1 y el equivalente FORTRAN en PC2, comparar y quedarnos con el más rápido. Aquí están los dos enlaces a los programas

El problema ha sido que la ejecución en el programa C recién compilado en el super PC1 ha tardado 27 minutos 05 segundos. Cuando el mismo programa en el viejo portátil tardaba 21 minutos 09 segundos.

¿¿¿¿¿??????
¿Los viejos cacharros son mejores? No.
¿Windows XP no es capaz de sacar provecho de la máquina? Tampoco.

No, no es nada de eso. Tiene más que ver con el compilador, más concretamente si es capaz de utilizar los recursos de la máquina, o los está infrautilizando.

El Dev C++ 5.0, tal y como lo descargas lleva debajo el compilador MinGw 3.4.2. Realmente la última versión disponible es la 5.1.4 como se puede ver en http://sourceforge.net/project/showfiles.php?group_id=2435

Ahora lo que toca es buscar el mejor compilador C posible para el AMD64 con Windows.

Saludos.

lunes, marzo 09, 2009

Reflexión compartida

Artículo interesante este de Fernando Acero publicado en Kriptópolis.

Es verdad que la piratería perjudica tanto software privativo o comercial (no quiero entrar en esta guerra de términos), como al software libre, aunque yo matizaría que... No perjudican en igual medida a todos.

Tenemos que tener en cuenta que cuando se piratea un producto "comercial" se le perjudica al desarrollador en una medida cuantificable como es el precio de la licencia.

Pero todos los productos no son iguales y hay algunos que se ven favorecidos si un porcentaje mayoritario de usuarios lo utiliza (sea o no software pirateado).

Estoy pensando en Sistemas operativos y suites ofimáticas cuyo pirateo, siempre que se mantenga en un nivel bajo, perjudica más al software libre que al fabricante, que deja fuera de juego a otros competidores "comerciales".

Si en lugar de piratear el S.O. los usuarios se dedican a piratear programas que corren en ese S.O. entonces ya la jugada es maestra.

Si te llama un amigo para que le instales algo "comercial", pídele la licencia, y si no está dispuesto a pagar por él, ofrécele el software libre equivalente.

Saludos.

jueves, diciembre 11, 2008

Para terminar con el Ariane

Anteayer vimos una pequeña introducción sobre el caso Ariane-5.

Ayer hice un resumen del resumen del informe sobre lo ocurrido.

Hoy espero aclarar las dudas que pueda haber sobre el tema de las excepciones.

En Visual Basic.NET tenemos unas cuantas funciones de conversión:



En el siguiente código visual basic se hace una conversión como la que pudo ocurrir en el momento previo de la explosión del cohete.

Tenemos una variable entera llamada i.
Y una variable doble llamada z.

Dim i As Integer
Dim z As Double
z = 4.354354387594386E+25
i = CInt(z)

En Visual Basic, igual que en Ada (lenguaje utilizado en el Ariane-5) la variable z contiene un valor demasiado grande para que pueda convertirse al tipo entero. Lógicamente esto provocará un error.

Igual que en el caso del cohete Ariane, hemos introducido captura de excepciones, lo que ocurre es que no se capturan todas.

Try

Dim i As Integer
Dim z As Double
Dim streamEscritura As New System.IO.StreamWriter("c:\temp\dato.txt")

z = 4.354354387594386E+25
i = CInt(z)

streamEscritura.WriteLine(CStr(i))
streamEscritura.Close()

Catch ioe As System.IO.IOException
MsgBox("c:\temp no existe")

Catch se As System.Security.SecurityException
MsgBox("Acceso denegado.")

End Try

El programita después de la conversión imposible va a intentar escribir el resultado en un fichero de texto. Hemos capturado la excepción de "Error de Entrada/Salida" y la de "Seguridad". Veamos lo que ocurre:



Se ha producido un error "Overflow Exception" y la ejecución del programa se ha interrumpido. Esto es lo que ocurrió en el cohete.

La solución es evidente. Hay que capturar TODAS LAS EXCEPCIONES para que nunca se interrumpa de esa forma la captura de datos de los sensores. Si un valor es demasiado grande no debería ocurrir nada, se desecha el valor y el sensor ya nos enviará un nuevo dato.

En Visual Basic esto se hace con una captura de excepción genérica:

Catch ex As System.Exception
End Try



Bueno, la lección es la siguiente: Hay que pensar que siempre puede haber excepciones no previstas. Pensar la mejor forma de salir del error e implementarla en el lugar adecuado.

También es importante recordar que las conversiones de tipos suelen ser especialmente problemáticas.

Saludos.

miércoles, diciembre 10, 2008

El fallo informático más gordo

El Ariane-5 era algo más que la continuación de los anteriores. El diseño prácticamente era nuevo. La nueva lanzadera tiene dos secciones. La de abajo es la parte común para todas las misiones y la superior depende de la carga que se va a poner en órbita.

Las dimensiones, los motores, la fuerza de empuje, son datos impresionantes.

El 4 de junio de 1996, en su primer vuelo, la expectación fue enorme. Todo el mundo estaba observando. Despegó y a los 40 segundos, empieza a girar sobre si mismo hasta que explota.


A los pocos días se nombró una comisión de investigación formada por técnicos de diferentes países. Y esto fue lo que encontraron:

Datos de vuelo:

Hasta el segundo 42 tenían datos telemétricos remitidos a tierra, señales de radar e imágenes visuales.

1-Antes del despegue, todo normal.
2-Despegue, todo normal.
3-Hasta el segundo 36, todo normal.
4-Fallo del sistema de referencia inercial de reserva.
5-Fallo del sistema de referencia intercial activo.
6-La posición de las bocas de los propulsores y del motor van a la posición más extrema.
7-Autodestrucción de la lanzadera.

Con estos datos, ya vieron lo que falló: el sistema de referencia inercial.

Recogida de más datos:

La zona de despegue (Kourou, Guayana Francesa) estaba rodeada de árboles. La explosión fue sobre los 4.000 m. Los fragmentos se dispersaron a lo largo de 12 km cuadrados. Patearon toda la zona y encontraron los dos sistemas de referencia inerciales los cuales tenían datos valiosísimos que no se habían remitido a tierra. De esta forma se supo que primero falló el sistema de reserva y luego el principal.

El diseño

Lógicamente, lo primero que tenemos que saber es qué es eso del sistema de referencia inercial. Para decirlo con cuatro palabras. Parece un montón sensores (giroscopios láser y acelerómetros) conectados a un procesador. De esta forma se mide en todo momento el movimiento, orientación, velocidad, aceleración de la lanzadera.

Este sistema de referencia inercial provee de datos a la computadora de a bordo (sí, como los coches de ahora) a través de un bus de datos.

Esa computadora central tiene el programa de vuelo y va accionando las bocas de los propulsores, el motor, etc. por medio de elementos hidráulicos.

El hecho de que hubiera dos sistemas de referencia inerciales era para evitar el desastre en caso de que fallara el principal. El hardware y el software eran iguales. Como se suele decir ahora eran un activo pasivo y encargado de "switchear" es el computador de a bordo en caso de detectar algún fallo.

El computador de a bordo también estaba duplicado.

El fallo

La secuencia "marcha atrás" fue la siguiente:

  • A la velocidad que va el cohete y con una inclinación del 20 grados (y subiendo), los propulsores se separan. Eso hace que se active la autodestrucción.
  • Ese giro no planeado se produce porque las bocas de los propulsores y del motor se encuentran "a tope".
  • Estaban "a tope" porque así lo había ordenado la computadora de a bordo.
  • Los datos que cogió de referencia la computadora de a bordo eran los del sistema de referencia principal. No eran datos "buenos" pero los tomó como si lo fueran.
  • El sistema de referencia principal no enviaba datos "buenos" porque se había producido una excepción en el software.
  • Aunque había una excepción, el ordenador de a bordo no cambió al sistema de referencia secundario porque este había fallado antes que el principal. En el secundario se había producido la misma excepción.
  • La excepción se produjo en una conversión de datos de coma flotante (64 bits) a entero con signo (16 bits). Resulta que el número en coma flotante que se intentaba convertir no cabía en los 16 bits del entero. La excepción era un "Error de Operando". El código era Ada, y en esta parte del programa se habían tenido en cuenta otro tipo de errores de conversión, pero no el "Error de Operando".
Ya vemos el cariz que esta tomando esto, pero la realidad supera siempre a la ficción y lo que viene es flipante...

El módulo en el que ocurre el error es para una función de alineamiento que sólo es necesaria antes del despegue. Después del despegue ya no sirve para nada.

O sea, todo se fue al garete sin necesidad. Se trataba de un código que no debería estar ejecutándose.

La cosa es algo más complicada que eso. El Ariane-4 si que necesitaba esa función durante 50 segundos desde la activación del "modo de vuelo" de los sistemas de referencia inerciales. Esos 50 segundos se terminan sobre el segundo 40 desde el despegue. El Ariane-5 no necesitaba esa función en vuelo.
  • El Error de operando se produjo porque la función se encontró con un valor más alto de lo esperado. La variable está relacionada con la velocidad horizontal de la plataforma.
  • Era más alto que lo normal porque la trayectoria del Ariane-5 es diferente del Ariane-4 y lo que no era normal en el anterior sí era normal en el nuevo cohete.
00:30 a.m.
Hora de dormir.
Mañana continuo, porque en el informe se intenta justificar el motivo por el cual no se hicieron todas las comprobaciones necesarias. Decían que no se quería llegar al 80% de la capacidad de proceso del sistema de referencia inercial, pero algo huele mal si realmente estaban ejecutando código innecesario.

Saludos.

Fuente: http://www.upv.es/satelite/trabajos/pract_9/kike/paginas/accid.htm

martes, diciembre 09, 2008

¿Donde está el fallo?


Muy pocos recordaran el desastre del Ariane 5.

Es mucho más conocido lo ocurrido en 1986 con el Challenger. Por un lado, a diferencia del Ariane, éste era un vuelo tripulado. Además recuerdo que en aquel vuelo iba una civil (la primera civil en el espacio). Por si eso fuera poco, muchos vieron las imágenes en directo.

En la wikipedia hay un resumen y las posibles causas del accidente, así como detalles más o menos escabrosos como la posibilidad de que la causa de la muerte de los astronautas fuera el impacto con el océano. La falta de un sistema de eyección así como de paracaídas fue muy criticada y tuvo consecuencias para la NASA.

Hoy quiero hablar del Ariane ya que desde el principio se achacó el desastre a un "problema" informático.

En muchos sitios se habla del Ariane, al fin y al cabo es un cohete europeo con muchos años de vida, pero parece que se ha olvidado lo ocurrido en 1996. En la Wikipedia una simple oración lo recuerda, y en muchos sitios especializados ni mencionan aquel problema informático que originó una pérdida de millones de euros.

Ariane es una familia de cohetes europeos construidos por la Agencia Espacial Europea (ESA).
Esta agencia está formada por varios países. Entre otras misiones los Arianes se encargan de poner en órbita satélites.

El primer Ariane se lanzó en 1979. Tenía 47 metros de longitud y podía poner en órbita un satélite de unos 2.500 kg. En 1980 se encarga la construcción a la empresa Arianespace cuyo accionista mayoritario es el estado francés. Las diferentes series se van mejorando y se utilizan según necesidades. La serie 4 podía poner en órbita 4.400 kg.

En estas estamos cuando se llega a la serie 5. La decisión de una lanzadera-cohete más competitiva, con menores costes y mayor fiabilidad, la tomaron en 1987 los ministros de los estados miembros. El Ariane 5 podía poner en órbita 2 satélites de 3.000 kg cada uno, o uno solo de 6.800 kg. Puede transportar incluso vehículos tripulados.

Para el año 1996 se preparan los primeros dos vuelos de prueba: el ariane-501 (en mayo) y el ariane-502 (en otoño). Al final el vuelo 501 se lanza en junio y ocurre el gran desastre.

Al tratarse de un proyecto compartido entre varios países había que iniciar una investigación y hacer públicos los errores. El resultado muy sorprendente. Uno de los mayores fallos software de la historia en un sistema diseñado para que nada falle.

Este post ha resultado demasiado largo. Son las 00:43. Mañana el informe.

Saludos.