Entendiendo canales y goroutines (me falta medir tiempos)

[ines...@gmail.com]

Hola de nuevo,

Como veréis continuo con Go.
Este finde puse cara a los canales y las goroutines pero no sé medir sus tiempos, es decir, quiero medir tiempos en todo, la verdad, con o sin goroutines, con o sin canales, paralelo, secuencial, jejeje.
Viendo la web, tienen la función :

func TestXxx(*testing.T)

Que añaden dentro luego un for, pero en mi caso me gustaría testear la goroutines, es decir, dentro de mi funcion main()
hago uso de mis canales y las goroutines (sus funciones están arriba del main)

Un ejemplo:

func main() {

	ir_cs := make(chan string)
	venir_cs := make(chan string)
	
	go conduciendo_al_trabajo(ir_cs, "conduciendo", 5)
        go conduciendo_vuelta_trabajo(venir_cs, "vuelta", 5) 
	go estancia_en_trabajo(ir_cs, venir_cs)     	
	
	time.Sleep(2 * 1e9)

}

¿Cómo mediríais aquí los tiempos?

func TestXxx(*testing.T)  *  Time make *  Time gotest * 
^Gracias por leer.

[Zorion]

Hola Inés,

Nunca he intentado medir tiempos y tal así que soy nuevo en eso. Perdona si digo tonterías.

He de decir que no entiendo muy bien tu ejemplo pero intentaré simplificar.

He hecho la prueba del BenchmarkHello que exponen aquí: http://golang.org/pkg/testing/

Lo he modificado para hacer una prueba simple con un canal sin buffer (no tengo muy claro si es correcto).

El siguiente código lo he metido en "$GOPATH/src/prueba/prueba_test.go":

package prueba

import "testing"

func BenchmarkHello(b *testing.B) {

c:=make(chan int)

go func(){

for{

<-c

}

}()

for i := 0; i < b.N; i++ {

c<-i

}

}

Con eso puedes ejecutar

z@h:.../src/prueba/$  go test -test.bench BenchmarkHello

Eso te da unos resultados tipo:

BenchmarkHello   50000000      492ns/op

Que entiendo que ha pasado por el canal 5 millones de enteros (b.N=5000000) y que ha tardado 492 ns por cada loop, es decir enviarlo (+ recibirlo en la rutina concurrente).

Disculpa si lo que he puesto es muy básico. Es mi primer "benchmark".

Referente a tu ejemplo, asumo que los canales los usas para enviar en las rutinas de "conduciendo" y para recibir en la de "estancia_en_trabajo".

No sé si vas a poder medir mucho enviando sólo una string por cada canal, ¿Cuántos pensabas enviar?, supongo que harás algún "for" hasta b.N en el futuro.

Por otro lado, creo que el Sleep del final no te haría falta si la función "estancia_en_trabajo" no fuera concurrente (no le pusieras el "go").

También me he fijado que la comunidad go suele usar identificadores camelCase más que con subguiones, es decir, estancia_en_trabajo -> estanciaEnTrabajo. Creo que no es obligatorio pero vale la pena hacerlo igual ;-)

Eso último de "..*time make*time go_test*" y tal no lo entiendo. ¿Necesitas medir el tiempo de compilación? 

Bueno, ya me dirás si te he ayudado en algo o en nada ;)

Saludos,

Zorion

2013/3/19 <ines...@gmail.com>

--
 
---
Has recibido este mensaje porque estás suscrito al grupo "golang-spanish" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a golang-spanis...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[ines...@gmail.com]

Gracias Zorion por tu pronta respuesta.

Las pruebas de canales eran sólo mis ejemplos para entenderlas, así como el uso de goroutines.
Ahora no tengo mucho tiempo para comentarte bien el ejemplo puesto que en las "go" realicé previamente las funciones de "conduciendo" con el for apropiado y luego sólo invocaba la goroutine dentro de func main() (por eso quería meter ahí dentro el test, no en el for, si no en el uso de la goroutine). El uso de sleep es para que el programa espere un poco, no acabe inmediatamente...

Acabo de probar el ejemplo que me has dado (copiado, pegado, ejecutado) y no consigo rularlo:

(dc mar 20) *Inés* > go test -test.bench BenchmarkHell
can't load package: package .: found packages prueba (benchmark.go)

Soy muy nueva con esto así que te agradezco mucho tu colaboración.
:)

PD: Si quiero medir tiempos de compilación y tiempos de todo.

[Zorion]

Por la tarde me lo intento mirar mejor, pero ahora solo se me ocurre que no debes tener bien puesto el nombre al archivo.
No sé si eso afecta pero mi prueba_test.go se llamaba exactamente así (creo que es importante que acabe en "_test.go") y estaba donde debería estar un package prueba, es decir, en $GOPATH\src\prueba\ (usas Windows, ¿no?).

[ines...@gmail.com]

Hola Zorion,

Acabo de renombrar el fichero para que acabe en _test.go y me ha dado el mismo error.
Mirando la ruta (No uso Windows, uso Lliurex, basado en Ubuntu ) veo que está dónde todos los programas y cuando lanzo el test me dice que tanto este programa como otro con goroutines no les encuentra el package... he pensado llevarlo un directorio atrás, y lo he pasado ahí y ualá, me ha dicho lo siguiente:

(server-lliurex)(dc mar 20) *Inés* > go test -test.bench BenchmarkHell
testing: warning: no tests to run
PASS
BenchmarkHello    10000000           204 ns/op
ok      _/.../Universidad/GoogleGO    2.260s
(server-lliurex)(dc mar 20) *Inés* >

*Antes estaba en: _/.../Universidad/GoogleGO/ejerciciosGo

Y no entiendo el porqué, antes no y ahora sí, ¿qué diferencia encuentra entre un directorio y otro? y tampoco entiendo que quiere decir con lo de testing: warning: no tests to run  PASS y luego muestre el test...

Bueno, hora de comer. Luego le doy más vueltas.
Muchas gracias.

:)

[Zorion]

Hola,

La estructura de directorios yo todavía no la tengo por la mano pero aparentemente es la clave del error.

Lo del warning es porque en realidad no hemos puesto ningún test.
Los test aparentemente son testXxx, nosotros hemos puesto un benchmarkXxx.
Entiendo que los test son para probar si las funcionalidades de un package son correctas y en cambio los benchmark son para evaluar su rendimiento. Que alguien me corrija si me equivoco.
Puesto que querías una manera de medir tiempo pensé que un benchmark era más adecuado.
De todos modos hemos hecho trampa porque no estamos evaluando el tiempo de un package, estamo metiendo todo el programa en la función de benchmark.

Saludos,

PS: Lo de Windows era porque me ha sorprendido que pusieras el prompt acabando en ">", que parece más propio de MS-DOS que de un "linux" (yo esperaría un "$" o incluso "#" si te gusta el riesgo).

[ines...@gmail.com]

Pues debe de venir por la estructura de directorios, pero pensé que con exportar el PATH estaba todo controlado.

Probaré más adelante otra vez con benchmark o TestXxx por si me arrojan luz.
Quiero saber añadir "temporizadores" en Go como en C:  gettimeofday(&t0, &z);
¿Cómo los haríais?

Cualquier ayuda es buena, lo agradezco mucho.
Un saludo.

Acabar el prompt en > es sólo por cambiar el riesgo #
:)

[Zorion]

El package time tiene una función "Now()".

http://golang.org/pkg/time/#Now

La he ejecutado con un fmt.Prinln(time.Now()) y el resultado te puede servir:

2013-03-20 21:57:21.600054 +0100 CET

Si quieres sacarlo con precisión puedes usar el método "Nanosecond()"

http://golang.org/pkg/time/#Time.Nanosecond

Por ejemplo: fmt.Prinln(time.Now().Nanosecond())

Para calcular el tiempo que ha pasado puedes sacar una Duration con la función "Since()" pasándole el Time inicial.

http://golang.org/pkg/time/#Since

2013/3/20 <ines...@gmail.com>

--

[ines...@gmail.com]

Me miro todas las opciones en cuanto pueda, sobre todo las de medir tiempo.
También he visto ahora la función  de ParseDuration que me comentas.

A parte de medir tiempos en canales, quiero medir tiempos en vectores, para la reserva de tamaño y espacio de las mismas, se utiliza make, no?

Muchas gracias.
:)

[Zorion]

No sé muy bien tu objetivo de "medirlo todo" de una manera tan atómica. 

De hecho me parece que no es correcto pero no puedo asegurarlo. Deberías medir funcionalidades un poco más complejas.

Respondiendo a tu pregunta:

Los "vectores" en go suelen representarse con arrays o con slices.

Un slice se reserva con el "make", sí. El espacio para una array se reserva al declararlo.

Para comprobarlo he intentado hacer "make" de un array o asignar una slice a un puntero a array:

http://play.golang.org/p/AcI7DglziS

Si usas vector2 como array, no le haces el make y funciona el puntero.

Si usas vector2 como slice "vector2:=make([]int,5)" no se puede asignar al puntero a array "*[5]int"

También he intentado hacer cosas como make([5]int) o make([5]int,5) y también parecen incorrectos.

Por si el ejemplo no es claro en la diferencia entre array y slice, mira el mismo ejemplo con punteros a slice:

http://play.golang.org/p/611hAKRHyk

(Disclaimer: un puntero a slice no es habitual en Go)

Como siempre, espero que alguien me corrija si me equivoco ;)

2013/3/21 <ines...@gmail.com>

[ines...@gmail.com]

Hola Zorion,
Son sólo pruebas y exactamente no voy a medirlo todo en un programa, mediré según que funciones o acciones en cada programa que hago y de diferentes formas.
Pero sí voy a medir más en paralelismo y concurrencia.

Grácias por los vectores. En cuanto pueda me pongo a ello.
Lo cierto que así, con tu ayuda, lo estoy entendiendo más.

Miraré bien lo que dices de  --> Disclaimer: un puntero a slice no es habitual en Go.
Y ya que estamos con esto: ¿Cómo se declara el tipo double en Go?
Ejemplo de C que quiero pasar a Go:   double *M y luego utilizarlo en Go como está en C: M= (double*) malloc(n_col*(n-col+1)/2*sizeof(double));

(Anteriormente en mi programa en Go tengo a n_col:  n_col,_ = strconv.Atoi(flag.Arg(1)) )

Mil gracias de nuevo.
¡¡ Por fin es viernes !!
:)

[Zorion]

Un double debe ser un decimal de 64, creo
En Go eso es float64.

Para hacer la reserva de espacio que pones (malloc) yo usaría slices, pero dependiendo de lo que quieras hacer una slice del tamaño total o una slice de slices.
1)
M:=make([]float64,tamaño)
o
2)
M:=make([][]flota64,n_col)
y en un for hasta n_col
M[i]=make([]float64,(ncol-1)/2)

Si fueran tamaños fijos podrías
var M [m][n]float64
Pero no parece tu caso :(

[ines...@gmail.com]

Nas Zorion,

Al final he realizado el siguiente calculo:

http://play.golang.org/p/UbwagaJLsd

Pero me da errores de sintaxis y no consigo que rule como debe hacer la solución. :(

Espero que esté bien explicado, en // está la forma que C lo habría hecho ...
Gracias.
Un saludo.

:)

[Zorion]

Hola Inés,

Go no es idéntico a C, tienes que tener en cuenta que las cosas se pueden hacer al estilo C o al estilo Go. Te recomiendo que intentes usar el estilo Go.

Por ejemplo, para intercambiar dos variables generales puedes hacer como en C:

tmp:=a //incluye la definición de la variable tmp al tipo de a

a=b

b=tmp

O puedes usar el estilo Go:

a,b=b,a

Te voy a poner varios de los fallos que he visto:

-Usar const para funciones del preprocesador (como #define), no creo que en Go tengamos algo así (un preprocesador). Si lo tenemos yo lo desconozco.

-El make no necesita que le pases el tamaño del float (sizeof), ya lo sabe, tú le indicas el número de posiciones, no el tamaño en bytes. Para hacer algo así se usa el unsafe pero tampoco lo he usado nunca.

-Si vas a usar un vector ([]float64) no definas una tabla ([][]float64) en el make.

Para hacer lo siguiente:

#define A(i,j) (A[i*n_A-i*(i+1)/2+j])

Podrías emularlo teniendo n_A y A como variables globales a través de una función como

func A(i int, j int) *float64

Luego para hacer los accesos a la "tabla" deberías usar *A(i,j) (el * es la indirección, para que sea asignable)

Ten también en cuenta que si la función se llama "A" ya no puedes llamar "A" a tu vector/tabla. Yo lo he llamado "a".

Mira tu ejemplo usando este estilo:

http://play.golang.org/p/n4_OPOqeCi (lo he probado y funciona si le das valor a las tablas a y c)

De todos modos, ¿no sería mejor hacerlo de otra manera?

¡Usar una tabla! Parece más natural

Con una tabla no te harían falta una función rara para el acceso.

Para crear una tabla de tamaño "m_C x n_C" haz esto:

C := make([][]float64, m_C) //vector de m_C posiciones del tipo []float64

for i, _ := range C {

C[i] = make([]float64, n_C) //vector de n_C posiciones del tipo float64

}

La tabla triangular A ya tiene un poco más de dificultad pero sabiendo que cada fila "i" tiene que tener n_A-i columnas no parece problemático.

A := make([][]float64, m_A)

for i, _ := range A {

A[i] = make([]float64, n_A-i)

}

Así de simple.

Ahora el acceso es tan fácil como A[i][j-i] y C[i][j], sin variables globales y al estilo Go.

Te paso el ejemplo hecho así:

http://play.golang.org/p/RBmoEucRqG

¿Entiendes el motivo por el cual el acceso a A deba ser así A[i][j-i]?

El hecho de que usemos el triángulo superior de A en este caso ha sido un poco problemático a la hora de usar una tabla.

Fíjate que si usamos el triángulo inferior todo se simplifica:

http://play.golang.org/p/amm8E3OpJa

El acceso es A[i][j] directamente (i>=j).

Cada fila de A se reserva con A[i]=make([]float64,i+1) //i+1 columnas, no necesitamos n_A

Sólo se calcula la parte triangular inferior y por simetria si B=C*C' entonces B[i][j]=B[j][i] así que eso no hay que cambiarlo: Sum_k(C[i][k]*C'[k][j]) == Sum_k(C[j][k]*C'[k][i])

Si tienes alguna duda vuelve a preguntar, me ha salido un e-mail largo pero es que había mucho que comentar ;)

Saludos.

2013/3/22 <ines...@gmail.com>

:)

[ines...@gmail.com]

Hola Zorion,

Muchas gracias por contestarme.
Tienes razón con que Go no es idéntico a C, trato de conocerlo a base de compararlo con C, pero es bien cierto que Go "simplifica" más la programación (necesita menos datos), por ejemplo con lo de intercambio de variables: a,b=b,a o cuando te dice que aunque declares variables enteras, i,j,k y las use, te dice él mismo que no las necesitas declarar...

Para usar la macro definida me estaba costando entenderlo, sí que había usado ya conts MAX_N = 10 pero no diferenciaba esta vez que podía salir al paso con las funciones (gracias!).
De verdad que ahí sí que me había atascado y no me salía como hacer rular A(i,j) (A[i*n_A-i*(i+1)/2+j])

El que el make no necesitaba que le pasaran el tamaño no lo sabía, si que vi que al compilar me apuntaba ahí y al final le puse *sizeof(double) y continuó sin volverlo a mencionar.

Lo de usar el vector y definir la tabla es despiste mio, jeje.
El free(A) entiendo que no lo necesita al tener Go recolector de basura.

Ahora me voy a programar los ejemplos que me has pasado, compararé el ejercicio original con la opción de la tabla y el triángulo inferior.

Este es mi primer programa que hice en Go el otro día con matrices y multiplicándolas, las introduce el usuario pq quería ver esta opción (aunque no es muy recomendable ya que estás un rato fijando los valores de filas-columnas, también lo realicé fijas, ah! y les he puesto medición de tiempo, fíjate al final como te dice el tiempo que ha tardado, por ejemplo: 3us, que no acabo de entender si eso son 3 unit seconds o es otra unidad de tiempo...

http://play.golang.org/p/aOk8kmIv77

Ya que en verdad, para medir tiempos me gustaría un resultado como con OpenMP:

(server-lliurex)(ds mar 23) *Inés* > time ./matrices 100
100    0.001221

real    0m0.003s
user   0m0.004s
sys    0m0.000s

Muchas gracias, Zorion.
No conozco a nadie físicamente que sepa programar en Go y que me ayudes lo agradezco mucho.

[Zorion]

​Hola Inés,​

P

​ues creo que ya has programado más Go que yo. 

​Mucho gusto en poder ayudarte ;)​

​Ojo con lo de declarar i,j,k y redeclaralas.

Si escribes for i:=0;i<N;i++ estás declarando i (por tanto se redeclara

 y oculta la definición original).

Si no quieres re-declarar "i" puedes escribir tu "for" así: for i=0;i<N;i++{

​

Lo de los "us" creo que son microsegundos, 1microsegundo=1000nanosegundos.

Puedes pasar a nanosegundos tu función "from" para estar seguros:

func from(t0 time.Time) {

fmt.Println(time.Now().Sub(t0).Nanoseconds())

}

Ten en cuenta que estás midiendo el tiempo de llamada del from, no has evaluado el tiempo total del programa ni de la ejecución.

No entiendo tampoco para qué pones un "defer" en la función "empty".

El defer sirve para ejecutar al final de una función la función diferida.

​Además ten en cuenta que si pones varios "defer" se ejecutarán en orden inverso al final de la función.​

​

Por curiosidad, ¿Has probado el tour de go?, 

​es muy rápido y creo que te ayudará a pasar de C a Go.​

Puedes encontrar versiones en inglés castellano y catalán en los enlaces de abajo ;)

[en] tour.golang.org

[es] go-tour-es.appspot.com (está en revisión)

[ca]​ go-tour-ca.appspot.com

​Saludos

Zorion​

[ines...@gmail.com]

Lo cierto es que "intento" programar en Go.
Me conozco el tour, lo que hecho de menos son más cosas en español (no el tour, que ya vi su traducción), más documentación, ejemplos, ejercicios, etc.
(Tengo el manual de Roberto y muchos documentos más) pero al ser joven le falta más extensión. - Tiempo al tiempo-
Lo que sí veo que se te da muy bien la programación y los cálculos (por la matriz anterior)
¡ Y menos mal que estabas ahí !

Pasaré a nanosegundos con tu función, el utilizar el time será para añadirlo entre las goroutines o las funciones con el problema a testear:

func testeando_matriz() {
    defer from(time.Now())
    for j := i; j < n_A; j++   {
    ...
 }
}

testeando_matriz()

Y de ahí viene el defer, que entendí en esta función como: " captura el tiempo actual en el punto de defer" ;)

Bueno, son pruebas pero que tienen que ser reales al final así que a ver por dónde me sale.
¿Qué tal llevas los hilos en Go? (jejeje)
Gracias de nuevo.
:)

[Zorion]

Ahora entiendo lo del defer. Me parece buena idea. Así mides el tiempo de la función "testeando_matriz()".

No lo entendía en la función "empty()" pero ahora ya te sigo.

Fíjate que si pones un "defer from(time.Now())" antes de pedir los datos al usuario ese tiempo también lo incluye pero si lo pones justo después de pedir los datos te mide correctamente (creo) lo que tarda en multiplicar las matrices.

Lo único que sé de hilos en Go es usar gorrutinas.

En C llegué a usar hilos tanto para linux como para Windows, pero tendría que revisarlo, justo recuerdo que usaba fork() y pipes en linux y que Windows era un follón de handlers, poco más.

Tú pregunta lo que quieras, si puedo te ayudo ;)

2013/3/24 <ines...@gmail.com>

[ines...@gmail.com]

Nas Zorion

El  defer() parece que tiene mucho juego con esto de ejecutar una función cuando la global termina la suya.
Lo pondré próximo para medir lo que tarda en multiplicar que es cuando más cerca estaré de comparar tiempos con C.
Pues voy a empezar con los hilos ---> runtime.GOMAXPROCS()

** Fijate qué documento interesante acabo de encontrar :

http://renzhi.ca/2012/04/04/concurrency-performance-comparison-between-erlang-and-go/

 y si le digo 1000 en mi pc:

(server-lliurex)(dl mar 25) *Inés* > go run hilos.go 1000
Number of threads: 1000
Available cpu: 4
Total time: 5.875ms
Average   : 5.875000 microseconds

( y los tiempos los controla, jejeje, aunque lo tengo que traducir)

[ines...@gmail.com]

Pues tras las fiestas de pascua todo vuelve al sitio y vuelvo a medir tiempos.
Espero que lo hayáis pasado bien y disfrutarais de las  vacaciones.

Zorion, al final el código original queda así:

http://play.golang.org/p/0cJAjmqdVz

He pasado a nanosegundos la función para ver cómo saca el tiempo y lo muestra así.

(dj abr 04) *Inés* > go run medicionMatriz.go 1000

2000

720855000

-->Sin pasar a nanosegundos:

(dj abr 04) *Inés* > go run medicionMatriz.go 1000

2us

725.362ms

En C, esta misma matriz de 1000 me da estos segundos:

(dj abr 04) *Inés* > ./medicionMatriz 1000
1000    0.483361

Me gustaría más acercarme a medir en Segundos...

[Zorion]

Hola Inés,

>
> Me gustaría más acercarme a medir en Segundos...

Para pasar de nanosegundos a segundos conviértelo a decimal y divide por 10^9
fmt.Printf("%fs\n",float32(time.Now().Sub(t0).Nanoseconds())*1E-9)

Por cierto, en caso que suba de un segundo no sé que pasará con los
nanosegundos, deberías leerte el manual o hacer pruebas para saber si
"nanosegundos" siempre es menor que 10^9. Va a ser que sí pero mejor te aseguras.

Espero que te ayude ;)

Parece que el programa en go es un 50% más lento que el de C (si mis
cálculos son acertados).

Saludos

Zorion

[ines...@gmail.com]

Gracias Zorion !!
Si tengo un rato hoy lo comprobaré (revisaré si pasa de un segundo qué hace)
En tal caso, si, es más lento que C (que ya se sabía) ... ¿crees que se podría hacer algo para que fuera más rápido? quiero decir, ¿añadir una goroutine? pq hilos quiero probar en otro ejemplo, pero si vale, vale.
¡Buenos días!

[ines...@gmail.com]

Ya lo he probado  y funciona bien al pasar nanosegundos a segundos.
Lo que sí, cuando son matrices más grandes, debería diferenciar los  minutos de tantos segundos... puede que revise esto.
En C: 5000 58.7589  en Go: 5000 90.074471s
Mirando de nuevo varios  tiempos de varias matrices, creo que en esta parte justamente ronda un 30% más lento que C.
... ^_^ no es una carrera, pero lo dicho anteriormente, estaría bien adelantar en algo con goroutines e hilos.

[Zorion]

Hola,
Yo considero que pasar de 60s a 90s es un 50% más lento.
Para hablar del 30% diría que el programa de C es un 30% más rápido que el de Go.

Es un tema de convenciones (cuál ponemos como base de comparación) y yo no lo he consensuado con nadie, no sé si mi punto de vista es correcto y/o compartido…

Podríamos preguntar la opinión del resto de Gophers. Me parece una encuesta interesante ;)
¿Alguien se anima a dar su opinión?

[ines...@gmail.com]

A mí me interesa precisar un poco más este tema.
Ya que he realizado más ejercicios con tiempos pero no comparando con lo mismo en C.
Bueno, he utilizado OpenMp, así que voy a mirar con goroutines.

:)

[Roberto Costumero Moreno]

Efectivamente, como dice Zorion, la mejora siempre es relativa.

En tu caso Go es un 50% más lento que C, utiliza un 150% del tiempo, o C es un 33% por ciento más rápido que Go.

Es muy importante para validar los resultados científicos saber bajo qué medida se realiza la comparación, ya que si no se pueden invalidar los mismos y esto es una convención social y debe realizarse así.

Un saludo,

Roberto

2013/4/6 <ines...@gmail.com>

[ines...@gmail.com]

Vaya, entonces es bastante lento comparándolos...
Las características de este equipo no son obsoletas y sin embargo es mucho tiempo de diferencia.

En el caso de mejorar algo en estos tiempos con Go, añado una Goroutine delante de la función de medición para probar pero no hace ni caso (cuando digo ni caso, es que no me muestra nada por pantalla), no sé si no he entendido bien su funcionamiento...

func main() {
    go medicion_matriz()
}

También he probado a añadir runtime.GOMAXPROCS(2) dentro de la función medicion_matriz.
^_^

[Carlos Canaza Ayarachi]

Creo que tienes que hacer uso de channels http://tour.golang.org/#63

[ines...@gmail.com]

Gracias jcca, entiendo que los canales son para comunicar goroutinas y me lo estoy mirando.
Trato de acortar el tiempo que me ha dado de calculo.

Zorion --> Acabo de encontrar un "temporizador" de sólo 3 líneas que sí me añade los 60 segundos en su minuto !!! Ni hace falta defer, ni el calculo de nanosegundos a segundos,  ni nada... (el truco era el time.Since)  ¡Ya podía haberlo descubierto hace un mes que rondo con los tiempos!

     empieza_el_tiempo := time.Now()
     tic tac tic tac
     paramos_el_tiempo := time.Since(empieza_el_tiempo)
     fmt.Println(paramos_el_tiempo)

Y aulá:  5000  1m31.503181s !!!

[Zorion]

Es posible que ese temporizador te muestre 2us de nuevo si mides tiempos muy pequeños (que era tu queja inicial).

Entiendo que el defer era un poco de syntax sugar.

Respecto a lo de enviar la medición a una gorrutina, el problema es que tu programa acababa y ya. No hacía nada con las matrices.

Para eso tendrías que por lo menos esperar en el main a que acabara la gorrutina (con un canal, por ejemplo, como dice Carlos), pero de todos modos no te sirve para mejorar tiempo.

Las gorrutinas te pueden ayudar si paralelizan algo, que no es el caso de:

func main() {
    go medicion_matriz()

    //Si no metes aquí nada para sincronizar el programa acaba sin necesidad de llamar a medicion_matriz()
}

Saludos

Zorion

2013/4/7 <ines...@gmail.com>

[ines...@gmail.com]

Sabiendo como quedan los tiempos pequeños ya entiendo su medición ;)
Tampoco estuvo mal descubrir algo más del defer, pero prefiero menos código.

Si en el calculo de las matrices no voy a conseguir mejorar el tiempo pues ... casi que lo dejo así.  :/
Una pena, ya que me parece mucho un 50% más de tiempo que C.
¿Quiere decir esto que haga lo que haga, todo será 50% comparado con C, aunque sea con paralelización, etc?

Si alguien más del foro ha medido tiempos con C imagino que le habrá dado algo parecido (aunque todo depende, a más maquina ambos programas más veloces,etc)

[Antonio Pardo]

Buenas,

El 20/03/13 14:37, ines...@gmail.com escribió:

ya es un poco tarde para responder a esto, pero para que quede en el
archivo ahí va.

Este documento lo leí hace poco y me pareció muy didáctico. Explica tus
dudas con $GOPATH

https://github.com/alco/gostart

Saludos

[ines...@gmail.com]

Gracias apardo por tu aporte.
Me lo miraré próximamente.
Un saludo.
:)