Если это код с циклами на Rust, то он в два раза медленне того, наркоманского. И проигрывает по скорости коду на Go.

Вероятно это не так, компилятор rust довольно хорошо умеет в оптимизации https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractions

Народ) Делаю сервер, который будет держать map из вебсокетов, разделенных по каналам. Подскажите, будет ли вот так Map работать конкуррентно? https://play.golang.org/p/67_thvSxFT

с блокировками — будет работать

а как по производительности? Сильно скажется?

а как по производительности? Сильно скажется?

бенч же легко написать

так было бы с чем сравнивать)

так сравнить вариант с блокировкой и без, узнаешь на сколько просядет

Если это код с циклами на Rust, то он в два раза медленне того, наркоманского. И проигрывает по скорости коду на Go.

ты ведь конечно это проверял, а не просто так ляпнул? ) у меня го чуть медленнее (1.38 vs 1.25s)

ты ведь конечно это проверял, а не просто так ляпнул? ) у меня го чуть медленнее (1.38 vs 1.25s)

Код GO чуть медленнее чем извращенный на Расте.

Что и где я ляпнул?

го чуть медленнее чем тупое решение с циклами на расте

ляпнул про “в два раза” )

а где этот код на go?

а где этот код на go?

да там выше картинка

во

но там “ложь, пиздеж и провокация” ) код на расте делает что-то совсем другое, но цель была показать насколько страшные итераторы и вообще фп

ляпнул про “в два раза” )

Код с циклами на Расте в два раза медленнее кода с итераторами на Расте. Каким хуем в этом утверждлении Go упоминается?

Иди читай Растоманский блок: http://maxim.livejournal.com/494874.html

Код с циклами на Расте в два раза медленнее кода с итераторами на Расте. Каким хуем в этом утверждлении Go упоминается?

а, извини я думал ты с го сравниваешь

оу, максим записался в растоманы он же с эрлангом головного мозга

но там “ложь, пиздеж и провокация” ) код на расте делает что-то совсем другое, но цель была показать насколько страшные итераторы и вообще фп

Цель была написать быстрый код на Расте и он действительно процентов на 20% быстрее Го. Цена за это - взрыв мозга головы.

Цель была написать быстрый код на Расте и он действительно процентов на 20% быстрее Го. Цена за это - взрыв мозга головы.

ну нет же, тупой код на расте с циклами УЖЕ быстрее го

то что итераторы будут еще быстрее — окей

ну нет же, тупой код на расте с циклами УЖЕ быстрее го

Нет

maxim@kudzu:~/depot/voxoz$ time ./main-lpa 9999010000 real 0m0.085s user 0m0.068s sys 0m0.020s maxim@kudzu:~/depot/voxoz$ time ./main-go Sum: 9999010000 real 0m0.058s user 0m0.052s sys 0m0.004s maxim@kudzu:~/depot/voxoz$ time ./main-lpv 9999010000 real 0m0.052s user 0m0.044s sys 0m0.004s

Это не мои тесты, это адвокат Раста

мне кажется там количество итераций надо раз в 10 задрать, а то цифры такие (на грани погрешности)

Короче lpa - это циклы на расте, lpv - это сумашедший код

Нормальные циклы Rust - на 20% быстрее go

Я просил его запустить на 1.7.3 вместо 1.6 было бы чуть быстрее. Но он не стал, потому что был риск получить Go на первом месте.

Кто-то тоже самое делает на питоне и не перживает за производительность

да там выше картинка

а какая правильная сумма?

ну нет же, тупой код на расте с циклами УЖЕ быстрее го

Я перепутал lpa и lpv.

а какая правильная сумма?

9999010000

Питоном жаришь? :)

Питоном жаришь? :)

time ./c.py 9999010000 real 0m0.162s user 0m0.142s sys 0m0.019s

Сравнивай с Go

https://gist.github.com/begetan/a1db9fe3ccb2e93aa4350f66dd85a57b

Народ) Делаю сервер, который будет держать map из вебсокетов, разделенных по каналам. Подскажите, будет ли вот так Map работать конкуррентно? https://play.golang.org/p/67_thvSxFT

s.mux = new(sync.Mutex) - мьютекс не надо инициализировать. ЕМНИП.

Сохатский еще “тупой” код на расте написал странно там вектора можно инициализировать без цикла и второй вектор заполнять без push, это оптимизируется лучше

в общем калька с тупого кода на го работает лучше чем его тупой код на расте )

s.mux = new(sync.Mutex) - мьютекс не надо инициализировать. ЕМНИП.

Там указатель на мьтекс, он же nil по умолчанию

https://gist.github.com/begetan/a1db9fe3ccb2e93aa4350f66dd85a57b

ну да, го в 1.6 раза быстрее

Там указатель на мьтекс, он же nil по умолчанию

А, не заметил. Тогда не надо делать указатель на мьютекс:)

ну да, го в 1.6 раза быстрее

pypy ?

pypy ?

да

на самом деле разница даже меньше: 1.5 раза

Помнится заполнение хеш-массива псевдорандомом было в pypy в два раза быстрее чем в Go.

чтобы так сравнивать нужно убедиться что генераторы рандомов одинаковые

а то у одного будет быстрый тупой рандом, а у другого медленный но пригодный для криптографии

Эмм

какбы

питонячий рандом он какбы очень даже годный

там как только малейшие проблемы с безопасностью появляются все фиксится

Гошный рандом он какой ?

и да важно помнить что проблема pypy не в скорости

Проблема в том что память у меня не казенная

нет понятия “годный” рандом они почти все годные только каждый для своей задачи )

прекл в том что гошечка будет куда меньше питончика кушать память

и в том что в многих аспектах очень даже производительнее

ну и плюс корутинки и асинхронщина искаропки без костылей

ребят, вы код когда-нибудь пишите? или только спорите? просто интересно, как не загляну в чатик: 100 сообщений споров о том, кто круче го или ХХХХ (подставь яп) )))

все работают, просто периодично сремся

ERROR: S client not available

почему бы нет

логично

Гошный рандом он какой ?

у него два, есть быстрый в math и медленный в crypto

Помнится заполнение хеш-массива псевдорандомом было в pypy в два раза быстрее чем в Go.

Тут не хеш, а обычный массив

а как по производительности? Сильно скажется?

ну, в гудланге, после мерджа thread-safe мап, блокировки скажутся сильно, по скорости будет одинаково с go.

Проблема в том что память у меня не казенная

Нормально все у pypy с памятью

Javascript framework benchmarks. недавно на реддите пробегало)

Напоминает те же самые дискуссии разряда «Go против всех».

?

не самый интересный забег, там были более эпичные и непредсказуемые, например этот https://www.youtube.com/watch?v=RPClAUGj4S4

http://gobuffalo.io/docs/getting-started

вот почему все пилят веб фреймворки и почти никто не пилит гуи. приходится лабать на pyqt

вот почему все пилят веб фреймворки и почти никто не пилит гуи. приходится лабать на pyqt

libui есть

правда он сильно кастрирован

опять же можно go + qml использовать, я пробовал, но с фронтом не дружу вообще, хотя работает

qml это для мобилок. мне под десктоп. и вообще мне qml не нравится

Мне кажется, что на go будет не очень отзывчивый интерфейс

http://gobuffalo.io/docs/getting-started

awesome-go обновился?

qml это для мобилок. мне под десктоп. и вообще мне qml не нравится

это вам кто такую лютую неправду сказал?

что qml для мобилок?

не. я в курсе что он собирается и под десктоп. но подход к построению уи на мой взгляд заточен под мобилки

на десктопных приложениях qml выглядит не очень

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

какбэ из UI на контролах, по сути, один только GTK еще и выжил, и то условно

а в остальном - как бэ есть QtQuick.Controls

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

по сравнению с интерфейсами на html + css + js оно еще и шевелится

awesome-go обновился?

сам список — еще, вроде бы, нет

а сайт переделывать не планировали

а в остальном - как бэ есть QtQuick.Controls

это какой-то свежачок. ещё не щупал