Google Go vs. Си

Комментарий для Евгения Степанищева:

Зачем нужно убирать время компиляции и убирать вывод на экран, если первое всё равно чувствительно для пользователя, а второе есть в задаче?

Первое чуствительно для пользователя, если он перед каждым запуском функции компилирует в байткод. Это может быть и не так, если у него процесс в памяти висит, и выполняет много задач подряд, а не одну.

Зачем нужно убирать время компиляции и убирать вывод на экран, если первое всё равно чувствительно для пользователя, а второе есть в задаче?

Возможно потому, что если ваша задача выполняется не 0.5 секунды, а хотя бы минуту, то время компиляции будет вносить значительно меньшую погрешность.

Комментарий для Евгения Степанищева:

Зачем нужно убирать время компиляции и убирать вывод на экран, если первое всё равно чувствительно для пользователя, а второе есть в задаче?

Поскольку я вижу в самой заметке:

померить языки программирования на каком-нибудь несложном алгоритме

Чтобы померить время холодного старта достаточно hello world, к чему городить огород с алгоритмом? Только вот к языкам программирования это не имеет ни малейшего отношения. И, кстати, подсчет времени в коде я углядел в php версии. По-моему кто-то что-то недоговаривает :)

Опять же:

Для сравнения выбрали решето Эратосфена для поиска простых чисел

Не думаю что вывод на экран имеет отношение к поиску простых чисел. Если бы выбрали для сравнения вывод n чисел на экран тогда другое дело.

PS: разумеется компиляция не в байткод а из него.

Комментарий для Евгения Степанищева:

Хотя, если

Да кому оно интересно, голое время работы алгоритма?

тогда конечно да. Мерить языки программирования временем старта интерпретатора/виртуальной машины и компиляции/интерпретации куда как увлекательнее. Особенно в сравнении с теми языками где оных нет.

Комментарий для Евгения Степанищева:

Не нужно относиться к этому как к серьёзному исследованию

нас хлебом не корми, дай копья поломать :)

Что за дискриминация? :)

никакой дискриминации, согласен с предложением.
более того, полагаю что выигрыш во времени у java версии по сравнению с си в моем сравнении вероятно именно этим и обусловлен. я действительно был удивлен результатами. к сожалению я не на короткой ноге с си, поэтому не добавил подсчет времени в код си версии. но с удовольствием бы взглянул на результаты сравнения голых алгоритмов (и всё-таки я против вывода на экран :) )

Комментарий для Евгения Степанищева:

Ну так за чем дело встало? Компиляторы-то для всех платформ существуют :)

Можно и не компилировать самому:

— JavaScript (Rhino): http://ideone.com/Z3e1T  — время: 2.53 s, память: 214016 kB
— JavaScript (SpiderMonkey): http://ideone.com/E62qk  — время: 1.08 s, память: 5076 kB
— Perl: http://ideone.com/sBs9y  — время: 0.34 s, память: 4732 kB
— С: http://ideone.com/7VWx7  — время: 0.04 s, память: 1908 kB
— Go: не запустился (undefined: append)

Я сократил количество итераций до 20000, иначе для некоторых языков время выполнения превышало лимит.

Комментарий для Евгения Степанищева:

Тоже ведь неизвестно что там за версия.

Почему неизвестно? Версия указана.

Я тут начал изучать Forth и первой программой написал тот же самый алгоритм, чтобы сравнить перфоманс.
http://hastebin.com/raw/fiqigusano
Использовал gforth и сравнивал с вашими программами на си и питоне.

$ uname -a
Linux 3.0.0-16-generic #27-Ubuntu SMP Tue Jan 24 19:14:19 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
$ gcc -o prime-filter prime-filter.c
$ time ./prime-filter >/dev/null
real 0m0.759s
user 0m0.752s
sys 0m0.004s

$ python --version
Python 2.7.2+
$ time python prime-filter.py >/dev/null
real 0m19.904s
user 0m19.853s
sys 0m0.008s

$ gforth --version
gforth 0.7.0
$ time gforth prime-filter.fs >/dev/null
real 0m7.815s
user 0m7.796s
sys 0m0.000s
$ time gforth-fast prime-filter.fs >/dev/null
real 0m4.537s
user 0m4.516s
sys 0m0.008s

man gforth:

gforth-fast is the same as gforth, except that it does not support accurate backtraces for signals, and is faster by up to a factor of 2. Use it for debugged, performance-critical programs such as benchmarks.

package main
func main() {

x := []int{2}
for i := 3; i < 200000; i += 2 {
for _, j := range x {
if i%j == 0 {
break
}
}
x = append(x, i)
}
println(x)

}

Вообще то да, это не решето решето Эратосфена.

Вот мои результаты питона (так как я пишу на нем)

python name.py 23,33s user 0,04s system 99% cpu 23,447 total

И результаты с Гоу (так как хочу его изучать)

./name 0,83s user 0,00s system 96% cpu 0,863 total