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

P.S. Всегда было интересно, куда девают столько сэкономленного свободного времени Go-разработчики, которые пишут func вместо function :)

тратим на написание if err != nil ))

в 18м году тестить одинарные и двойные кавычки это конечно жесть ))
помню как бомбило, когда в подобных спорах, этак 8-10 назад ссылались лохматую статью начала 2000х, выглядело это как язычество

извините, но ничего нового, все это написано в мануалах

я про гидроавтоматы

да ты его новым продал ))

гидроавтоматы и вариаторы не любят буксировку

прям таки и не любят? откуда это заблуждение?

В современном обществе потребления это мало кого волнует. Автопроизводители уже не производят вечных машин. Потребители по окончании гарантии авто меняют. Т.е. заявленный производителем ресурс 100-150ткм (для некоммерческого транспорта) двигателя и кпп ходят.

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

На ниссанах довели до ума вариатор. Если в начале они были проблемой на кашкае и мурано, то года после 08го с вариатором проблем не больше чем с автоматом, даже на двигателях 2.5/3.5л. и 4wd. Последние модели все выпускаются с CVT (исключая альмеру и террано, но все знают что это неправильная альмера и неправильный террано)

Помню, когда массово начали ввозить бу иномарки из японии, очень недоверчиво относились к автоматам. Сейчас автоматом никого не напугаешь.
То же самое, как мне кажется, произошло и с вариаторами, ошибки найдены и исправлены, ресурс соизмерим с ресурсами современных двигателей. При этом размер вариатора очень важное преимущество — размер, что важно для авто с поперечным расположением двигателя и кпп. Старые 4хступенчатые автоматы AT очень надежны, но при этом из-за малого кол-ва передач туповаты и неэффективны (ну разве что за городом). Увеличение кол-ва передач требует либо увеличение размеров акпп либо уменьшение размеров деталей.
Следующий этап за преселективными роботами имха

Был в семействе 21й с французским двигателем, достойно бегал для того времени.

В этом есть какая-то магия? Просто не работал с пакетом unsafe.
Есть какие-нибудь тесты, которые подтверждают облегчение жизни gc при использовании sync.Map?

В коде вижу вот это:
return &entry{p: unsafe.Pointer(&i)}
создается ссылка на entry и далее она хранится в
map[interface{}]*entry
Сокращения кол-ва ссылок не вижу, плюс объект, ссылка на который сохранена в map, продолжает жить в куче. В чем профит.

согласен, кроме последнего предложения
sync.Map не решит проблему с gc, т.к. хранящиеся в мапке указатели никуда не денутся
здесь только один путь — уменьшать кол-во указателей, как, например, сделали вот эти ребята: allegro.tech/2016/03/writing-fast-cache-service-in-go.html

по поводу defer
i5-4670 CPU @ 3.40GHz
goos: linux
goarch: amd64
BenchmarkLockUnlock-4 100000000 15.0 ns/op
BenchmarkLockDeferUnlock-4 30000000 44.9 ns/op
PASS


здесь один метод вообще лишний, оставить только GC и стартовать его в функции New

еще 5 копеек
— не стоит светить все функции наружу, тот же GC, есть интерфейс Get/Set/Delete остальные функции не должны быть доступны снаружи
— defer не бесплатен, когда функции делает много под блокировкой, это оправдано, для чтения/записи в map это избыточно
— не надо держать блокировку без необходимости, получил блокировку, прочитал/записал в мапку, отпустил блокировку и дальше уже разбираешься с тем что получил (это про Get)
— зачем delete возврат ошибки? она бесполезна + ради этого двойной поиск в мапке
— сборка мусора вообще странно сделана, зачем в два этапа? нет гарантии что между expiredKeys и clearItems значения не будут обновлены

Ну и довольно медленный он, по крайней мере по сравнению с мьютексами

Сам бенчмарков не делал, столь категорично утверждать не буду, но как универсальное решение тоже бы не посоветовал.
Документация описывает 2 конкретных случаях, когда sync.Map выгоднее мапки с мьютексом, но в общем случае для реализации кеша может сыграть как в плюс так и в минус.

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

и не должно было получиться
sqle это про удобство а не про производительность

Было интересно кроме самих цифр увидеть какой-то анализ, почему в одних случаях разница между 7.0/7.1/7.2 существенна а в других нет, или почему так выбивается laravel c hhvm?

func (b *Block) SetHash() {
    timestamp := []byte(strconv.FormatInt(b.Timestamp, 10))
    headers := bytes.Join([][]byte{b.PrevBlockHash, b.Data, timestamp}, []byte{})
    hash := sha256.Sum256(headers)
    b.Hash = hash[:]
}

В описанном примере велика вероятность, что память для headers будет выделена на стеке и это никак не нагрузить GC. В общем случае так делать не надо. Интерфейс hash.Hash расширяет io.Writer и этим стоит пользоваться.