LINUX.ORG.RU

JIT GO как правильно готовить?

 


0

4

Время выполнения в среднем ~7 секунд на моем ПК

import datetime
map1 = {}
map2 = {}
print(datetime.datetime.now())
for x in range(0,10000000):
  map1[x] = x
for x in range(0,10000000):
  map2[x] = map1[x]
print(datetime.datetime.now())
Время выполнения в среднем ~9 секунд на моем ПК
package main
import (
	"fmt"
	"time"
)
func main() {
	var (
		mat1 map[int]int
		mat2 map[int]int
	)
	mat1 = make(map[int]int)
	mat2 = make(map[int]int)
	start := time.Now()
	for i := 0; i < 10000000; i++ {
		mat1[i] = i
	}
	for i := 0; i < 10000000; i++ {
		mat2[i] = mat1[i]
	}
	end := time.Now()
	fmt.Println(start)
	fmt.Println(end)
}
c# за 2 сек справляется

так вот, Go компилируемый язык, JIT технология и все такое. Почему он медленнее Python? Хотя если посмотреть http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... и http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... то можно увидеть что все хорошо. Отсюда сделал вывод, что я что то не так делаю. Подскажите как скомпилить правильно на Go?


так вот, Go компилируемый язык, JIT технология и все такое. Почему он медленнее Python?

Какой ещё JIT в Go?

Хм-м. У меня Python справляется то за 9 секунд, gccgo примерно за 8. При перезапуске Python справился за 7, gccgo опять за 8.

ИМХО, этот тест упрётся в скорость выделения памяти операционной системой, а не во время расчётов, поскольку на каждые несколько элементов карту надо увеличивать в размерах.

c# за 2 сек справляется

Наверняка не обошлось без какой-нибудь мощной оптимизации, вроде создания всей этой таблицы на этапе компиляции. Однако сработает ли это в реальной жизни, а не на таком синтетическом примере?

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 1)
Ответ на: комментарий от anonymous

Причем в go map не потокобезопасный.

А в Python он что, потокобезопасный? Хотя бы по спецификации?

(потому что на практике в CPython вообще GIL)

proud_anon ★★★★★
()

Больше похоже на косяк в gc Go, т.к. в gccgo все ок:

$ gccgo-4.7 t.go
$ ./a.out 
2014-02-23 01:18:45.011756 +0400 MSK
2014-02-23 01:18:47.534696 +0400 MSK
Ну, именно поэтому и пилят два конпелятора.

cx ★★
()
Последнее исправление: cx (всего исправлений: 1)
Ответ на: комментарий от cx

Ну и как у тебя это получилось?

me@mybox ~/test/map2 % gccgo-4.7 -o map2 -O3 map2.go
me@mybox ~/test/map2 % ./map2
2014-02-22 22:26:45.329217 +0100 CET
2014-02-22 22:26:51.225388 +0100 CET
me@mybox ~/test/map2 % gccgo-4.8 -o map2 -O3 map2.go
me@mybox ~/test/map2 % ./map2                       
no debug info in ELF executable errno -1
fatal error: no debug info in ELF executable
me@mybox ~/test/map2 % gccgo-4.8 -g -o map2 -O3 map2.go
me@mybox ~/test/map2 % ./map2                          
2014-02-22 22:27:12.288527 +0100 CET
2014-02-22 22:27:19.906841 +0100 CET

proud_anon ★★★★★
()
Ответ на: комментарий от proud_anon

~25 сек

for i in 0..10000000
  map1[i] = i
end
for i in 0..10000000
  map2[i] = map1[i]
end
~40 сек
0.upto(10000000) do |i|
  map1[i] = i
end
map1.each do |val|
  map2[val] = map1[val]
end
так, что выделение памати ОС может быть не причем // ужс на сколько Руби тормоз((

RA
() автор топика
Последнее исправление: RA (всего исправлений: 1)
Ответ на: комментарий от proud_anon

Хотя бы по спецификации?

AFAIK jython, в котором нет GIL, учитывает «атомарное» поведение cpython dict'а

anonymous
()
Ответ на: комментарий от proud_anon

Как и в первый раз, лол.

c0@c13 ~/t$ gccgo-4.7 -o map2 -O3 map2.go
c0@c13 ~/t$ ./map2
2014-02-23 01:35:57.629473 +0400 MSK
2014-02-23 01:36:00.160835 +0400 MSK

c0@c13 ~/t$ gccgo-4.8 -g -o map2 -O3 map2.go
c0@c13 ~/t$ ./map2
2014-02-23 01:37:00.391836 +0400 MSK
2014-02-23 01:37:04.499434 +0400 MSK

c0@c13 ~/t$ go build map2.go
c0@c13 ~/t$ ./map2
2014-02-23 01:37:46.422518765 +0400 MSK
2014-02-23 01:37:54.372895591 +0400 MSK

cx ★★
()
Ответ на: комментарий от KRoN73

Угу, оно тут вряд ли при делах: https://github.com/Balancer/benchmarks-fib-obj/wiki/Результат-теста:-i3-2.2ГГц

Ну хорошо, но ведь при работе с картой, скорее всего, понадобятся realloc'и, в т.ч. копирование данных в памяти, а при создании объектов это в принципе необязательно.

proud_anon ★★★★★
()

Это не го медленней питона, это реализация хэш таблиц медленней. Которые и там и там на си писаны.

anonymous
()
Ответ на: комментарий от anonymous

Так и знал что это из-за тормозного си питон тормозит.

PolarFox ★★★★★
()
Ответ на: комментарий от cx

Собрал из исходников gcc 4.8.2, всё равно 8 секунд получается. Но хотя бы теперь флаг -g указывать не нужно.

Впрочем, gc показывает вообще 13 секунд, а у тебя gccgo — 4 сек., gc — 8.

Предполагаю, что у тебя машина намного мощнее.

proud_anon ★★★★★
()
Ответ на: комментарий от proud_anon

Ну хрен знает, питоноверсия как и у ТС ~7-8 секунд.
Ноут, i5-3317U, Дебиан Джесси, gccgo из реп, gc go из последних сорцов и немного пропатчен.

cx ★★
()
Ответ на: комментарий от cx

У меня тоже ноут, Pentium 987 @ 1.50 Ghz (2 ядра), Mint 16 64-bit, gccgo пробовал из реп и собранный из ванильных исходников.

Впрочем, питоновая версия тоже примерно как у ТС.

proud_anon ★★★★★
()

Лол, sclang обгоняет и ваш го, и ваш педон

Date.getDate.postln;
a = 10000000.collect{|x| x};
b = a.collect {|x| x};
Date.getDate.postln
Sun Feb 23 08:49:22 2014
Sun Feb 23 08:49:27 2014
hvatitbanit
()
for i := 0; i < 10000000; i++ {
	mat2[i] = mat1[i]
}

это лучше заменить на

for i, x := range mat1 {
	mat2[i] = x
}

чуда не будет, но в gc слегка улучшает производительность, в gccgo — хз.

korvin_ ★★★★★
()
Ответ на: комментарий от hvatitbanit

Перепиши правильно оригинальный код — перестанет обгонять

var map1=();
var map2=();
Date.getDate.postln;
10000000.do{|x| map1[x]=x};
10000000.do{|x| map2[x]=map1[x]};
Date.getDate.postln
$ python t.py
2014-02-23 22:13:05.669962
2014-02-23 22:13:10.953456
$ sclang t.sc
...
Sun Feb 23 22:13:28 2014
Sun Feb 23 22:13:33 2014
anonymous
()

Вот он, очередной убийца Cи. Пока еще Питон обогнать не может, но обязательно победит Си! Мля, да Java/C# и то быстрее. А синтаксис! А возможности! Ну и говноедство.

jit нет у Go. Бери С++, C# или Java, не насилуй себя.

anonymous
()

А плюсы можешь у себя проверить:

#include <iostream>
#include <unordered_map>
#include <chrono>

using namespace std;
using namespace std::chrono;

int main() {
	auto start = system_clock::now();
	unordered_map<int, int> map1, map2;
	for (auto i = 0; i < 10000000; ++i)
		map1[i] = i;
	for (auto i = 0; i < 10000000; ++i)
		map2[i] = i;
	auto end = system_clock::now();
	std::cout << duration_cast<microseconds>(end - start).count() << "us\n";
	return 0;
}

anonymous
()

С преаллокацией мапов получается ~3.5 секунды на i5.

package main

import (
	"fmt"
	"time"
)

func main() {
	mat1 := make(map[int]int,10000000)
	mat2 := make(map[int]int,10000000)
	start := time.Now()
	for i := 0; i < 10000000; i++ {
		mat1[i] = i
	}
	for i, x := range mat1 {
		mat2[i] = x
	}
	end := time.Now()
	fmt.Println(end.Sub(start))
}
anonymous
()
Ответ на: комментарий от anonymous

21.4, с -O3 8.5

Вообще, продолжая тему Го и учитывая разницу производительности gccgo и go, мне кажется это недоработкой, которую просто не успели пофиксить. Вон 1.2 релиз принес ~30-40% прирост, вполне возможно что из следующего выжмут не меньше.

cx ★★
()
Ответ на: комментарий от anonymous
end := time.Now()
fmt.Println(end.Sub(start))

=>

fmt.Println(time.Since(start))

korvin_ ★★★★★
()
Ответ на: комментарий от cx

Вообще, продолжая тему Го и учитывая разницу производительности gccgo и go, мне кажется это недоработкой, которую просто не успели пофиксить. Вон 1.2 релиз принес ~30-40% прирост, вполне возможно что из следующего выжмут не меньше.

Если не ошибаюсь, кто-то из разработчиков Go говорил, что они просто еще особо и не занимались оптимизациями в компиляторе gc, до версии 1.0 единственной важной целью была стабилизация языка и стандартной библиотеки. Так что да, ждем следующих улучшений.

korvin_ ★★★★★
()
Ответ на: комментарий от anonymous

Ну дело не только в длине. Как-то симпотичнее на крестах. Не думал, что я такое когда-нибудь скажу. Go какой-то укуренный язык

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.