feed

Google

Después de escribir la anterior entrada sobre el lenguaje de programación go y de leer un comentario donde se dice que Go es bastante lento, me he decidido a realizar unos benchmarks muy sencillos.

La idea es comparar la velocidad de ejecución de la devolución del logaritmo natural de un número dado y la introducción del mismo en un mapa o hash. Obviamente, la velocidad depende en gran medida de la implementación del contenedor en cada lenguaje.

En cuanto a Go, he usado el compilador 6g basado en Inferno por que no quiero instalar una versión inestable del compilador GCC en mi Gentoo Linux y cagarla a lo grande, supuéstamente, el gccgo optimiza más el código que el 6g.

NOTA: Este benchmark es bastante cutre y simplón, solo lo hice para aliviar mi curiosidad y ver más o menos por donde andaba el rendimiento de Go. En el futuro y cuando tenga más tiempo, haré uno en serio añadiendo Java, Ruby y Scala.

Implementación C

Vamos a empezar por la implementación en C de este sencillo benchmark. He utilizado las librerías uthash para crear al Hash, puedes encontrarlas en sourceforge

Código becnhmark.c

#include <math .h> #include "uthash.h" struct map { float id; float value; UT_hash_handle hh; }; struct map *dict = NULL; void add_data(float data_id, float data) { struct map *m; m = malloc(sizeof(struct map)); m->id = data_id; m->value = data; HASH_ADD_INT( dict, id, m ); } int main() { for (int i = 0; i < 5000000; i++) { add_data(i, log(i)); } return 0; }

Compilación

genbeta@dev $ gcc -O3 -Wall -c -fmessage-length=0 -MMD -MP -std=c99 benchmark.c gcc -lm -o cbench benchmark.o

Implementación C++

Para C++ usamos el contenedor map de la STL

Código benchmark.cpp

#include <iostream> #include <map> #include <cmath> using namespace std; int main() { map <float , float> dict; for (int i = 0; i < 5000000; i++) { dict[i] = log(i); } return 0; }

Compilación

genbeta@dev $ g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP benchmark.cpp -o cppbenchmark.o g++ -o cppbench cppbenchmark.o

Implementación en C# de Mono

Los expertos en .NET C# que me perdonen pero no tengo ni idea de C# no se si este snippet está muy bien pero el caso es que funciona de maravilla, si hay algún error ruego que me corrijan.

Código benchmark.cs

using System; using System.Collections; namespace CSBenchmark { class MainClass { public static void Main (string[] args) { Hashtable dict = new Hashtable(); for (int i = 0; i < 5000000; i++) { dict.Add(i, Math.Log(i)); } } } }

Compilación

genbeta@dev $ /usr/bin/gmcs /noconfig "/out:./benchmark.exe" "/r:/usr/lib/mono/2.0/System.dll" /nologo /warn:4 /debug:+ /debug:full /optimize- /codepage:utf8 /platform:x86 "/define:DEBUG" /t:exe "./benchmark.cs"

Implementación en Python

Esta sea seguramente la más sencilla de todas :)

Código benchmark.py

import math d = {} for i in range(1, 5000000): d[i] = math.log(i)

Implementación en Go

Esta también es muy sencilla, está más o menos a la par con C++

Código benchmark.go

package main import "math" func main() { m := make(map[float64] float64) var i float64 = 1 for ; i < 5000000.; i++ { m[i] = math.Log(i) } }

Compilación

genbeta@dev $ 6g benchmark.go && 6l benchmark.6 && mv 6.out gobench

Benchmarking

Para la ejecución de los benchmarks utilizo el comando time de GNU sobre el siguiente sistema:Sistema Operativo: Gentoo LinuxArquitectura: x86_64Procesador: Intel® Core™ i7 CPU @ 2.80GHzVelocidad RAM: 1666

LenguajeTiempo UsuarioTiempo SistemaTiempo RealUso de CPUUso de RamCambios de ContextoC1.90s0.27s2.19s99%1826704kB1C++4.07s0.14s4.24s99%941808kB1C#1.72s0.29s2.01s131%2032176kB1155Python CPython 2.7.23.43s0.37s3.86s99%2101312kB1Python PyPy-c1.51.57s0.33s2.70s99%2442032kB280Go2.76s0.16s2.93s99%1044304kB1

Es destacable como C# es el más rápido con 2.01, no tengo ni idea de si eso es así por la implementación de Mono, del lenguaje en si, o si es que no he hecho bien el benchmark en C# pero lo cierto es que estoy gratamente impresionado. Le sigue muy de cerca C con 2.19s, después la implementación PyPy de Python 2.7 con 2.70, tras él le toca el turno a Go con 2.93, la implementación de CPython 2.7 le sigue con 3.86 y muy tristemente el último lugar lo ocupa C++ con un 4.24

También podemos apreciar como Mono y PyPy utilizan más de un núcleo de mi procesador i7 mientras que el resto solo utilizan un núcleo al 99%.

En cuanto al consumo de memoria, C++ es el más óptimo seguido muy de cerca por Go. C# y Python —en ambas implementaciones— hacen un uso mucho mayor de recursos.

Go Profiling

Pero ojo, ese benchmark ha sido ejecutado sin utilizar profiling en Go. En Go se usan las herramientas de profiling para detectar cuellos de botella y arreglarlos mejorando el rendimiento considerablemente. El paper al que un usuario hacía referencia en el anterior post, es un benchmark sin profiling en Go y ya ha tenido su respuesta por parte de los creadores del lenguaje en el blog oficial. Vamos a utilizar profiling a ver cuanto podemos mejorar el rendimiento de nuestro snippet en Go.

Primero modificamos el código de nuestra función para añadir soporte para cpuprofiling, nuestro código quedaría así:

package main<br /> import ( &#8220;math&#8221; &#8220;os&#8221; &#8220;flag&#8221; &#8220;log&#8221; &#8220;runtime/pprof&#8221;<br /> )<br /> var cpuprofile = flag.String(&#8220;cpuprofile&#8221;, &#8220;&#8221;, &#8220;write cpu profile to file&#8221;)<br /> func main() { flag.Parse() if *cpuprofile != &#8220;&#8221; { f, err := os.Create(*cpuprofile) if err != nil { log.Fatal(err) } pprof.StartCPUProfile(f) defer pprof.StopCPUProfile() } m := make(map[float64] float64)

var i float64 = 1 for ; i < 5000000.; i++ { m[i] = math.Log(i) } }

Ahora podemos ejecutar el snippet con el parámetro cpuprofile y depurarlo con gopprof:

./gobench -cpuprofile=gobench.prof gopprof gobench gobench.prof Welcome to pprof! For help, type &#39;help&#39;. (pprof) top10 Total: 290 samples 149 51.4% 51.4% 224 77.2% hash_insert_internal 32 11.0% 62.4% 32 11.0% math.Log 17 5.9% 68.3% 17 5.9% runtime.mcpy 17 5.9% 74.1% 17 5.9% runtime.memmove 16 5.5% 79.7% 16 5.5% memhash 13 4.5% 84.1% 13 4.5% runtime.memclr 13 4.5% 88.6% 13 4.5% scanblock 8 2.8% 91.4% 250 86.2% runtime.mapassign 5 1.7% 93.1% 8 2.8% MHeap_AllocLocked 5 1.7% 94.8% 5 1.7% memwordcopy (pprof)

Podemos ver que la aplicación ocupa la mayoría de los ciclos de la CPU y el tiempo de ejecución en introducir valores en el map. El depurado de aplicaciones desarrolladas en Go con gopprof va mucho más allá de la intención de esta entrada, pero comprobando los listados del código y los samples empleados en cada línea podemos saber que el cuello de botella esta en la línea m[i] = math.Log(i) que acumula 285 de los 290 samples de la ejecución.

Queda claro que el uso de un map para esta benchmark no es nada óptimo y podríamos utilizar un slice para almacenar los datos. Si editamos el archivo y comentamos la linea /*m := make(map[float64] float64)*/ y usamos un slice en lugar de un map var p [5000000]float64; m := make([]float64, len(p)) y volvemos a generar un archivo .prof y depuramos:

Welcome to pprof! For help, type &#39;help&#39;. (pprof) top10 -cum Total: 25 samples 7 28.0% 28.0% 25 100.0% main.main 0 0.0% 28.0% 25 100.0% runtime.initdone 0 0.0% 28.0% 25 100.0% runtime.mainstart 18 72.0% 100.0% 18 72.0% math.Log (pprof)

Comprobamos que ahora la práctica totalidad del tiempo está dedicada a la función que devuelve el logaritmo natural de i y ya no hay ningún cuello de botella. Vamos a eliminar el código que introduce la funcionalidad de depurado comentándolo y pasemos el benchmark otra vez.

LenguajeTiempo UsuarioTiempo SistemaTiempo RealUso de CPUUso de RamCambios de ContextoGo0.22s0.01s0.24s99%314512kB1

Ouch! Una mejoría notable. Pero seamos justos, vamos a cambiar el hash en la implementación de C por un simple array y convertir el benchmark en simplemente calcular el logaritmo natural de i e introducir el valor en un array.

LenguajeTiempo UsuarioTiempo SistemaTiempo RealUso de CPUUso de RamCambios de ContextoC0.31s0.00s0.31s99%1824kB1Go0.22s0.01s0.24s99%314512kB1

En este caso, Go es incluso más rápido que C devolviendo el logaritmo natural de i.

Conclusión

Parece que el tipo map no está muy fino en Go, aún así, la velocidad y eficiencia del lenguaje está entre C y C++. En este caso, no podemos hacer nada cien por cien legítimo por eliminar el cuello de botella por que es parte específica del test que hemos realizado. No se si hay que esperar cuatro años como he leído por ahí a que el lenguaje esté más maduro o no. Está claro que aún le falta madurez y necesita unas cuantas implementaciones en sistemas para poder mejorar. Lo que si que se es que yo al menos le voy a seguir la pista, y más ahora que está disponible en Google App Engine y es más eficiente que Python y Java.

Más en Genbeta Dev | Introducción al lenguaje de programación Go

Google anunció el pasado junio su apuesta por material design para la web. Google, desde el año pasado buscaba la unificación del diseño tanto en los entornos de escritorio como web. Material Design Lite es una biblioteca de componentes, basada en la guía de estilo de material design. Vamos a presentar y analizar sus componentes.

Una breve introducción a la filosofía

La metáfora del material


La metáfora del material es la definición de la relación entre el espacio y el movimiento. El material,
...

Leer más »

Trabajar de una forma más sencilla y cercana con la comunidad de desarrolladores. Esta es una de las principales premisas que apreciamos en el movimiento realizado por Google migrando Dart a Github.

Dart SDK tiene ahora su propio repositorio, uniéndose a las númeras herramientas y librerías que se han desarrollado alrededor del lenguaje. También se ha trasladado dartbug (aseguran que sin perder...

Leer más »

Muchas veces tenemos la necesidad de utilizar alguna herramienta profesional a la hora de construir diagramas UML, Entidad Relación etc. Siempre han existido muchas opciones pero casi todas de pago. Ahora poco a poco comienzan a aparecer herramientas en la nube que ofrecen bastantes características de forma gratuita una de las que más destaca es Draw.io.

Extensión de Google Chrome

Draw.io se...

Leer más »

Es un caso viejo, la disputa entre dos colosos como Oracle y Google por las patentes de Java y Android. Sin embargo ahora se ha producido un giro en los acontecimientos que se puede tornar definitivo: el gobierno de los Estados Unidos, a través del Departamento de Justicia y a petición del juzgado de apelación, se ha posicionado a favor de Oracle y afirma que las APIs son susceptibles de tener...

Leer más »

Es un hecho que hoy en día que los frameworks MVC de JavaScript están asumiendo más peso en los desarrollos. Hace un año las empresas eran reacias a abordar proyectos de cierta entidad apoyandose en ellos. Hoy la tendencia esta cambiando y muchas empresas están empezando a adoptarlos como parte de sus arquitecturas.

¿Cuantos frameworks MVC existen en JavaScript?

Esta podría ser la pregunta de...

Leer más »

Aprovechando el paso por Madrid de la Droidcon Spain 2015, hemos tenido la oportunidad de realizar unas mini entrevistas a los ponentes de esta edición. Gracias a la colaboración de estos 15 speakers hemos podido extraer su vision sobre las tendencias de desarrollo en Android y qué mejorarían de la plataforma . El contenido de las charlas van enfocadas totalmente a su experiencia diaria como...

Leer más »

La Droidcon Spain 2015 es la cita ineludible para cualquier desarrollador de Android que se precie. Este año se adelanta de fecha: concretamente los días 23, 24 y 25 de Abril en Madrid, de nuevo se repite ciudad.

¿Qué ofrece este año la DroidCon Spain? Después de lo comentado el año pasado sobre la madurez del desarrollo de aplicaciones Android , nos adentramos en una conferencia aún más...

Leer más »

Google ha abierto parcialmente de forma Open Source el sistema que usan para realizar los builds de forma interna. Se trata de Bazel, un build system construido íntegramente por Google que les permite entre otras cosas ser más rápidos, escalable y fiables a la hora de crear software.

Como todas las grandes compañías uno de los problemas de mayor importancia es el manejo de grandes cantidades de...

Leer más »

No sólo de información para profesionales vive Genbeta Dev, también nos ocupamos de los jóvenes aspirantes que todavía se forman en el entorno académico. Para ellos es el recordatorio de que por decimoprimer año Google organiza el Google Summer of Code, una buena oportunidad para colaborar en proyectos de software libre, ganarse un dinerillo y poner una muesca muy apañada en tu fusil curriculum...

Leer más »

gRPC, ha sido el framework usado internamente por Google para conectar microservicios. Mejorado obviamente durante el tiempo ha llegado a una potente evolución que ha unido a este framework RPC (Remote Procedure Call) con el reciente y casi casi estandarizado HTTP/2. Google ha decidido lanzarlo públicamente a la comunidad Open Source.

¿Por qué es tan interesante gRPC?

El foco principal es el...

Leer más »

Sigue a Genbetadev