Обширная тема, и я давно хочу написать по ней пост, но если вкратце, то очень хорошо плохой дизайн языка виден на примере функций GetEnv и LookUpEnv. Они обе предназначены для получения значений переменных среды, но GetEnv возвращает строку, которая будет пустой в случае отсутствия такой переменной, а LookUpEnv возвращает кортеж из строкового значения и булевого флага, сигнализирующего о том, найдено ли значение. Зачем же понадобились две функции для выполнения одной и той же задачи? А понадобились они потому, что обработка ошибок в стиле Go слишком многословна. Поэтому, в дополнение к идиоматичной, но неудобной LookUpEnv сделали уродца GetEnv, который возвращает валидное значение в случае ошибки. Можно было бы назвать это частным случаем, но такой подход проистекает из общего плохого дизайна языка. Правильным решением этой конкретной задачи были бы опции, но опций в Go нет и не будет, потому что нет дженериков. Та же история и с типами Result/Try. И из-за этого обработка ошибок в Go обладает целым списком фатальных неодстатков:
Безотносительно противостояния с крестами, просто ремарка: Go спроектирован ужасно.
Чуваааак! Мне пиписьками мериться не интересно, цель я озвучил — тренируюсь писать на новом языке. Это раз. Быстрее или медленнее работают не алгоритмы, а реализации алгоритмов. Это два. И если скорость считать единственным критерием, то мой код дрючит вообще всё. Это три.
Извиняюсь, форматирование полетело. Результаты бенчмарков: pastebin.com/Xft1uRA8
Меж тем, этим вечером я в целях более глубокого освоения Rust решил реализовать на нём какую-нибудь интересную структуру данных. В качестве таковой был выбран HAT-Trie с некоторыми моими изменениями в алгоритме. Матан по HAT-Trie здесь: crpit.com/...
[zenom@lynx release]$ ./rust_playground
Size 1000000
Insert 0 sec 125162718 nanos
Search 0 sec 102876360 nanos
Size 2000000
Insert 0 sec 258873856 nanos
Search 0 sec 221173375 nanos
Size 3000000
Insert 0 sec 392696414 nanos
Search 0 sec 305683095 nanos
Size 4000000
Insert 0 sec 547442910 nanos
Search 0 sec 454124008 nanos
Size 5000000
Insert 0 sec 698278097 nanos
Search 0 sec 532422106 nanos
Size 6000000
Insert 0 sec 866163393 nanos
Search 0 sec 716194667 nanos
Size 7000000
Insert 1 sec 41583520 nanos
Search 0 sec 784532907 nanos
Size 8000000
Insert 1 sec 168931976 nanos
Search 0 sec 920360498 nanos
Size 9000000
Insert 1 sec 357707590 nanos
Search 1 sec 13637407 nanos
Оверхед по памяти:
[zenom@lynx release]$ /bin/time -f "Max resident %M KiB" ./rust_playground > /dev/null
Max resident 191984 KiB
Никакой чёрной оптимизирующей магии пока не применял, писал более-менее идиоматичный Rust-код (с поправкой на то, что сам язык я только осваиваю). Если сообществу будет интересно, то могу после стабилизации, генерализации и возможной оптимизации кода опубликовать исходники, библиотеку и
Для крестов общепринятый подход — нечто, что генерирует makefile. CMakeList.txt, напирмер. Совсем олдскул — автолулзы, но это принято только в GNU-мире.
Самое полезное в треде, я только сейчас узнал об Electric Fence.Вот, кстати, да. Одно это стоило прочтения треда.
О, ты посмотрелся в зеркало? Отлично, это первый шаг к правильным выводам. Только не останавливайся.А когда я ходил в детский садик, то там ещё любили говорить «я в домике». Рекомендую освоить. Как раз соответствует твоему уровню развития.
А тебя никто не заставляет ограничиваться чистым C.Мой код. На чём хочу, на том и пишу. А C++ просто не нужен.
А с учётом того, что тестируемый код на C++, вообще непонятно, откуда и зачем ты взял C.Чувак, вот ты правда думаешь, что я сравниваю что-то с кодом топикстартера? Вот правда?
Хороший метод: сдулся — объявить всё сказанное шуткой и анекдотом. Боюсь только, не пройдёт.Ага, разумеется. Я это всё писал всерьёз. И всерьёз предлагал аллоцировать массив в 16 Гб.
Теперь тебе осталось показать, что кто-то полагается на «конкретные настройки overcommit» при определении скорости.Ты сам мне это предлагал предыдущим постом. У меня все ходы записаны:
Докажи. Более традиционной структурой, которая даёт эффективный поиск и использует такой же «overcommit»
структурой, которая использует такой же «overcommit»
структурой, которая использует «overcommit»
Из этого я и делаю вывод, что проблема std::map или в мелких аллокациях и недружественности к кэшу, или собственно алгоритме с недостаточно «плоским» деревом, или в обоих.В обоих. Крачно-чёрное дерево имеет асимптотическую оценку сложности как вставки, так и поиска O(log n), где n — количество элементов. Кроме того, нелокальные прыжки от ноды к ноде по указателям инвалидируют кэш. Trie имеет оценку O(n), но n в данном случае — это длина ключа. Таким образом, корректнее сравнивать структуру ТС с хэш-мапой.
Что случилось с QNXМожно повторить и на Linux, установив vm.overcommit_memory=2 и, опционально, ограничив vm.overcommit_ratio. На моей машине падение воспроизводится с ограничением памяти до 4 Гб.
Воистину, хуже идиота только агрессивный идиот, упорствующий в своём идиотизме.
Ну тогда тем более сам должен был отловить, или вместо макроса использовать шаблонную функцию.Какие шаблонные функции в C, родное сердце? Ты ещё и C от C++ не отличаешь?
Чтобы доказать, что оверкоммит тут хоть как-то при чём...Достаточно посмотреть на размер аллоцируемой памяти. Если бы не оверкоммит, то процесс был бы прибит OOM-killer’ом.
показать действительно аналогичную реализацию со сравнимой скоростью, которая бы что-то полезное делала, а не просто заливала память константами. Ты даже не попытался это сделать.Божечки! Ну перечитай ты тред, в который я отвечал. Мне реально западло объяснять суть анекдотов тем, до кого они не доходят даже с третьего раза.
Докажи. Более традиционной структурой, которая даёт эффективный поиск и использует такой же «overcommit».Наркоман что ли? Полагаться на overcommit при реализации general-purpose структур нельзя, потому что его настройки могут быть разными. Что, кстати, и произошло выше по треду на QNX, где существуют требования реалтайма и поэтому lazy mapping недопустим.
Чувак! Не тупи ты так яросно, ну!
Доёб к опечатке низащитан. С == тоже замечательно работает.
Чувак, хочешь фокус покажу?
Ололо, моя супер-пупер коллекция обгоняет всё известное науке! Волосы от неё становятся мягкими и шелковистыми! А ещё она решает ближневосточный конфликт и похмеляет с утра!
Тут существует два пути. Первый: получение фундаментальных знаний, знакомство со всеми существующими парадигмами программирования, обзор подходов, существовавших в прошлом, существующих сейчас и тех, которые будут существовать в будущем, затем выбор конкретного направления. Это, очевидно, требует инвестиций сил, времени и денег, что слабо совместимо (не говорю — невозможно) с жёнами, детьми и любовницами. Зато на выходе мы получаем человека, способного на декомпозицию используемых в работе понятий на фундаментальные части и через это способного быстро осваивать новые подходы. Путь второй: курсы условного ПХП и в бой. В принципе, это абсолютно не исключает успешного применения того, чему научили, но освоение нового потребует значительных затрат. В результате, таких специалистов любое колебание рынка смывает подобно тому, как поток воды из бачка смывает дерьмо с белого фаянса унитаза. И поделом.
В чём отличие от наивной реализации trie? Хочется на досуге поковырять, но код весьма слабо читаем.
Кстати. sharpc.livejournal.com/67583.html Вот тут реально магистратура. А мой список — это такое, детский лепет.
Справочные данные и не нужно помнить. Я какой-нибудь формат селектора для 386 процессора тоже не помню. Надо понимать алгоритмы, парадигмы, подходы. Фундаментальные знания, в общем.
Я в дискуссию не вникал и вникать не хочу, но замечу, что было бы очень странно, если бы разработчики утверждали, что второй ангуляр хуже первого. Разработчики — это вообще последние люди, кого надо слушать при выставлении таких оценок.
Это про разные модели разработки. В оригинальном значении термины описаны здесь, например: ru.wikipedia.org/wiki/Собор_и_Базар Но я их использую в более широкой трактовке. В соборной модели есть единый центр принятия решений, отсюда логически следует единый фреймворк, единая платформа как в случае с C# и Obj-C. И есть базарная модель, которая представлена зоопарком разных подходов и фреймворков, как в мире Java.
Если уж уезжать из Украины, то можно найти варианты для поступления получше :)
Аргументом за возврат кортежа для сигнализации ошибки это всё равно не является, т. к. во-первых, это частгый случай, а во-вторых и он прекрасно укладывается в модель ADT.