Go 1.7

А вот когда надо - внезапно оказывается, что трехсоткратное различие в скорости работы - это многовато.

А ещё оказывается, что разница между O(n) и O(n^2) может дать и большее различие в скорости работы.

Они уже перестали быть предметом первой необходимости или нет.

Зависит от области. Из телекома, например, тебя с твоей идеей пихать везде map погнали бы взашей. И да, я не говорил «предмет первой необходимости». Я говорил «выгода очевидна».

Зависит от области. Из телекома, например, тебя с твоей идеей пихать везде map погнали бы взашей. И да, я не говорил «предмет первой необходимости». Я говорил «выгода очевидна».

А, так ты в телекоме работаешь. И что там юзают, когда надо пару миллиардов записей в памяти переживать? map или deque?

Ладно, не мучайся.

// g++ (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
#include <unordered_map>

int main()
{
        std::unordered_map<int, int> m;
        for (int i = 0; i < 10000000; i++)
                m[i] = i;
}

time ./a.out
real	0m3.904s
user	0m3.796s
sys	0m0.104s

// go version go1.7 linux/amd64
package main
func main() {
        m := make(map[int]int)
        for i := 0; i < 10000000; i++ {
                m[i] = i;
        }
}

time go run map.go
real	0m2.464s
user	0m2.332s
sys	0m0.140s

А ты включи оптимизацию и добавь reserve в код на С++, у меня получается:

С++:

real	0m0.686s
user	0m0.576s
sys	0m0.108s

Go:

real	0m2.192s
user	0m2.156s
sys	0m0.076s

И это без подбора оптимального max_load_factor.

Походу не работать мне в телекоме. Вот беда.

тогда и в Go сделай «reserve»:

package main
func main() {
    const n = 1e7
    m := make(map[int]int, n)
    for i := 0; i < n; i++ {
        m[i] = i;
    }
}

//другой аноним

Не, брат аноним, мы слили. Оптимизация у г++ весьма жесткая, не дотягиваем пока. Резервирование не помогает, нужна тяжелая артиллерия типа кастом мапы без гойского оверхеда в виде поддержки всяких рукожопов, которые модифицируют мапы во время итерации.

Без вопросов:

real	0m1.248s
user	0m1.168s
sys	0m0.076s

Кстати, вспомнил, тут на ЛОР обсуждалась подходящая задача:

http://www.spoj.com/problems/HOMO/

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

да я и не сомневался, тем более что Go еще и перемешивает мапу...

Зачем там map?!

http://pastebin.com/hXG28zBx

Зачем там map?!

Запости решение - будет видно.

Запостил же, Accepted.

Мне однажды пришлось делать unordered map, обновляющийся N раз в секунду либо для конкретного пользователя позволяющий тут же видеть его изменения. Типа вася запостил на стене котиков и тут же их видит а все остальные узнают о событиях других пользователей по таймеру.

Это к тому что обычные контейнеры могут и не тянуть в реальных условиях

Запостил же, Accepted.

wota	accepted 	0.00 	9.1M 	
shdown	accepted 	0.13 	4.9M

Но при этом значительно проигрывает по скорости. А тут вроде как меряются члскоростью.

Ты что-то темнишь. Там всё упирается в скорость ввода-вывода, сейчас написал с read+write — стало 0.06. Суть в том, что там можно тупо отсортировать и искать бинарным поиском, что быстрее, а unordered_map, кажется, тупо не поддерживается на сервере:

In file included from /usr/include/c++/4.3/unordered_map:40,
                 from prog.cpp:2:
/usr/include/c++/4.3/c++0x_warning.h:36:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.

Там всё упирается в скорость ввода-вывода, сейчас написал с read+write — стало 0.06.

Ну раз у меня 0.00, а не 0.06, то значит не все.

искать бинарным поиском, что быстрее

Я б не делал такие смелые заявления. Особенно в плане практического применения алгоритмов.

а unordered_map, кажется, тупо не поддерживается на сервере:

А причем тут сервер, речь исключительно в стандартах. До С++11 unordered_map был в tr1:

#include <tr1/unordered_set>

#include <tr1/unordered_set>

unordered_map т.е., впрочем unordered_set был там же, как и shared_ptr, unique_ptr etc. И конечно не было ни единой причины ими не пользоваться.

Мм, да, ты прав — с unordered_map 0.10.

Хочешь сказать, сишка из-за отсутствия дженериков - уже не годный язык программирования?

в Сишке есть макросы (в частности техника X-Macros), которые компенсируют нехватку женериков.

в Сишке есть макросы (в частности техника X-Macros), которые компенсируют нехватку женериков.

What. The. Fuck. I. Have. Just. Read.

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

Препроцессор — это такая фаза.

В Go вроде не так давно тоже взялись за ум и добавили go generate

это способно компенсировать нехватку женериков

Дженерики по определению понимаются компилятором. Их отсутствие не способно компенсировать никакое количество X-макросов (то еще уродство) .

Это если ты библиотеки пишешь.

А если конечный продукт/сервис, то способны только в путь.

цитата_о_невесте.txt.

как будто дженерики не уродство

И чего только люди не придумывают, лишь бы не использовать устоявшиеся промышленные стандарты, такие как C++. Высокоэффективные, скоростные решения, проверенные годами и миллионами сотен тысяч строк кода. Тянет вас, маргиналов, на всякую глупость, понимаете ли... Си, С++ и может быть Джава, а всё остальное от Лукавого.

Только истинно устоявшееся, только Кобол. Кресты с явками удел хипстоты!

XSI ICE, Houdini VOPs etc. Только тут такое дело, при визуальном подходе желательно, чтобы самые базовые («атомарные») операции были достаточно высокоуровневыми (гораздо выше уровнем, чем +-/*) иначе программа, составленная таким образом, будет представлять собой очень длинное спагетти, непростое для понимания.

Ты всерьез его бредни воспринимаешь что-ли. Чел открытым текстом пишет: хочу иде, которе само за меня программы пишет. Школота какая-то.

XSI ICE

Это что за говно было такое? Я так понял что это некая среда для 3д графики но я все таки ожидал увидеть если не шедевр то по крайней мере новый подход к программированию. А просто обвести каждую операцию и даже константу квадратом...

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

Ты всерьез его бредни воспринимаешь что-ли. Чел открытым текстом пишет: хочу иде, которе само за меня программы пишет. Школота какая-то.

Не, я подумал грешным делом, что человек переизобретает блок-схемы / визуальное программирование. А оно вон что - Болген Студио какое-то :-D

Это что за говно было такое? Я так понял что это некая среда для 3д графики но я все таки ожидал увидеть если не шедевр то по крайней мере новый подход к программированию. А просто обвести каждую операцию и даже константу квадратом...

Это г..но (в лице ) является одним из двух адекватных движков на рынке, Карл. Никто ничего дельнее не осилил.

Рисунком можно обрисовать архитектуру программы, интерфейсы и т.д. а кодом описать конкретную реализацию каждого элементика.

Так покажи, как надо, хотя бы в виде презентахи.

а кодом описать конкретную реализацию каждого элементика.

Забыл сказать, в XSI ICE «элементики» писались на Си,в Fabric Engine и Houdini- код пишется прямо в «элементике» на KL и VEX (да и на Python можно) соответственно. Не оно?

http://cowlark.com/2009-11-15-go/

Можно было дать и ссылку на полную дискуссию: https://news.ycombinator.com/item?id=12330573

P.S. так квотят только... ну ты понял.

А сверху этого читаем: «Looking at it now, it's incoherent, badly argued, and a lot of the details are simply wrong.»

Так что я бы не воспринимал цитату об Алголе. Плюс чувак в тексте пишет, что на момент написания только-только немного потыкал Go палочкой. Первые впечатления от языка почти всегда негативные, потому что непривычно.

Даже в том треде упоминают Rust. Прям как на лоре. Классика.

Ага, а абзац после этого ты тихо поскипал:

Don't get me wrong; I still think that Go is a terrible language. I now work for a company that does a lot of it, and every time I touch it it depresses me a little more (and I've had the 'Hey, did you read that article which compares Go to...' 'Yeah. I wrote it.' 'Oh. awkward silence' conversation at least twice). However, I can now express my reasons in a much more coherent fashion.

Чтобы вещи типа HashTableMap<string,AnotherType<ThidTypeEtc>> в этом формате становились читабельными.

Неявной типизации недостаточно? Вроде в ocaml и haskell все читаемо более чем, если в редких случаях компилятор не выведет типы — можно написать руками.

Тут он просто пишет, что Go ему не по душе. Да пожалуйста. Я говорил конкретно о цитате, где Go сравнили с Алголом. Эта цитата содержится в тексте, о котором сам автор написал, что он некорректный, поэтому использовать эту цитату в аргументации некорректно.

Ну а если мысль только сказать, что +1 чувак хейтит Go, тогда ок.

Плюс чувак в тексте пишет, что на момент написания только-только немного потыкал Go палочкой. Первые впечатления от языка почти всегда негативные, потому что непривычно.

В начале статьи написано, что его мнение мало изменилось за несколбко лет.

В начале статьи написано, что его мнение мало изменилось за несколбко лет.

у тебя мнение вообще не меняется никогда, может он просто такой же упорот^W, простите, упорный, как и ты

Наивная имплементация:

=== RUN   ExampleHomo
--- PASS: ExampleHomo (0.00s)
BenchmarkHomo-4         30000000                54.6 ns/op
PASS
ok      mystuff/homo    1.696s

у тебя мнение вообще не меняется никогда

Это исключительно потому, что в Go никогда не появляются дженерики.

может он просто такой же упорот^W, простите, упорный, как и ты

Призрак гика восстал, чтобы сказать мне это. Ну точно - я пришел к успеху.

Это исключительно потому, что в Go никогда не появляются дженерики.

ты же не пишешь на Go - какая тебе разница ? :)

Ну точно - я пришел к успеху.

пришёл - не забудь вовремя уйти, дай другим постоять возле успеха

ты же не пишешь на Go - какая тебе разница ? :)

Ну так жизнь кончается не завтра.

Ну так жизнь кончается не завтра.

а ты оптимист

Это г..но (в лице ) является одним из двух адекватных движков на рынке

Я если честно в удивлении. «А что, так можно было?»

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

На ЛОРе был недавно тред: как вы обустраивались на новых проектах. И как я понял основная проблема была в том, что ты же программист, ну поработай 12-14 часов в день и разберись, всё же понятно. В общем, без картинки в куче кода не разберешься.

Поэтому моя идея - только высокий уровень писать картинками. Т.е. иерархия классов, кто owner pointerов, потоки и пулы потоков, и т.д.

А внизу текст по любому компактнее. Не надо его «рисовать». Вот это то, что я увидел в XSI ICE: там даже константы в виде «блоков»: они тупо решили рисовать код полностью.

А оно вон что - Болген Студио какое-то

И это не «Болген Студио» - я изначально пилил плагин для QtCreator, и ничего особо лютого не изобретал. Просто есть сложные вещи которые удобно разрисовать а потом кодом детализовать.

Я не фанат «рисунков»: у МЦСТ был такой говнопроект «Дракон», где код реально чертили в виде блок-схем. Это я знаю, потому что это была наша базовая кафедра. И этот способ записи из 60х отлично бы работал для ламповых ЭВМ. Но сейчас у нас 2010е, и хочется иметь возможность быстро набросать схему программы, и оценить «load». А мне лично хочется сделать свой проц, и там тройная задача: рисовать layout, верифицировать его относительно кода на Си, и код на Си/Си++ прогонять на модели.

Вот откуда выросло требование «картинки» - я хочу видеть как проц реагирует на код: как используется кэш, как используется ALU и т.д.

Вообще, если бы передо мною поставили бы задачу сделать такую же хренть как XSI ICE, то вот то говно, что я увидел, просто бы не появилось на свет.

Во первых, я уже писал что придумал свой проц. А придумал его я потому, что придумал изначально игру типа minecraft но с физикой - то есть все может падать. Я могу написать алгоритм на SSE3 который вычисляет время до столкновения двух кубов, и его уже некуда оптимизировать(6 инструкций + 1 jmp vs N инструкций + 19 jmp). Но он тормозил!

И тормозил он потому, почему я сперва решил его ускорить на FPGA, а потом понял, что такой подход можно переносить вообще на большинство алгоритмов.

Так что я свой проц вывел из 3D графики. У мну и разработка как X*Y*Z вокселей рисовать за X+Y+Z операций есть, если что.

Вот что я вижу в XSI ICE: то что мы раньше писали «буквами», мы сооружаем из квадратов с соединениями. Погодите, а в чем, собственно, «прогресс»?

Вот я прихожу и говорю: у меня есть Texture3D, каждый блок 16х16х16 которой описывает массив вокселей. Для этих блоков я сгенерю а)массив матриц преобразования координат б) массив указателей вида block_id->matrix_id потому что блоки обычно идут связно и с одной матрицей.

То есть я не хочу нарисовать какие операции будет делать шейдер. Я хочу нарисовать то, какие буфера выделит мой класс на С++ или Java, какие GLSL-программы он построит и как их запустит. Это естественно, будет происходит по «рецептам». Сперва человек сочиняет «рецепт», потом IDE по нему генерит код или не генерит а ругается.

Но просто изображать код шейдеров в виде блоксхемы.... Ну это же пипец.Это дно. Я не понимаю зачем это.