Пожалуй в данном вопросе стоит начать с того, что CPU-арифметика никак не сильный конёк перла. (Кстати, удивлён, что никто не затестил CUDA) Во вторых - CPU-intensive задачи выгоднее решать именно в синхронной модели. Асинхрон рулит только тогда, когда переключение контекста планировщиком OS становится дороже, чем “ручное" управление контекстами при помощи event-машины.
Ну и в третьих, хотелось бы спросить: какое отношение данная задача имеет к реальной жизни? -- Mons Anderson <[email protected]> > On 9 февр. 2015 г., at 16:11, Михаил Монашёв <[email protected]> wrote: > > Здравствуйте, Mons. > >> Народ, я не осилил дочитать это всё до конца. >> А давайте-ка соберёмся и померяемся. >> Не в плане теории, а в плане конкретных чисел >> сравним разные языки, подходы и т.п. > > А собираться обязательно? Можно ведь и удалённо. Я на Go пишу всего > месяц и мне было бы сложно придти и что-то нормально на нём написать > за малое время. Но сравнить языки было бы интересно. > > Предложу простую задачку, которая покажет, насколько хорошо язык > работает с памятью: сложить все значения массива, состоящего из > 10000000 целых чисел. Код там простой: создаём массив, заполняем его, > замеряем время, потом в цикле складываем элементы массива, снова > замеряем время и выдаём результат. Вот мой вариант на Go: > https://play.golang.org/p/iHGG3nV10L > > Тонкости: в песочнице код съедает много процессора и время там всегда > одно и то же, поэтому его надо сохранить в файл, например main.go и > потом запустить вот так: go run main.go > Скомпилировать в исполняемый файл можно вот так: go build main.go > А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go > Скачать Go можно вот тут: http://golang.org/ > > -- > С уважением, > Михаил mailto:[email protected] > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
