ArchiTecnologia

Aprendizaje abierto. Conocimiento libre.

ArchiTecnologia
AsesoramientoElectrónicaHardware

Benchmark: todos los secretos de las pruebas de rendimiento

La prueba de rendimiento o benchmark es muy populares a la hora de evaluar el rendimiento del hardware. Los datos de rendimiento arrojados por ellas se usan como herramienta de marketing, pero no es oro todo lo que reluce. En muchas ocasiones, los resultados no se corresponden con la realidad…

Por tanto, el benchmarking se debe entender para determinar si estás ante un engaño para hacerte creer que un dispositivo rinde más que el de la competencia, o si te puedes fiar realmente de ellas…

¿Qué son los benchmark?

Raspberry Pi benchmark, comparación

Un banco de prueba, punto de referencia, o benchmark, como lo quieras llamar, no es más que un programa o conjunto de programas pensado especialmente para evaluar el rendimiento del sistema. Para ello se basa en una serie de operaciones que ejecuta para evaluar y comparar el rendimiento del componente en cuestión.

No solo pueden medir y comparar rendimiento, también se usan para consumo, rendimiento por vatio, latencia de memoria, ancho de banda de un bus o baudios, accesos de E/S, etc.

Para poder evaluar el rendimiento, estos programas suelen ejecutar una serie de operaciones esenciales o simular cargas de trabajo específicas que se darían en el mundo real. Por ejemplo, pueden simplemente ejecutar unos cálculos matemáticos y medir el tiempo que se tarda en obtener el resultado, o realizar compresiones de datos, codificación, y otras cosas habituales.

Las benchmarks más comunes suelen estar dirigidas para evaluar el rendimiento de la CPU, especialmente en operaciones con enteros y en coma flotante, así como para la GPU, la memoria RAM, los medios de almacenamiento, o las redes. Sin embargo, también hay otras muchas pruebas para evaluar otros parámetros del sistema.

Gracias a que este software repite las mismas pruebas una y otra vez, se pueden usar bases de datos con los puntos de referencia de pruebas anteriores y así poder comparar los resultados de varios dispositivos diferentes. Por ejemplo, se puede comparar el rendimiento de un microprocesador con respecto a otros modelos de esa misma marca o con los de la competencia.

Hasta mediados de los 80, el rendimiento de los procesadores creció alrededor de un 25% anual debido a los avances de la tecnología. A partir de ahí, se han ido dando saltos de hasta el 52% anual, producto de ideas arquitectónicas y organizativas avanzadas. En 2002, los límites de potencia, el paralelismo a nivel de instrucción disponible, la latencia de la memoria y otros impedimentos, han hecho que se ralenticen las mejoras a aproximadamente el 22% anual.

Este tipo de benchmark es necesaria, ya que dos máquinas, o procesadores, que aparentemente cuenten con iguales características, como es la capacidad de la memoria caché, la frecuencia de reloj a la que trabajan, etc., su rendimiento no será el mismo debido a las diferentes microarquitecturas. Así mismo, muchos usuarios no disponen de las dos máquinas para ejecutar software y comparar tiempos, por eso se deben fiar de los puntos de referencia para hacer las comparaciones en la máquina que sí poseen.

Además, muchas empresas usan estos puntos de referencia como un instrumento de marketing también, comparando su rendimiento con el de la competencia.

¿Cuándo es necesario evaluar el rendimiento?

El uso de un benchmark (o de las bases de datos con resultados) puede ser una buena idea en varias situaciones:

  • Antes de comprar un nuevo hardware, para poder elegir el que mejor se adapte a tus necesidades.
  • Cuando se va a actualizar un equipo, tanto antes como después de la actualización. Así se podrá evaluar si la modificación ha tenido el impacto esperado o no.
  • En caso de hacer overclocking, no solo para ver el salto de rendimiento, también porque estas pruebas someten al hardware a un estrés que te ayudará a determinar si sufre de inestabilidad debido a la aceleración y se necesita dar marcha atrás.

Pruebas disponibles

Si sientes curiosidad por emplear este tipo de software para pruebas, dispones de multitud de ellas, algunas clásicas como Dhrystone y Whetstone. Algunos de los ejemplos más famosos son:

  • Código abierto y/o para múltiples plataformas:
    • Coremark: específico para unidades de procesamiento, y un estándar en la industria.
    • HardInfo: software similar a AIDA64 para Linux y con capacidad de realizar varias pruebas comparativas.
    • Geekbench: mide rendimiento de CPU y GPU.
    • IOzone: punto de referencia para medir el rendimiento del FS.
    • LINPACK: prueba muy conocida en HPC para medir FLOPS, por ejemplo, para la lista Top500 de supercomputadoras.
    • UNIGINE: pruebas de rendimiento gráfico en tiempo real para la GPU.
    • Phoronix Test Suite: suite de múltiples pruebas.
    • PARSEC: benchmark suite orientada a procesamiento multihilo que usan Pthreads (POSIX) u OpenMP.
    • Fhourstone: para cálculo de enteros de la CPU.
    • POV-Ray: para renderización 3D de la GPU.
    • VMmark: para virtualización.
  • Para Windows:
    • CrystalDiskMark: es una de las herramientas de referencia para medir el rendimiento de los medios de almacenamiento.
    • Futuremark (3D Mark, PCMark,…): pruebas para la CPU y GPU.
    • AIDA64: suite que permite ver información del sistema y realizar pruebas comparativas.
    • GFXbench: para rendimiento gráfico con OpenGL y Vulkan. También está disponible para Android e iOS.
    • CineBench: para medir el rendimiento de la CPU y la renderización.
  • Para dispositivos móviles:
    • AnTuTu: similar a AIDA64, pero para dispositivos móviles, además, también tiene pruebas de rendimiento comparativas.
    • PassMask: similar al anterior, pero también está disponible para PC.
    • BaseMark: benchmark basado en web.

Recursos para ver resultados – PassMark / Guide of Scores

¿Cómo interpretar los resultados?

Para interpretar los resultados de un benchmark deberías comprender que se suelen interpretar en algunas webs que ofrecen comparativas mediante marcas o gráficas:

  • Higher is Better vs Lower is Better: siempre debes leer muy bien, puesto que no siempre un nivel más alto es mejor que uno bajo. Por ejemplo, si se está midiendo la tasa de FPS, más es mejor. Sin embargo, si se está midiendo el tiempo que se tarda en comprimir un ZIP en segundos, menos es mejor.
  • ¿En qué fijarme?: para el mundo real son importantes valores como:
    • Caída de fotogramas: mide la cantidad de fotogramas perdidos al codificar un vídeo. Mientras menor sea, mejor será la calidad del vídeo.
    • FPS: los frames per second, o fotogramas por segundo, indican la cantidad de veces que se actualiza la escena en cada segundo. Un nivel mayor es siempre mejor. Sin embargo, no es igual si se mide FPS para vídeo que para videojuegos. Para vídeo te indica la cantidad de FPS que el sistema es capaz de codificar en cada segundo. En el caso de los videojuegos se refiere a la cantidad de renderizados por segundo (en ocasiones también se mide el tiempo de fotograma, buscando valores bajos como lo más apropiado).
    • GB/s: en pruebas de cifrado también se puede medir el rendimiento en gigabytes por segundo. Mientras más alto sea el valor, mejor.
    • MIPS: los millones de instrucciones por segundo también es una comparativa frecuente. Mientras mayor, mejor. Eso sí, esta cifra puede variar con la frecuencia, compara siempre a frecuencias similares o iguales. Por ejemplo, se puede obtener 97.000 MIPS @ 3.7Ghz y 115.000 MIPS @ 5Ghz.
    • Tiempo de renderizado: otra prueba que medirá la velocidad con la que se renderiza la geometría, iluminación y texturas de una escena 3D. Cuando más bajo sea el tiempo, mejor.
  • Single-core vs Multi-core: es importante comparar ambos. El motivo es que no todo el software aprovecha bien el paralelismo. El rendimiento single-core es más relevante para videojuegos y aplicaciones que solo hacen uso de pocos hilos. Por tanto, si quieres un buen procesador para videojuegos, mejor elige uno con el mejor rendimiento single-core y una alta frecuencia de reloj. Por otro lado, el rendimiento multinúcleo es más relevante para otras tareas que sí pueden aprovecharlo, como compilación, virtualización, codificación, renderizado, simulación, cálculo científico, etc.

Características esenciales

Un benchmark, o prueba de referencia, debería tener unas características básicas que se deben respetar para considerarlo apto:

  • Relevancia: debe medir datos relevantes.
  • Representatividad: las métricas deben ser realmente representativas.
  • Equidad: no deben diseñar para favorecer a unos u otros productos, sino que se deben comportar de manera justa.
  • Repetitiviad: deben permitir repetir los resultados de las pruebas comparativas y verificar que los datos son ciertos.
  • Rentabilidad: deben ser económicos.
  • Escalabilidad: deberían funcionar en equipos con pocos recursos y en los que tengan una gran cantidad de ellos.
  • Transparencia: se necesita que sean fáciles de interpretar y entender.

¿El problema? La mayoría de estos puntos no se suele respetar en las pruebas que realizan algunas empresas durante las presentaciones de sus productos…

Tipos

Dentro de los puntos de referencia puedes encontrar varios tipos según las características:

  • Programa real: son los preferidos cuando se trata de medir el rendimiento real de un sistema, ya que se trata del software que usa el usuario. Por ejemplo, puede usarse una app para comprimir, un software de codificación de vídeo, un simulador, un procesador de textos, un software CAD, etc. Por ejemplo, se puede hacer con videojuegos midiendo el FPS, con 7-Zip, Blender, GIMP, Handbrake, etc.
  • Microbenchmark: son fragmentos de código pequeños y específicos para medir el rendimiento de componentes básicos.
  • Core: suelen ser códigos muy concretos, generalmente sacados de un programa real. Algunos ejemplos son LINPACK o el bucle Livermore.
  • Sintéticos: fueron los primeros benchmarks en usarse, como Dhrystone o Whetstone. Son pruebas sintéticas al ser programas específicos para medir prestaciones del sistema, pero no suelen tener demasiado que ver con el mundo real. Es decir, están en el otro extremo de los programas reales. Ejemplos son PassMark, 3DMark, PCMark, etc.
  • Puntos de referencia de E/S: son específicos para medir prestaciones del sistema de entrada y salida.
  • Puntos de referencia de base de datos: específicos para bases de datos.
  • Puntos de referencia paralelos: usados en máquinas con gran paralelismo.

Por cierto, durante el diseño de algunos procesadores también se emplea software para anticipar el rendimiento que tendría el sistema en fases tempranas de su creación. Por ejemplo, los simuladores de rendimiento (Trace-Driven y Execution-Driven).

¿Qué es SPEC?

SPEC (Standard Performance Evaluation Corporation) es un consorcio sin ánimo de lucro que está centrado en crear conjuntos estándares de puntos de referencia para los sistemas informáticos modernos, así como publicar los resultados. Este organismo se creó con miembros como AMD, Intel, Dell, Fujitsu, Siemens Computers, HP, IBM, y Sun Microsystems (ahora Oracle).

En 1989 se creó el conjunto para benchmark que evaluaría el rendimiento del procesador y al que se bautizó como SPEC89. Más tarde aparecerían otras actualizaciones (SPEC92, SPEC95, SPEC2000,…) que han ido tratando de mejorar y adaptarse a los nuevos requisitos de los sistemas actuales.

Por ejemplo, el estándar SPEC2006, en el que se han incluido varios programas o pruebas para medir el rendimiento actualizadas que constan de:

  • CINT2006: 12 puntos de referencia de enteros. Estos varían desde un compilador de C hasta un programa de ajedrez, e incluso una simulación por computadora cuántica.
  • CFP2006: 17 puntos de referencia de coma flotante. Incluyen códigos de estructuras grid para modelado de elementos finitos, procesamiento de partículas para dinámica molecular, y álgebra lineal dispersa para la dinámica de fluidos.

SPEC, para simplificar los resultados, en vez de aportar los valores de cada uno de esos 12 y 17 puntos de referencia, lo que hizo fue usar una media del tiempo de ejecución de todos esos y normalizarlos bajo lo que se conoce como SPECratio. Una cifra más grande indica mayor rendimiento, es decir, es inversamente proporcional al tiempo de ejecución.

Existe un consorcio u organización sin ánimo de lucro que también está centrada en crear benchmark estándar para sistemas embebidos. Se conoce como EEMBC.

También existe el SPECpower, que fue el primer intento de la industria por crear un punto de referencia que pudiera evaluar tanto el rendimiento de las computadoras como la potencia. Algo clave en los centros de datos.

Una de las últimas revisiones es SPEC2017, cuya última versión es la 1.1.8 lanzada en abril de 2021.

Además, a partir de 2008, SPEC también iría más allá de las suites originales destinadas a medir el rendimiento de la CPU, incorporando también pruebas para GPU, computación científica de alto rendimiento, computación orientada a objetos, sistemas de archivos (FS), servidores y clientes web, Java, y aplicaciones CAD.

Más información – Sitio web de SPEC

Más información sobre requisitos, guías de instalación, etc – SPEC CPU 2017

Benchmark: Desafíos para el futuro

Los benchmarks se enfrentan a numerosos desafíos. La evaluación no suele ser fácil, y en ocasiones implica usar multitud de software diferente y realizar varias pruebas iterativas para poder llegar a conclusiones que se ajusten más a la realidad. Además, se debe emplear el mismo software y versiones, así como la misma versión de firmware, y un hardware lo más parecido posible entre las máquinas a comparar. De lo contrario, se pueden inducir variaciones.

Por ejemplo, si quieres comparar un AMD Ryzen y un Intel Core, no deberías usar memorias RAM diferentes (latencia, capacidad, frecuencia, tipo), mismo disco duro,…

Por otro lado, las empresas deberían ajustarse a los puntos de referencia estándar, para no generar confusión con pruebas propietarias. Y también se deberían ajustar mejor al método científico, ya que las muestras son, en ocasiones, demasiado pequeñas como para ser representativas, o a veces falta control en cuanto a las variables que están influyendo.

Y las pruebas deberían ir más allá de realizar ciertas operaciones computacionales sin más, pudiendo evaluar otros detalles que ahora están totalmente descuidados y que importan. Por ejemplo, cualidades como la confiabilidad, disponibilidad, seguridad, tiempos de recuperación, tener en cuenta caídas de rendimiento de algunas máquinas (fall off a cliff), etc., que son vitales en un centro de datos.

Se llama intensidad aritmética a la relación entre las operaciones de coma flotante de un programa y el número de bytes de datos a los que accede un programa desde la memoria principal. Puede calcularse los Bytes/segundo accedidos dividiendo entre los FLOPS y las operaciones de coma flotante por byte.

Por otro lado, la forma de representar los datos también es importante. Existe el modelo Roofline que permite visualizar los datos de rendimiento en un sistema paralelo de una forma muy intuitiva. Este modelo tiene en cuenta algo muy interesante, y no solo es el rendimiento, sino también la intensidad aritmética.

roofline model

Como se puede ver en la gráfica anterior, el Roofline Model se basa en un representación del rendimiento de coma flotante alcanzable (GFLOPS) en el eje vertical (Y) y de la intensidad aritmética (FLOP/Byte) de los accesos en el eje horizontal (X).

Malas ideas…

Tomar el IPC de una unidad de procesamiento como una referencia es una mala idea. El software en la práctica necesita de instrucciones diferentes (con diferente número de ciclos para completar cada una de ellas), además de producirse fallos de caché, vaciado del cauce por predicciones fallidas, etc.

Tampoco uses herramientas como time de Linux para comparar rendimientos. No es nada fiable hacer eso, ten en cuenta que este comando lo que hace es medir el tiempo que tarda en ejecutarse un programa. Sin embargo, si lo ejecutas varias veces verás que los resultados son diferentes en cada caso, pese a que la máquina no ha variado. ¿Por qué? Muy fácil, dependerá de la carga de trabajo del sistema en ese momento, el planificador del kernel puede estar dando preferencia a otros procesos y que no lo sepas…

Y cuidado con las pruebas de una sola pasada, ya que suele hacerse con el dispositivo a una temperatura más baja y se consiguen los mejores resultados. Pero eso no se corresponde con la realidad. Con el aumento de la temperatura se suele realizar throttling y otras gestiones de energía para reducir el consumo a costa del rendimiento. Por eso, lo más representativo sería realizar pruebas en las que se someta el sistema a mayor estrés para ver también las puntuaciones cuando está a mayor temperatura. Además, este tipo de ajustes de energía pueden depender también de los controladores (versiones) y/o sistema operativo, por lo que también hay que prestar atención a ellos a la hora de hacer las pruebas al igual que se hacía con las configuraciones y el firmware.

¿Son fiables los benchmarks?

vs competencia rivalidad, benchmark

Atendiendo a lo dicho en el apartado anterior, la respuesta es: no demasiado. Sin embargo, la cosa empeora aún más si se tienen en cuenta las artimañas de algunas empresas. Es decir, que te puedes fiar de los resultados que te dan tanto como te fíes del que te los está dando… y créeme, una empresa nunca se va a perjudicar.

A veces, la falsedad de las pruebas de rendimiento es directamente proporcional a la situación de presión por parte de la competencia. En algunas conferencias se ha podido ver a ciertas compañías hacer malabares para «trucar» las pruebas y que no den resultados tan pésimos frente al avance de la competencia.

Se sabe, y no es ningún misterio, que las empresas suelen configurar sus sistemas para brindar un rendimiento más alto a sus productos y así mejorar su imagen frente a la competencia, e incluso perjudicar a los productos de la competencia optimizando algunos compiladores. Sin embargo, nada de eso tiene correlación con la realidad.

Por supuesto, se necesitan re-escrituras del código para adaptar los programas a las nuevas unidades de procesamiento, por ejemplo par aprovechar los múltiples hilos en paralelo o los múltiples núcleos de procesamiento. Pero una cosa es adaptar para aprovechar todos los recursos y otra es optimizar para que los datos sean mejor de lo que realmente serían…

En la década de los 80, por ejemplo, se usaban compiladores que usaban un sistema para detectar ciertas operaciones matemáticas que usaban estos puntos de referencia y sustituirlas por otras operaciones más rápidas. Sin embargo, en el mundo real, rara vez se hacía eso. Por tanto, el usuario se dejaba influenciar por unas cifras maquilladas.

Además, algunas benchmarks suelen dar mejores cifras para un determinado producto que otras, pese a que están tratando de medir lo mismo. Por eso, muchas compañías emplean la que sea más favorecedora. Es por eso que, para una comparación correcta de dos productos, se deberían emplear varias pruebas diferentes.

Todo esto se denomina marketing comparativo, y puede resultar extremadamente confuso y engañoso para el usuario.

Lo ideal sería ejecutar aplicaciones del mundo real y comparar los resultados con ellas, sin emplear un benchmark, más aun en sistemas donde el rendimiento es crítico. Sin embargo, esto casi nunca se hace, y en ocasiones ni siquiera se encuentra disponible la app para una determinada arquitectura.

¿Sabía que no solo se manipula el benchmark? También existen algunos diseños de hardware, especialmente algunas CPUs que se sospecha que han sido especialmente diseñadas para obtener buenos resultados con las pruebas de rendimiento, pero no para el software real. Esto, aunque parezca absurdo, se ha usado en algunas guerras entre ciertas potencias para mostrar músculo en cuanto a capacidad de supercomputación…

Estudio del caso Apple M1

Desde el lanzamiento del Apple M1, muchas páginas se han publicado sobre el resultado de este chip bajo el benchmark. La compañía de Cupertino quería justificar a toda costa que el cambio de Intel a sus propios chips basados en la ISA ARM tenía sentido, y quizás los valores que se han vendido no sean del todo reales…

Por un lado, hay que tener en cuenta que no se pueden comparar en igualdad de condiciones con los chips x86-64, ya que, entre otras cosas, los M1 carecen de extensiones para virtualización (un problema para Rosetta, y la compatibilidad de ciertos programas), entre otras cosas, como el «pequeño» detalle de tener la memoria en el mismo empaquetado, y otros aceleradores incluidos on-chip dentro del SoC.

Por otro lado, Apple recompila su código casi cada año para optimizarlo. Eso en los x86 no ocurre. En el mundo del PC, algunos códigos existentes tienen casi 20 años, ya que son «legacy», hechos para la retrocompatibilidad y para que funcione en una amplia gama de chips diferentes.

Si se usan las «spec rules» (véase flags de GCC, también te puede interesar ver PGO y LTO) para una CPU específica, y no el código compilado de forma genérica, entonces se dan también mejores resultados. También influye el tipo de compilador usado para la compilación, ya que no todos generan código igual de eficiente.

Por todo esto, comparar algunos resultados de un benchmark puede ser como comparar peras y manzanas.

En el caso del Apple M1, seguro que has visto referencias muy optimistas para la empresa de la manzana en Geekbench cuando se compara su arquitectura con otros chips x86 de Intel y AMD. Pero esos datos no son fiables, de hecho, en Cinebench R23, por ejemplo, los resultados son peores (a pesar de la desventaja de nodo para los AMD e Intel, ya que los verdes  están fabricados en proceso de 7nm de TSMC y los de Chipzilla en 14/10nm, frente a los 5nm de Apple):

Debido a un contrato de exclusividad con TSMC, Apple tiene garantizado el acceso a los nodos más nuevos antes que nadie. Una ventaja en la fabricación que le hace tener algo más de margen frente a sus competidores. AMD tendría que esperar más tiempo produciendo con 7nm antes de poder pasar a los 5nm, cuando estén «libres» por esta cláusula. En ese momento, Apple debería ya contar con acceso a los 3nm…

  • Apple M1 (single a 2.5Ghz): ~990
  • AMD Ryzen 5 3600X (single a 4.4Ghz): ~1300
  • Apple M1 (multi): ~4530
  • AMD Ryzen 5 3600X (multi): ~9500
  • AMD Ryzen 7 4800H (multi): 10590
  • AMD Ryzen 7 4800U (multi): 10156
  • Intel Core i7-1185G7 (10nm – multi): 6264
  • Intel Core i7-10850H (14nm – multi): 7455
  • Intel Core i7-1185G7 (10nm – single): 1538
  • Intel Core i7-10850H (14nm – single): 1504

El Intel de 11ºGen alcanza una puntuación inferior debido a que tiene menor cantidad de núcleos que el de 10º Gen. Sin embargo, la nueva microarquitectura supera a la anterior en single-core debido a las mejoras.

Y es que, el M1 tiene un gran IPC, sí, pero no una frecuencia demasiado alta. Hay que buscar un buen compromiso entre ambos para conseguir los mejores resultados en el mundo real. Y en el caso de Apple no es así…

¿Entonces por qué en Geekbench gana y en Cinebench R23 no? En el caso de Geekbench ejecuta múltiples algoritmos y luego hace una media geométrica de los resultados. Algo que puede sesgar algunos resultados si existen ciertas optimizaciones. En cambio, Cinebench mide la potencia bruta del procesador, y es el punto de referencia preferido por la mayoría de entusiastas.

Lo que te quiero hacer ver con esto es que no es oro todo lo que reluce, y que debes tomar los resultados que te muestran con pinzas. La afirmación hecha por Apple de que «En un MacBook Air, el M1 es más rápido que el 98% de los chips portátiles vendidos el pasado año» no es cierta.

Ejemplo justo

Últimamente, el famoso portal de tecnología Anandtech, concretamente Ian Cutress, están haciendo una impecable labor en cuanto a las comparativas con los puntos de referencia que están haciendo. Lo puedes tomar como un ejemplo justo de comparación.

Verás que, en vez de limitarse a un software benchmark concreto, lo que hace es probar varios de ellos para obtener resultados más acordes con la realidad:

  • Microbenchmarks: con ellos prueban detalles como la latencia núcleo-núcleo, la latencia caché-DRAM, y rampa de frecuencia para el escalado.
  • Test para ofimática y software científico: prueba la CPU con este tipo de software muy habitual en el mundo real. Por ejemplo con programas como GIMP, o movimiento de partículas (con y sin uso de extensiones especiales como AVX), IA, etc.
  • Simulación: esto también tiene que ver con las aplicaciones científicas. En este caso se emplean una serie de simulaciones y renderizado para determinar la potencia de la CPU en este tipo de software.
  • Codificación y compresión: la codificación en el mundo multimedia y la des/compresión también son tareas muy habituales en el día a día. Por eso también prueban la CPU con este tipo de apps. Incluso agregan también pruebas de JavaScript y web.
  • SPEC: por supuesto, no puede faltar el estándar. Además, emplean el compilador LLVM en vez de GCC por ser mejor en las múltiples plataformas soportadas y así poder hacer comparaciones entre sistemas más igualadas.
  • Gaming: tampoco podía ser una evaluación completa sin probar el rendimiento en videojuegos.

Isaac

Apasionado de la computación y la tecnología en general. Siempre intentando desaprender para apreHender.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

A %d blogueros les gusta esto:

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar