А в чём профит?

Меньше lock contention на объектах ядра

А как быть с разделяемой памятью?

Кстати, в Эрланге как акторы реализованы? Тоже поверх тредов ОС как горутины?

Для чего она нужна?

Ладно, спрошу не про дженерики: что вы делаете, если ваш код медленный, а возможности по оптимизации уже исчерпаны?

1. zero memory allocation между запросами 2. перевести с мапов на массивы 3. найти copy() и аллокации, убрать 4. поиграться с типами. зачастую Int быстрее чем int32/bool 5. зверская магия, когда есть map, допустим из 50 элементов, делается make(map, 50), и копируется - чтение из нового будет быстрее, до 20-50% иногда. 6. алгоритмы! O(n) и все такое. 7. вместо стандартной библиотеки юзать свои функции (например которые вместо {}interface будут юзать int) 8. string поменять на слайс byte, когда есть промежуточные переводы туда сюда. Но это ерунда на самом деле. 9. если функции чистые и руки прямые, то можно в ассемблер залезть и там поковырять.

это в ответ на вопрос, что делать, когда возможные оптимизации выполнены, перечислили возможные оптимизации? (int vs int32, без пруфов я бы не принял)

1. zero memory allocation между запросами 2. перевести с мапов на массивы 3. найти copy() и аллокации, убрать 4. поиграться с типами. зачастую Int быстрее чем int32/bool 5. зверская магия, когда есть map, допустим из 50 элементов, делается make(map, 50), и копируется - чтение из нового будет быстрее, до 20-50% иногда. 6. алгоритмы! O(n) и все такое. 7. вместо стандартной библиотеки юзать свои функции (например которые вместо {}interface будут юзать int) 8. string поменять на слайс byte, когда есть промежуточные переводы туда сюда. Но это ерунда на самом деле. 9. если функции чистые и руки прямые, то можно в ассемблер залезть и там поковырять.

1. zero memory allocation между запросами 2. перевести с мапов на массивы 3. найти copy() и аллокации, убрать 4. поиграться с типами. зачастую Int быстрее чем int32/bool 5. зверская магия, когда есть map, допустим из 50 элементов, делается make(map, 50), и копируется - чтение из нового будет быстрее, до 20-50% иногда. 6. алгоритмы! O(n) и все такое. 7. вместо стандартной библиотеки юзать свои функции (например которые вместо {}interface будут юзать int) 8. string поменять на слайс byte, когда есть промежуточные переводы туда сюда. Но это ерунда на самом деле. 9. если функции чистые и руки прямые, то можно в ассемблер залезть и там поковырять.

я, может быть, плохой сварщик (скорее всего, даже не настоящий), но чтобы int64 операции обгоняли int32, вроде не натыкался

это в ответ на вопрос, что делать, когда возможные оптимизации выполнены, перечислили возможные оптимизации? (int vs int32, без пруфов я бы не принял)

Я про стандарт вроде pandas/tensorflow

pandas/tensorflow не обсчитвают вечность исключительно благодаря GPU, которым GIL действительн оне помеха.

Добрый день, вопрос по gorm. Есть две структуры и я упорно не понимаю почему не получается назначит внешние ключи, можете подсказать что я делаю не так type Answer struct { ID uint gorm:"primary_key",json:"id" User User gorm:"unique;foreignkey:UserID" UserID int Objects []Object gorm:"foreignkey:QuestionID" ObjectID int Questions []Question gorm:"foreignkey:QuestionID" QuestionID int } type Question struct { ID int gorm:"primary_key",json:"id" FirstObject Object gorm:"foreignkey:FirstObjectID" FirstObjectID int SecondObject Object gorm:"foreignkey:SecondObjectID" SecondObjectID int }

Вы утверждаете что без gpu они не будут работать? :)

1. zero memory allocation между запросами 2. перевести с мапов на массивы 3. найти copy() и аллокации, убрать 4. поиграться с типами. зачастую Int быстрее чем int32/bool 5. зверская магия, когда есть map, допустим из 50 элементов, делается make(map, 50), и копируется - чтение из нового будет быстрее, до 20-50% иногда. 6. алгоритмы! O(n) и все такое. 7. вместо стандартной библиотеки юзать свои функции (например которые вместо {}interface будут юзать int) 8. string поменять на слайс byte, когда есть промежуточные переводы туда сюда. Но это ерунда на самом деле. 9. если функции чистые и руки прямые, то можно в ассемблер залезть и там поковырять.

10. make([]int, Здесь указывать размер впрок ) - тоже ускоряет, если уже не сделано

10. make([]int, Здесь указывать размер впрок ) - тоже ускоряет, если уже не сделано

Они есть, а если нет, то есть @pycall + легко вызывать сишные либы

за счет чего быстрее?

за счет чего быстрее?

как правило при росте базы примерно до 20-30 гигов без GPU всё немножко становится рачком

за счет чего быстрее?

это смешно. Так можно любой ЯП брать для ML и потом манаться с биндингами

Ну если в размер не вместилось, append будет создавать копию массива.Например два варианта: z := []int{}; for i:=;i<=100;i++ { z = append(z, i) } //второй вариант z := make([]int,100); for i:=;i<=100;i++ { z = append(z, i) }

Ну если в размер не вместилось, append будет создавать копию массива.Например два варианта: z := []int{}; for i:=;i<=100;i++ { z = append(z, i) } //второй вариант z := make([]int,100); for i:=;i<=100;i++ { z = append(z, i) }

наверно, вы имеете ввиду make([]int,0,100)

Есть основные либы + NumPy встроен в язык

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

а cuda? и вот все то счастье в виде готовых и протестированных библиотек?

Видел. Не могу сказать что всё прям отлично оттестировано и проверено на проде

сначала работу с диском, потом алгоритмы и аллокации =)

сначала работу с диском, потом алгоритмы и аллокации =)

ну и о чем речь? кому интересно воевать с непонятными багами решая конкретную задачу?

а что с диском? программы на диск не пишут. практически никогда.

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

могут читать. с mysql например, при каждом запросе дергать какую нибудь фигню или чтото подобное. или какойнибудь конфиг в json

Мутабельное расшареное состояние - главный источник сложности ПО. Именно поэтому ООП - полное дерьмо, в нём shared mutable state достигает своего апогея. Хотя в го это не актуально, ибо всё состояние приложения хранится (почти) всегда в базе.

да и не читают тоже, кстати )

Иногда без него никак

Ключевое слово - иногда. Именно поэтому, например, в расте переменные по дефолту иммутабельные и мутабельными они становятся только после добавления модификатора mut.

а ты попробуй поработай с JSON в C++, поймёшь почему нам interface{} нужен)

интерфейсы - „не абстракции“ структуры - „не абстракции“ пакеты - „не абстракции“ вы так говорите будто Go это C

Толку от тип сумм, когда рефлексии нет и нужно ручками всё расфасовывать?

Стоп, а зачем рефлексия?

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

Чтобы эти самые типы автоматически в json распихать

в таком случае JavaScript это C++, только без %остустсвующие_фичи% и с %присутствующие_фичи%