Software Development Engineer в Amazon
  • О применении C++ и других монстрами индустрии

    Аргументом за возврат кортежа для сигнализации ошибки это всё равно не является, т. к. во-первых, это частгый случай, а во-вторых и он прекрасно укладывается в модель ADT.

  • О применении C++ и других монстрами индустрии

    Обширная тема, и я давно хочу написать по ней пост, но если вкратце, то очень хорошо плохой дизайн языка виден на примере функций GetEnv и LookUpEnv. Они обе предназначены для получения значений переменных среды, но GetEnv возвращает строку, которая будет пустой в случае отсутствия такой переменной, а LookUpEnv возвращает кортеж из строкового значения и булевого флага, сигнализирующего о том, найдено ли значение. Зачем же понадобились две функции для выполнения одной и той же задачи? А понадобились они потому, что обработка ошибок в стиле Go слишком многословна. Поэтому, в дополнение к идиоматичной, но неудобной LookUpEnv сделали уродца GetEnv, который возвращает валидное значение в случае ошибки. Можно было бы назвать это частным случаем, но такой подход проистекает из общего плохого дизайна языка. Правильным решением этой конкретной задачи были бы опции, но опций в Go нет и не будет, потому что нет дженериков. Та же история и с типами Result/Try. И из-за этого обработка ошибок в Go обладает целым списком фатальных неодстатков:

    • Возможность обратиться к полю кортежа, которое неопределено. Возвращать кортеж для сигнализации об ошибке — несусветная глупость, потому что в нём всегда валидно только одно поле, а возвращаются сразу два
    • Проигнорировать наличие ошибки проще, чем проверить
    • Необходимость наличия в языке такой пакости, как нулевые указатели для маркировки неопределённого значения
    • Общая многословность обработки ошибок.
  • О применении C++ и других монстрами индустрии

    Безотносительно противостояния с крестами, просто ремарка: Go спроектирован ужасно.

    Поддержал: Vitaly Chernooky
  • Самый быстрый Индиан

    Чуваааак! Мне пиписьками мериться не интересно, цель я озвучил — тренируюсь писать на новом языке. Это раз. Быстрее или медленнее работают не алгоритмы, а реализации алгоритмов. Это два. И если скорость считать единственным критерием, то мой код дрючит вообще всё. Это три.

    Поддержал: Andrii Uhryniuk
  • Самый быстрый Индиан

    Извиняюсь, форматирование полетело. Результаты бенчмарков: pastebin.com/Xft1uRA8

  • Самый быстрый Индиан

    Меж тем, этим вечером я в целях более глубокого освоения Rust решил реализовать на нём какую-нибудь интересную структуру данных. В качестве таковой был выбран HAT-Trie с некоторыми моими изменениями в алгоритме. Матан по HAT-Trie здесь: crpit.com/...apers/CRPITV62Askitis.pdf Свои изменения я опишу, если кому-то будет интересно. За сегодняшний вечер получены результаты для 32-разрядных ключей и значений:
    [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-код (с поправкой на то, что сам язык я только осваиваю). Если сообществу будет интересно, то могу после стабилизации, генерализации и возможной оптимизации кода опубликовать исходники, библиотеку и C-биндинги к ней.

  • Самый быстрый Индиан

    Для крестов общепринятый подход — нечто, что генерирует makefile. CMakeList.txt, напирмер. Совсем олдскул — автолулзы, но это принято только в GNU-мире.

    Поддержали: anonymous, Eugene Nuribekov
  • Самый быстрый Индиан

    Самое полезное в треде, я только сейчас узнал об 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 недопустим.
  • Самый быстрый Индиан

    Чувак! Не тупи ты так яросно, ну!


    1. -Wall такую ошибку в макросе не ловит, только в условном операторе. Иди читай ман по опциям gcc дальше
      Шутка, явно обозначенная таковой, не применимая на практике и работающая только за счёт оверкоммита, — это, разумеется, то самое место, где нужно искать опцию, которая позволит-таки поймать это предупреждение
      В коде нет ни одного ключа, идентичного другому. Идентичны только значения, которые могут быть вообще любыми. Если ты не отличаешь ключ от значения, то я сомневаюсь, что ты вообще способен хоть на какую-то осмысленную деятельность
      «Палево» здесь заключается не в значении ключей, а в настройках оверкоммита, что совершенно очевидно как из истории команд, так и из контекста, в котором я написал свой комментарий
  • Итого, чувак, не отличающий ключ от значения и не знающий, что такое оверкоммит, приходит рассказывать мне про отличие сравнения от присваивания. У тебя что, линтер вместо мозга?
  • Самый быстрый Индиан

    Доёб к опечатке низащитан. С == тоже замечательно работает.

  • Самый быстрый Индиан

    Чувак, хочешь фокус покажу?

    pastebin.com/3smXd8iA

    Ололо, моя супер-пупер коллекция обгоняет всё известное науке! Волосы от неё становятся мягкими и шелковистыми! А ещё она решает ближневосточный конфликт и похмеляет с утра!

  • Какая реальная реальность в ІТ?

    Тут существует два пути. Первый: получение фундаментальных знаний, знакомство со всеми существующими парадигмами программирования, обзор подходов, существовавших в прошлом, существующих сейчас и тех, которые будут существовать в будущем, затем выбор конкретного направления. Это, очевидно, требует инвестиций сил, времени и денег, что слабо совместимо (не говорю — невозможно) с жёнами, детьми и любовницами. Зато на выходе мы получаем человека, способного на декомпозицию используемых в работе понятий на фундаментальные части и через это способного быстро осваивать новые подходы. Путь второй: курсы условного ПХП и в бой. В принципе, это абсолютно не исключает успешного применения того, чему научили, но освоение нового потребует значительных затрат. В результате, таких специалистов любое колебание рынка смывает подобно тому, как поток воды из бачка смывает дерьмо с белого фаянса унитаза. И поделом.

  • Самый быстрый Индиан

    В чём отличие от наивной реализации trie? Хочется на досуге поковырять, но код весьма слабо читаем.

  • Что актуальней Frontend, Backend, mobile dev?

    Кстати. sharpc.livejournal.com/67583.html Вот тут реально магистратура. А мой список — это такое, детский лепет.

  • Что актуальней Frontend, Backend, mobile dev?

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

  • Что актуальней Frontend, Backend, mobile dev?

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

    Поддержали: Oksana Chuiko, NewOne NewOne
  • Что актуальней Frontend, Backend, mobile dev?

    Это про разные модели разработки. В оригинальном значении термины описаны здесь, например: ru.wikipedia.org/wiki/Собор_и_Базар Но я их использую в более широкой трактовке. В соборной модели есть единый центр принятия решений, отсюда логически следует единый фреймворк, единая платформа как в случае с C# и Obj-C. И есть базарная модель, которая представлена зоопарком разных подходов и фреймворков, как в мире Java.

    Поддержал: Sergey Sheshenya
  • Что актуальней Frontend, Backend, mobile dev?

    Если уж уезжать из Украины, то можно найти варианты для поступления получше :)

  • ← Сtrl 123 Ctrl →