AM
подскажите, почему оно работает еще дольше чем в одном потоке?
Size: a a a
2020 April 17
x
А почему оно должно работать быстрее?)
AM
А почему оно должно работать быстрее?)
ну мне подсказали, что dest блокирует запуск следующей горутины
GE
Может потому как накладные расходы выше и это для чего-то более трудоемкого?
К
операция слишком быстрая ее выполнение занимает мало времени и она то происходит быстро а вот потом начинает копится очередь append <-num и куча потоков блочат друг друга и слипаются
x
операция слишком быстрая ее выполнение занимает мало времени и она то происходит быстро а вот потом начинает копится очередь append <-num и куча потоков блочат друг друга и слипаются
Нет там очереди
ЛА
Канал небуферизирован, а значит вписать туда можно будет только после вычитки предыдущего значения. А вычитка идёт в одной рутине. По сути однопоточный код с лишними расходами на создание рутин и записью/чтением в каналы
2020 April 18
s
Потому что это и работает в одном потоке по сути, как уже и написали
s
Даже на буферизованном канале оно прямо очень вряд ли заметно быстрее отработает. Потому что накладные расходы на создание охренилиона горутин из одного действия перекроют профит от многопоточной записи в канал. И потому что консьюмер так и остался один, вдобавок там же, где и горутины отстреливаются.
VM
как с переполнением инта бороться? кастомно проверять на 0?
DP
а?!
VM
2^63 == 0
DP
и?!
DP
с чем тут можно бороться?
VM
ну в куче языков при переполнении возникает ошибка, с которой удобно работать, а здесь неадекватный 0
VM
в какой куче?
в джаве нет, в c/c++ нет..
в джаве нет, в c/c++ нет..
ок, видимо что-то путаю. Энивей неприятно(