а как ты это посчитал?

в 8 битах можно хранить число в диапазоне -256...255 в 4-х -: -16..15

in64 - 64 бита

значит, можно поуменьшить

когда ты говоришь ему value / 256 - он возвращает тупо такой же int64, только убив в нули все, кроме последних 8 бит

грабли могут, конечно, быть

возможно, он тебе день отрицательный вернет

кстати, да, скорее всего вернет

но там уже сам костыль можешь вставить)

жесть.

хорошо, спасибо большое, пойду попилю.

попили, удачи тебе)

Кстати, я тебе соврал, знаковые 8 бит - это от -128 до 127

Но на день месяца хватит

А ещё можешь с побитовым сдвигом заморочиться

А ещё можешь с побитовым сдвигом заморочиться

тоже интересная вещь

во, GetFromHistDate будет, наверное, так выглядеть: func GetFromHistoricalDate(histDate int64) (year int64, month int64, day int64) { year = histDate / (16 * 256) histDate = histDate - year month = histDate / 256 day = histDate % 256 return }

вот так она должна корректно отрицательные годы отрабатываеть

ммм.. нет, чё-т не то

/voteban

ммм.. нет, чё-т не то

ага, чота мутная история с годами вышла)

ща попробую починить

вот такая фигня получается: func ToHD(year, month, day int64) int64 { return year * 100 * 100 + month * 100 + day } func FromHD(hd int64) (year, month, day int64) { year = hd / (100 * 100) if hd < 0 { year-- hd = 10000 + hd % 10000 } hd = hd % 10000 day = hd % 100 month = hd / 100 return }

вот такая фигня получается: func ToHD(year, month, day int64) int64 { return year * 100 * 100 + month * 100 + day } func FromHD(hd int64) (year, month, day int64) { year = hd / (100 * 100) if hd < 0 { year-- hd = 10000 + hd % 10000 } hd = hd % 10000 day = hd % 100 month = hd / 100 return }

да, вроде фунтычит. Спасибо )

не больно ли много места занимает?

*100*100, вот это всё

а дата у нас data переводится?

всё ждал, когда же кто прикопается )

я долго тренирвоал снобизм. зря что-ли?

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

ну это получается надо заморачиваться самому - сколько там дней в месяце итп

хмм а можно ли хранить дату и инт сдвига года относительно минимального 19хх года? или это сломет верность дат?

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

Если только вы уж какой-то совсем простенький справочник не делаете.

я имел ввиду что наша эра началась с 0000, а не 1970

А ещё в истории не было нулевого года

За первым до нэ сразу шёл первый нэ

?

=)

Имеет ли смысл заводить goroutine pool для конкурентной обработки болшого колва запросов? (речь идёт не о HTTP) или просто запускать горутины go handle() ? предполагаю, что в случае HTTP, инициализация обработчика в горутине занимает значительное время и создаёт лишние аллокации и если эдакого overhead'а не имеется просто запускать горутины и не париться?

Зачем усложнять, при чём так зверски? Вы не напишете более эффективный планировщик, чем тот, что есть. Голанг имеено под это заточен изначально

Зачем усложнять, при чём так зверски? Вы не напишете более эффективный планировщик, чем тот, что есть. Голанг имеено под это заточен изначально

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

если обработчик при инициализации аллокейтит память, то это будет значительно тормозить при постоянном запуске многого колва обработчиков

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

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

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

да исходники то открыты: https://github.com/qbeon/webwire-go/blob/master/serverHttp.go#L66 сейчас работаю над реализацией feature request issue по параллелизации обработки запросов и задумался, а не стоит ли мне в этом случае использовать goroutine pool.. короче скорее всего нужно замерить сколько памяти например тот-же parser выделяет

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

тут планировщик не при чём, тут дело в коде, который запускается внутри каждой горутины..

че хероку от меня хочет?

https://pastebin.com/6jJwBT7m

исходников нет, но подозреваю, что импорта нет для xrich

тут планировщик не при чём, тут дело в коде, который запускается внутри каждой горутины..

может быть вы имеете ввиду просто сделать асинхронщину на event lopp-ах,?

Запускается одна горутина статически, в ней крутится евентлуп в цикле, который принимает сообщения, содержащие таски на вычисление. Вычисляет, передаёт результат в колбэк

исходников нет, но подозреваю, что импорта нет для xrich

https://github.com/RedSkotina/xrich/tree/develop

https://pastebin.com/6jJwBT7m

вы инглишь нихт ферштейн? в гугель-переводчик вбейте

вы инглишь нихт ферштейн? в гугель-переводчик вбейте

ты че такой злой то?

че это я злой, я по делу вам говорю

да есть у меня импорты

и локально работает

я этой хероке не могу указать где мой пакет по видимому находится. а сам он не может определить

значит пакета нет в папке вендор

может быть вы имеете ввиду просто сделать асинхронщину на event lopp-ах,?

какой event loop)) мы тут про Go говорим)

значит пакета нет в папке вендор

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

какой event loop)) мы тут про Go говорим)

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

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

и где тогда по вашему хорока должна его взять?

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

в данном случае никакой event loop не нужен, речь шла об оптимизации инициализации обработчиков горутин

мы не в Node.js чтоб однопотоком баловаться

в данном случае никакой event loop не нужен, речь шла об оптимизации инициализации обработчиков горутин

воркер пул может дать больший контроль над потреблением ресурсов, если говорить в целом

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

и где тогда по вашему хорока должна его взять?

я первый раз деп использую

ERROR: S client not available

воркер пул может дать больший контроль над потреблением ресурсов, если говорить в целом

что такон воркерпул в Го и как им управлять?

это канал + пачка горутин

которые обрабатывают задачи, приходящие из канала

я первый раз деп использую

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

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

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

это да, с этим согласен, а так можно поставить maxConcurrentHandlers: 100

именно

в этом случае мы эти 10к задач прожуём медленнее, но более контролируемо

ну или можем преаллоцировать сколько надо воркеров

у меня например в 1 сервисе 8к преаллоцированно, с лимитом увеличения до 60к

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

вот это сложно. евентлуп с одной горутиной, принимающий сообщения, проще и эффективнее

в таком случае workerPool на каждого клиента? или 1 на весь сервер? думаю что если в контексте клиента пул запускать, то это будет быстрее, ибо, как мне кажется, синхронизация доступа к каналу сожрёт много времени если клиентов предположим 10к и каждый из них по 20 запросов херачит

вот это сложно. евентлуп с одной горутиной, принимающий сообщения, проще и эффективнее

это примерно 20 строчек кода

в таком случае workerPool на каждого клиента? или 1 на весь сервер? думаю что если в контексте клиента пул запускать, то это будет быстрее, ибо, как мне кажется, синхронизация доступа к каналу сожрёт много времени если клиентов предположим 10к и каждый из них по 20 запросов херачит

а тут уже вам решать

за чем вы гонитесь

работать будет всё - и горутина на запрос, и на клиента, и на сервер

вопрос только в том, что у вас реально етсь такая нагрузка и в характере этой нагрузки

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

ну с godep у меня все работало и без моего пакета в вендоре

работать будет всё - и горутина на запрос, и на клиента, и на сервер

да вот боюсь как бы mutex канала не превратился в I/O bottleneck

я просто делал godep save ./cmd/.. и оно норм прописывало пути не кладя даже мой пакет в вендор

да вот боюсь как бы mutex канала не превратился в I/O bottleneck

чего бояться, мерять надо :)

mutex profile есть в pprof

как мне тогда сказать депу чтобы он мой пакет в корне гихаба положил тоже в папку вендор? и зачем мне две копии пакета - в корне и в вендоре?

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

вот это сложно. евентлуп с одной горутиной, принимающий сообщения, проще и эффективнее

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

чего бояться, мерять надо :)

мерять надо безусловно, но вот предполагаю что, теоретически, atomic int должен быть быстрее чем канал, по которому передаются целые сообщения. ибо канал блокирует во время копирования сообщения и передачи его в горутину а atomic только ин-/декрементит т.е. можно поставить atomic int currentActiveWorkers и с ним работать в обработчиках соединений

хотя...

вы заморачиваетесь

вы заморачиваетесь

возможно)

как мне тогда сказать депу чтобы он мой пакет в корне гихаба положил тоже в папку вендор? и зачем мне две копии пакета - в корне и в вендоре?

dep init dep ensure

dep init dep ensure

я это сделал

я это сделал

dep ensure -add github.com/foo/bar