«Go»: количество го-программ
It should be smarter and one day it will be smarter, but until it is if you want CPU parallelism you must tell
the run-time how many goroutines you want executing code simultaneously. There are two related ways to do this. Either run your job with environment variable GOMAXPROCS set to the number of cores to use (default 1); or import the runtime package and call runtime.GOMAXPROCS(NCPU).
В документации есть множество мест, где говорится, что сейчас планировщик
Возможно я ошибаюсь, но мне кажется очевидным, что значение этой директивы должно быть уж никак не меньше числа процессоров. Чтобы автоматически определять количество процессоров и указывать верное, по моему мнению, значение, я написал следующий код. Возможно ещё
package main
import ("syscall"; "runtime")
func main() {
if n, _ := syscall.SysctlUint32("hw.ncpu"); n > 0 {
runtime.GOMAXPROCS(int(n))
}
}
Комментарии 20
На уровне выполнения, это простой вызов sysctl, такой же как использует одноимённая утилита ( http://ru.wikipedia.org/wiki/Sysctl ). Этот вызов умеет очень многое рассказывать о системе, в том числе и про процессоры.
Кстати, этот код, конечно, не платформонезависим, под Windows вызова sysctl не существует, насколько я знаю.
с чего бы?
Программа, конечно, не будет подглючивать, просто выполняться будет медленнее, чем могла бы.
Кстати, под Windows можно проверить значение переменной окружения NUMBER_OF_PROCESSORS. Она точно есть со времён XP, возможно она была и раньше.
Комментарий для Евгения Степанищева:
Это число с учетом гипертрединга, скажем на i5 2 ядра, а NUMBER_OF_PROCESSORS равен 4. Выполнение приложение в 4 потока в таком случае будет не быстрее, чем в два. Впрочем, едва ли заметно хуже.
странно, Fritz Chess Benchmark показывает прирост производительности в 1.44 раза. и это у меня ещё относительно древний проц. а вы чем измеряли?
Комментарий для zg.livejournal.com:
Да накидал простой тест на яве, который делает много простых арифметических операций. При увеличении количества потоков с одного до двух производительность выросла почти ровно в 2 раза, до4-х или более -- осталась практически такая же, как с двумя.
На более сложных тестах, возможно, и правда будет прирост, не зря же этот гипертридинг вообще придумали.
Спасибо.
s/соответсвенно/соответственно/g
Комментарий для anonymouse:
Go сам убирает мусор, но не имеет деструкторов, к примеру, о закрытии файлов надо заботиться самостоятельно, хотя для этого есть удобные средства.
Плохо происходит, если честно. Я завершу эксперименты, ещё расскажу об этом.
В Go не процессы и даже не потоки, тамго-программы, правда на уровне системы эти го-процессы могут быть и потоками, но не обязательно, но это не процессы, в спецификации есть упоминание, что го-программы выполняются в одном адресном пространстве.
Евгений, я, наверное, не смог донести мысль и очень плохо задал вопрос.
Ужасно. Т.е. 'let it crash' метод в go не работает? И падениего-программы ведет к падению всего рантайма/утечкам памяти?
Извините, но я не понял. Поправьте, пожалуйста:го-программы выполняются параллельно в одном адресном пространстве => их || исполняют потоки ОС в рамках рантайма Go.как-то и как-то в рантайме должен производить планирование го-программ и раскидывание их по потокам рантайма.
1) Раз
2) Максимальное число этих потоков мы задаем, тогда
3) Раз адресное пространство шареное, то очевидны проблемы блокированием всего рантайма GC на время сборки.
Я просто пытаюсь сравнить с erlang, о внутренностях которого имею некоторое представление, и понять, что же такого есть в Go, чего нет в erlang, который изобрели 20 лет назад.
Комментарий для anonymouse:
Падениего-программы ведёт к вызову panic, вызов panic можно перехватить. По поводу утечек памяти пока ничего сказать не могу, литературы по этому поводу нет, а я пока не исследовал.
Не обязательно. http://ru.wikipedia.org/wiki/%D0%A1%D0%BE% … 0%BC%D0%B0
У Go есть плохенький планировщик.
Увы, пока ничего не могу сказать по этому поводу.
Не знаю, я Erlang не знаю, но в Go куда более привычный синтаксис.
Комментарий для mixa.livejournal.com:
Возможно, Ява не умеет распределять операции так, чтобы они могли хорошо выполняться на HT, там есть особенности. Кроме того, HT реализован так, что некоторые программы могут даже замедлиться.
Комментарий для Евгения Степанищева:
Спасибо, за ответы!
Это понятно и известно, но мы же говорили про «CPU parallelism» и я к сожалению не знаю, как сопрограммы «прикручиваются» к SMP, если подкините ссылок --- буду признателен!
В целом, ясно, что ничего не ясно :) Успехов в дальнейших исследованиях!
Комментарий для anonymouse:
Если начто-то наткнусь, то кину обязательно!