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

Вот тут я с ваим ен согласен

правильно - оно от определения правильного зависит

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

чтобы я мог происходящее понять прочитав как можно меньше

а страх перед накладными на вызов функции - это совсем не правильно

@avquantex Го не про мега скорость

Го для тех силучаев когда хочется быстрее питона )

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

Есть где то надпись что "го предназанчен тоьлко для микросервисов с большим и жирным процом и кучейпамяти"?

нет, но это от скромности

по сокрости го в 2 раза медленее си

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

@avquantex у Го просто есть веселый пожитатель скорости - GC :)

ну в среденм

по сокрости го в 2 раза медленее си

там где GC спит - да

там где он просыпается происходит трэш и угар

как впрочем в любом языке с GC

да вроде же говорили про 100мкс

да вроде же говорили про 100мкс

ну так оно зависит от )

это пауза

там помимо паузы есть че поделать

авторы гошечки оптимизировали gc под маленький stop to world

в общем пока мне в моих задачах GC не мешал

а вот сборка мусора по сути идет в фоне

авторы гошечки оптимизировали gc под маленький stop to world

Это было давно.

итого на краевых случаях (десятки ГБ памяти) gc может жрать больше ресурсов чем приложение

в общем пока мне в моих задачах GC не мешал

тогда и стек не помешает

Это было давно.

но ничего принципиально не поменялось с тех пор

они давно обещают request oriented gc

но ничего принципиально не поменялось с тех пор

Они трубили во всю что удбрали стопмир

но пока он не случился

Они трубили во всю что удбрали стопмир

где? )

ты с джавой и g1 кажется путаешь

в 1,5 кажется

Они трубили во всю что удбрали стопмир

куда они его уберут?!

в 1,5 кажется

ооо, нет

они в 1.5 переписали все на Го

и уменьшили паузы

даже вьюков про это говорил

не говорил

точно не говорил

Эм.. даже не хнаю что сказать. Неужели я жестоко ошибался?

stop the world делается, и работы ведутся в направлении уменьшения его

@avquantex там обычный mark-sweep

и он уже довольно маленький

ничего нового в Го не появилось с момента его создания

Эм.. даже не хнаю что сказать. Неужели я жестоко ошибался?

да

кстати кажется понял зачем они проверку сделали.

кстати кажется понял зачем они проверку сделали.

зачем?

чтоыб не идти до 7 байта чтобы потомт поянть что надо паниковать

чтоыб не идти до 7 байта чтобы потомт поянть что надо паниковать

как будто это страшно

оптимизация. Вы не разбрасывайтесь тактами ?

оптимизация. Вы не разбрасывайтесь тактами ?

преждевеременная оптимизация

к тому же она ухудшает ситуации когда все ок

других мыслей у меян нет почему

ну скорее всего ты прав

чтоыб не идти до 7 байта чтобы потомт поянть что надо паниковать

поменять порядок заполнения массива, и не надо будет идти. но я бы вообще binary.BigEndian.PutUint64() использовал, а не писал это вот

поменять порядок заполнения массива, и не надо будет идти. но я бы вообще binary.BigEndian.PutUint64() использовал, а не писал это вот

+1

забавно, с проверкой границ код гораздо медленнее

а?!

забавно, с проверкой границ код гораздо медленнее

сюрприз

поменять порядок заполнения массива, и не надо будет идти. но я бы вообще binary.BigEndian.PutUint64() использовал, а не писал это вот

Не совсем понял ход вашей мысли

я про вторую часть

Не совсем понял ход вашей мысли

в стандартной библиотеке уже есть код который делает то же самое

притом у него в отличии от того что написано выше есть шансы быть написанным например на асме

func (littleEndian) PutUint64(b []byte, v uint64) { // _ = b[7] // early bounds check to guarantee safety of writes below b[7] = byte(v >> 56) b[0] = byte(v) b[1] = byte(v >> ? b[2] = byte(v >> 16) b[3] = byte(v >> 24) b[4] = byte(v >> 32) b[5] = byte(v >> 40) b[6] = byte(v >> 48) }

ERROR: S client not available

с каким-нибудь симдом

func (littleEndian) PutUint64(b []byte, v uint64) { // _ = b[7] // early bounds check to guarantee safety of writes below b[7] = byte(v >> 56) b[0] = byte(v) b[1] = byte(v >> ? b[2] = byte(v >> 16) b[3] = byte(v >> 24) b[4] = byte(v >> 32) b[5] = byte(v >> 40) b[6] = byte(v >> 48) }

такое кстати сломает автовекторизацию если таковая есть

в Го вроде рудиментарная есть

я про вторую часть

аааа

ониже массив оп разному заполняют

функции бил и литтл

такое кстати сломает автовекторизацию если таковая есть

в современном мире вообще-то не сразу поймешь, отимизироал ты код, или, наоборот, ухудшил

функции бил и литтл

там обе есть

ксттаи предложите оптимизацию для бинари. Если заполнять с конца

и тут до меня дошло

по gc такой интересный issue есть https://github.com/golang/go/issues/17503

1.11 обещает быть интересной

и тут до меня дошло

это же как раз https://golang.org/src/encoding/binary/binary.go?#L81 и есть!

а 2.0 ещё итереней

и тут до меня дошло

BenchmarkV1-4 2000000000 0.43 ns/op BenchmarkV1-4 2000000000 0.56 ns/op BenchmarkV1-4 2000000000 0.40 ns/op BenchmarkV1-4 2000000000 0.38 ns/op BenchmarkV1-4 2000000000 0.40 ns/op BenchmarkV2-4 2000000000 0.44 ns/op BenchmarkV2-4 2000000000 0.44 ns/op BenchmarkV2-4 2000000000 0.38 ns/op BenchmarkV2-4 2000000000 0.38 ns/op BenchmarkV2-4 2000000000 0.39 ns/op

это же как раз https://golang.org/src/encoding/binary/binary.go?#L81 и есть!

Ну да.

V2 - это оригинальный с _ =

а V1 как модифицированный

/leave

а 2.0 ещё итереней

её ж не будет

по этому я и не понял про биг и литтл. Однго вметсто второго нельзя использовать для оптимизации как вы написали. Они по разному массив заполняют.

я написал с подъебкой

но получилось, что сам себя того :)

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

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

массив оказывается в кеше, видимо

BenchmarkV1-4 2000000000 0.43 ns/op BenchmarkV1-4 2000000000 0.56 ns/op BenchmarkV1-4 2000000000 0.40 ns/op BenchmarkV1-4 2000000000 0.38 ns/op BenchmarkV1-4 2000000000 0.40 ns/op BenchmarkV2-4 2000000000 0.44 ns/op BenchmarkV2-4 2000000000 0.44 ns/op BenchmarkV2-4 2000000000 0.38 ns/op BenchmarkV2-4 2000000000 0.38 ns/op BenchmarkV2-4 2000000000 0.39 ns/op

Вы можете написать что конкретно вы изменили?

А как положить краисиво uint64 в слайс?

точнее добавить

в байтовый слайс

Вы можете написать что конкретно вы изменили?

В1 вариант Даниэля