+

Объясните почему?

Объясните почему?

Что, почему?

Вопроса не понял.

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

Если я правильно понимаю, то дешевле указатели хранить чем копипастить туды-сюды.

Что, почему?

Почему лучше копировать чем передовать ссылку

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

Теоретически не должно копирование быстрее быть.

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

с современными процессорами хер поймешь, что им хорошо, а что не очень

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

Барьер памяти?

ага

А что это?

use google, Luk

А что это?

Ну может быть копирование блока памяти дешевле, чем обращение по длинному адресу. Но надо курить рантайм.

но, скорее всего, вопрос в том, что по значению оно оказывается в кеше за один запрос в память, а по ссылке - за два

и даже косвенным образом можно померять, вроде бы, потери на ожидание данных из памяти

в общем - надо бы раскопать

https://github.com/jmhodges/copyfighter

Если я правильно понимаю, то дешевле указатели хранить чем копипастить туды-сюды.

скопировать указатель конечно-же интуитивно кажется быстрее, однако Go GC замедляется по мере возраста колва указателей. Поэтому маленькие структуры, такие как webwire.Payload, в которой лишь слайс* и integer, лучше копировать * при копировании слайса копируется лишь маленький header а не сами данные

Passing by value often is cheaper Even though Go looks a bit like C, its compiler works differently. And C analogy does not always work with Go. Passing by value in Go may be significantly cheaper than passing by pointer. This happens because Go uses escape analysis to determine if variable can be safely allocated on function's stack frame, which could be much cheaper then allocating variable on the heap. Passing by value simplifies escape analysis in Go and gives variable a better chance to be allocated on the stack.

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

да, нужно benchmark'ить, однако всегда придерживаюсь правила: если указатель не нужен - не загрязняй GC

Интересно копирование, реально копирует или copy on write?

что касается escape analysis'а то да, однозначно лучше копия нежели указатель

скопировать указатель конечно-же интуитивно кажется быстрее, однако Go GC замедляется по мере возраста колва указателей. Поэтому маленькие структуры, такие как webwire.Payload, в которой лишь слайс* и integer, лучше копировать * при копировании слайса копируется лишь маленький header а не сами данные

непонятно какие структуры маленькие, а какие большие

это мерять надо

я с этим столкнулся на структурах в 256 байт

с современными процессорами хер поймешь, что им хорошо, а что не очень

Есть гайды от производителя

о. да

20 страниц мелким почерком

20 страниц мелким почерком

20? Мало

672 не хочешь?

это шуточка была. я последнее, что осислил - 386

https://www.coursera.org/learn/golang-webservices-1 https://www.coursera.org/learn/golang-webservices-2

кстати, зашел на этот курс и услышал, что го для реалтайма может не подойти, тут я вспомнил как на стачке в ульяновске кто-то рассказывал, что они сервер для игры писали на го

может не подойти из-за gc

где игры и где реалтайм

ну там ребята сервер для шутера писали

все еще ооочень далеко от реалтайма

кстати, зашел на этот курс и услышал, что го для реалтайма может не подойти, тут я вспомнил как на стачке в ульяновске кто-то рассказывал, что они сервер для игры писали на го

Ну знаешь, можно писать что угодно на почти чем угодно

Вопрос в колличестве дополнительного секса

Я видел в одной конторе rtb с временем ответа (target) людям в 2мс на Ди (тоже с гц язык)

кстати, зашел на этот курс и услышал, что го для реалтайма может не подойти, тут я вспомнил как на стачке в ульяновске кто-то рассказывал, что они сервер для игры писали на го

Для какого реалтайма? Для того что в RTOS или того, что называют реалтаймом в геймдеве (типа как можно быстрее)?

Я видел в одной конторе rtb с временем ответа (target) людям в 2мс на Ди (тоже с гц язык)

это худшее время ответа?

Для какого реалтайма? Для того что в RTOS или того, что называют реалтаймом в геймдеве (типа как можно быстрее)?

а вот этого я не понял, там без подробностей

т.е. го для гейм сервера вполне подойдет?

это худшее время ответа?

Типа у них slo для клиентов - принять решение не более чем за 2мс было

Ребятки, кто нибудь видел механизм очередей с такими критериями: - ограничение на максимальное количество заданий в общей очереди от одного пользователя (user ID); - и ограничение на максимальное количество одновременно выполняющихся заданий от одного пользователя. Есть что то готовое для таких условий?

И язык с gc

а вот этого я не понял, там без подробностей

Воооот. Навскидку сколько геймсерверов вспомнишь под QNX или какой-нибудь LynxOs?

т.е. го для гейм сервера вполне подойдет?

особенно для браузерного

т.е. го для гейм сервера вполне подойдет?

Как и любой другой язык с GC или без. Это все вопрос архитектуры, к тому же боттлнеком всегда будет сеть

где игры и где реалтайм

а какой реалтайм имеется в виду?) RTOS?

т.е. го для гейм сервера вполне подойдет?

Емнип Eve online чуть ли не на питоне серверная часть

а какой реалтайм имеется в виду?) RTOS?

Судя по высказыванию именно классический реалтайм из RTOS. Задачи очень разные.

непонятно какие структуры маленькие, а какие большие

it depends... но обычно я стараюсь всё что больше 32 байт передавать ссылкой, однако так-же не всегда

Емнип Eve online чуть ли не на питоне серверная часть

А сколько браузерок на похапэ - не перечесть

Подскажите, правильно ли реализован Selection Sort? play.golang.org/p/ucxhXmQr1jf

Подскажите, правильно ли реализован Selection Sort? play.golang.org/p/ucxhXmQr1jf

Вроде бы правильно.

т.е. го для гейм сервера вполне подойдет?

C++ для такого есть

https://play.golang.org/p/6ZW2PtILXrp

[1:3] как-то странно работает

вырезает только два элемента, а капасити 3

вырезает только два элемента, а капасити 3

почитайте про слайсы и массивы.

thnx, как раз разбираюсь с ними

C++ для такого есть

тогда уж раст, но го приятнее

ERROR: S client not available

почитайте про слайсы и массивы.

+

C++ для сервера... Мсье знает толк в извращениях.

C++ для сервера... Мсье знает толк в извращениях.

раскройте тезис

C++ говно. Даже Perl не такое говно как C++.

Особенность языка C++ в том, что он гораздо чаще приводит к ошибкам, гораздо хуже работает с юникодом и всякими json. Т.е. сделать все можно, но сильно дороже.

Емнип Eve online чуть ли не на питоне серверная часть

stackless python у них

C++ для такого есть

Увидимся в следующем столетии

Особенность языка C++ в том, что он гораздо чаще приводит к ошибкам, гораздо хуже работает с юникодом и всякими json. Т.е. сделать все можно, но сильно дороже.

С++ станет юзабельным когда завезут пакетные менеджеры.

C++ станет юзабельным, когда они откажутся от обратной совместимости. Т.е. никогда.

С++ станет юзабельным когда завезут пакетные менеджеры.

какие такие пакетные менеджеры? там что, есть пакеты?

какие такие пакетные менеджеры? там что, есть пакеты?

Да хоть какие-нибудь.

нетути такого понятия, пакет

и не будет, так уж язык устроен

Менеджер зависимостей, либ

в го с этим так хорошо, ох...

С++ станет юзабельным когда завезут пакетные менеджеры.

Их уже как говна за баней, но они идеологически не нужны

они же никак не оформлены как таковые. есть .h, есть связанные с ним (на уровне "там такое же описано") .a и .sso. и все, никаких больше ограничений, швабода.

в го с этим так хорошо, ох...

поди плохо

они же никак не оформлены как таковые. есть .h, есть связанные с ним (на уровне "там такое же описано") .a и .sso. и все, никаких больше ограничений, швабода.

Вот нужно принять единый формат и делать менеджер как npm, pip, go get или как в java всякие мавены или градлы

жаль с++ конечно . . .

это был мой любимый язык, но никогда не работала в продакшене на нем

это был мой любимый язык, но никогда не работала в продакшене на нем

Тоже самое, к сожалению.

как говорил сам Строуструп: "существуют 2 вида языков программирования: те о которых все ворчат, и те, которыми никто не пользуется"

Вот нужно принять единый формат и делать менеджер как npm, pip, go get или как в java всякие мавены или градлы

А потом сидеть в отдадчике и о..евать. Откуда к тебе косяки прилетели... Для с++ пакетный менеджер называется git submodules

жаль с++ конечно . . .

а что с ним случилось? :)

Он обречён. Го с растом его сожрут.

друзья . так вопрос - можно ли в GORM как-то один запрос сделать с local отличающейся от locale подключения к бд?

есть одна таблица где date хранится не так как везде

Он обречён. Го с растом его сожрут.

знаешь, это будет как с PHP, все говорят что он умирает вот вот, а нихрена так и с С++

в другой локале

Он обречён. Го с растом его сожрут.

Лол

знаешь, это будет как с PHP, все говорят что он умирает вот вот, а нихрена так и с С++

Не, у похапе совсем другая песня - там уровень вхождения низкий. А у плюсов, просто масса. Слишком много написано, и все это надо как-то поддерживать. Но когда эта масса будет вытеснена другими языками - исчезать он будет очень быстро