Заур
В остальных тестах, кроме регулярок, +- на уровне плюсов и rusta
Anonymous
Ну можешь оптимизировать:
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=go&id=4
Заур
Ну можешь оптимизировать:
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=go&id=4
Так знай я в чем причина, так и сделал бы 😀. В продакшене так кончено никто не будет писать, но интересно почему такая разница.
Anonymous
Как у Go с хвостовой оптимизацией рекурсивных вызовов?
Вот это:
func bottomUpTree(depth int) *Node {
if depth <= 0 {
return &Node{nil, nil}
}
return &Node{
bottomUpTree(depth-1),
bottomUpTree(depth-1),
}
}
Можно развернуть в цикл например, если у него с этим не очень
Anonymous
Можно еще переписать WaitGroup на атомики.
Посмотрел реализацию C++
Так они там используют OpenMP + Apache Portable Pool - не самый быстрый способ работы с парралельным кодом, так что там все еще быстрее может быть
Заур
По-моему проблема раскрытия рекурсии в цикл в том, что по условию нельзя хранить узлы ни в каких арраях и т.п. структурах данных
Заур
http://benchmarksgame.alioth.debian.org/u64q/binarytrees-description.html#binarytrees
Alexander
http://benchmarksgame.alioth.debian.org/u64q/binarytrees-description.html#binarytrees
В целом главная проблема - сборка мусора. Это плата за удобство программирования
Alexander
Простым добавлением debug.SetGCPercent(1000) в код бенчмарка я уменьшил время выполнения в два раза. При этом расход памяти вырос в 5 раз.
Alexander
Совсем отключить сборщик мусора не получится, т.к. памяти нужно будет слишком много и всё сэкономленное время уйдёт на ввод-вывод при свопе
Заур
Вот оно что.
Заур
А разница с c# и java это разница оптимизации работы сборщиков?
Mike
А разница с c# и java это разница оптимизации работы сборщиков?
ну вообще еще язык приятнее у шарпов, много сахара приятного и параллельности с корутинами
Заур
ну вообще еще язык приятнее у шарпов, много сахара приятного и параллельности с корутинами
Так чё же они не добавили сахара в go, если это так ускоряет всё 😁😁
Anonymous
Хотя смотрю атомики не сильно меняют картину в Go
https://play.golang.org/p/PbTS6BmY6hU
Anonymous
Кстати почему play.golang.org не выводит время? Оно всегда нулевое
Slava
Оптимизация такая
Slava
Там время виртуальное
Slava
И детерменированное
Slava
Как и рандом ;)
Anonymous
Рандом везде детерменинрован, если мы говорим о псевдослучайных генераторах, а не скажем рандом байтов в криптографии
Anonymous
Кстати, как простенький рандом сваять в одну строку? Желательно как-то так:
r := int(random(timestamp))
Anonymous
random := rand.New(rand.NewSource(time.Now().UnixNano()))
r := strconv.Itoa(random.Intn(math.MaxInt32))
Anonymous
Не знаю, может можно и проще, но это какой то пи** извиняюсь, даже в Си проще с этим
Anonymous
Anonymous
Можно чуть проще:
rand.Seed(time.Now().UnixNano())
r := strconv.Itoa(int(rand.Int31()))
Mike
а читалки /dev/urandom нет?
Anonymous
а читалки /dev/urandom нет?
Используй "crypto/rand" пакет
b := make([]byte, 16)
if _, err := rand.Read(b); err != nil {
fmt.Println("error:", err)
return
}
fmt.Println(b)
Anonymous
Проверка на err обязательна, так как буфер с энтропией может быть пустым
Заур
Вот этот момент немного не понял. А почему те же c# и джава тоже в разы быстрее отработали? Это как-то связано с тем, что они интерпретируемые или просто лучшая оптимизация из-за возраста?
Заур
2.5 секунды плюсы
34 (!) секунды голанг
Задание сгенерировать Бин дерево и посчитать количество узлов для каждой глубины
Заур
В целом главная проблема - сборка мусора. Это плата за удобство программирования
Slava
Вот этот момент немного не понял. А почему те же c# и джава тоже в разы быстрее отработали? Это как-то связано с тем, что они интерпретируемые или просто лучшая оптимизация из-за возраста?
они не интерпретируемые, а компилируемые в байткод
Slava
возможно тут JIT помог
Daniel
сложнее, чем "компилируемые в байткод"
Daniel
jit тут помог не быть тормозным
Daniel
тут два моммента
Daniel
1. оптимизатор в go довольно убогий. и будет таковым оставаться, ибо для 99% задач, которые решают на go, оптимизатор просто не нужен
2. разница 2.5 и 34 секунды означает только одно - "структура данных плохо влезает в кеш процессора". или большая, или разбросана по памяти, или предсказатель ветвлений ее не понимает. если, например, взять ту же структуру, что использовалась в c++ - разрыв может сократиться
Заур
Понял, спасибо)
Vladimir
Надо на код задачи ещё смотреть :)
Vladimir
/report
Vladimir
@onokonem @m0sth8 тут какая то нездоровая хрень у человека творится
Anonymous
Сколько уже спамеров забанили за историю группы?
Мерль
🏁Александр
Andrew
Grisha
Евгений
Коллеги, кто как, свои приложения в продакшен заводит?
Да смотря куда. Если что-то сложное, важное - докер.
Для веб-игрищщ завел себе акк не heroku. Деплой идет бинарем через отдельный гит-реп (чтобы основной с кодом не замусоривтаь).
1. компиляю у себя CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o ../project-heroku/bin/app
2. git add .
3. git push heroku master
Может не очень красиво, что бинарь в гит кладу, но получается простой быстрый деплой в одну команду make
Евгений
Anonymous
Vladislav
Евгений
Проверка на err обязательна, так как буфер с энтропией может быть пустым
Он может вычитать меньше байт, чем я заказал?
Я на всякий еще проверяю длину полученного.
Grisha
вендор в корне, бин тоже - норм.
Чем плохо?
Меня пакеты смущают что рядом, может их в pkg или вообще в vendor в отдельные репы.
Grisha
Вендор должен быть в корне проекта и управляться с помощью менеджера зависимостей, например dep.
Там в качестве менеджера glide
Евгений
вендор норм - как раз в отдельной папке все рядом и не лезет по всему проекту
Евгений
я использую dep (и вроде как он рекомендован для всех новых проектов)
- в корне проекта 2 файла Godep.toml `и `Godep.lock - в них описаны все зависимости
- так же папка vendor - в ней лежит исходный код проектов нужных версий, согласно файликам.
Да. vendor лежит в .gitignore и не коммитится в проект - он нужен только на рабочей машине для сборки
Vladimir
я использую dep (и вроде как он рекомендован для всех новых проектов)
- в корне проекта 2 файла Godep.toml `и `Godep.lock - в них описаны все зависимости
- так же папка vendor - в ней лежит исходный код проектов нужных версий, согласно файликам.
Да. vendor лежит в .gitignore и не коммитится в проект - он нужен только на рабочей машине для сборки
правила хорошего тона требуют закоммитить vendor тоже
Евгений
Если я кладу по каким-то причинам бинарники в bin в проекте, то он у меня в игноре.
Vladislav
правила хорошего тона требуют закоммитить vendor тоже
Вот неправда. Там есть плюсы и минусы. А там каждый сам решает.
Евгений
правила хорошего тона требуют закоммитить vendor тоже
Зачем? На случай, если у нас оторвется внешний источник и мы не сможем больше скачать?
Vladimir
Зачем? На случай, если у нас оторвется внешний источник и мы не сможем больше скачать?
точно. Гит историю ту же можно переписывать
Vladimir
или просто грохнуть проект
Vladimir
сделает умный человек форс пуш и нет коммита
Vladimir
по глупости например
Евгений
Мне кжется, более правильно поднять гит-копии использованных проектов, чтобы и код можно было достать и не замусоривать свой проект
Евгений
но это конечно сложнее
Евгений
Либо, если все на гитхабе, то форкаешь проект - и у тебя своя копия зависимости. Что там случилось с исходной версией, тебе не важно. Периодически, когда обновляешь зависимости затаскиваешь изменения в свой форк. Нашел серьезный баг - исправил у себя, отправил пулл-реквест.
На той стороне чувак будет морозиться - ну и хрен с ним, у тебя код работает. Если очень будут нужны его новые изменения, то тащишь и мерджишь.
Но, если чел морозится по пустякам, но наврядли в проекте появятся какие-то суперполезные изменения.
Vladislav
Либо, если все на гитхабе, то форкаешь проект - и у тебя своя копия зависимости. Что там случилось с исходной версией, тебе не важно. Периодически, когда обновляешь зависимости затаскиваешь изменения в свой форк. Нашел серьезный баг - исправил у себя, отправил пулл-реквест.
На той стороне чувак будет морозиться - ну и хрен с ним, у тебя код работает. Если очень будут нужны его новые изменения, то тащишь и мерджишь.
Но, если чел морозится по пустякам, но наврядли в проекте появятся какие-то суперполезные изменения.
Каждый проект форкать такое себе. Да и в случае если ты не один работаешь, то нужно акк компании на гитхабе делать?
Евгений
Не обязательно. Мне никто не запрещает сделать бесплатный публичный форк открытых проектов на GH.
А дальше в своей закрытой репе, которая вообще лежит даже не на ГХ я импортирую нужные мне зависимости.
go get и dep штуки умные - они без проблем мне вытаскивают все нужное из разных источников.
Евгений
Если компания не хочет закрывать копии своих репов, то без проблем можно сделать бесплатный акк компании и туда все сотрудники будут класть. Тогда, если кто уволится, то все равно все сорцы останутся в том же самом месте.
Vladislav
Не обязательно. Мне никто не запрещает сделать бесплатный публичный форк открытых проектов на GH.
А дальше в своей закрытой репе, которая вообще лежит даже не на ГХ я импортирую нужные мне зависимости.
go get и dep штуки умные - они без проблем мне вытаскивают все нужное из разных источников.
Вот сделал ты форк. И ушел из компании. И решил форк удалить.
Евгений
только что ответил )
Vladimir
кстати, если я правильно помню, удаление оригинальной репы ведет к удалению всех форков
Евгений
для публичных беслпатных?
Евгений
тогда можно неаккуратно полгитхаба разломать