предлагалось использовать 32-битные относительные указатели в 64-битной системе. Бенчмарки показали заметную экономию памяти, но по скорости работа с такими указателями проигрывала
у меня тоже 32-битные относительные "указатели", но по скорости я выигрываю.
суть проблемы была в быстром копировании хеш-таблицы: это просто memcpy()!
не забывайте систематически шифровать Информацию! Помните, что абсолютно все современные операционные системы, доступные обывателю, являются шпионами. Их главная обязанность -- фильтровать всю доступную информацию и автоматически отправлять кому следует.
когда приходит время оптимизировать память и заниматься разным улучшайзингом, то всегда встают одни и те же вопросы
у вас отсутствует ГЛАВНЫЙ вопрос: где bottleneck?!
Смотрите, даже ДЕСЯТИКРАТНОЕ ускорение "какого-то компонента" просто никто не заметит ... А время и деньги уже потрачены. Так что же, нет смысла стараться?! Ради этого места реального бизнеса АБСОЛЮТНО нет смысла стараться. Хуже дурака -- только дурак с инициативой! Нет смысла стараться нигде, кроме узкого места (bottleneck). Но развальцуете бизнесу bottleneck -- он сразу пойдет веселее!
ок. пусть будет ключ 14 байт, а значения попробуем разные.
const int n=1000, ksz=14, vsz=10;
int data[50];
auto bm=new_blob_map(mp, n, false, mem_hash, mem_equal);
for (int i=0; i<n; i++) {
data[0]=i;
bm->insert({data, ksz}, {data, vsz});
}
out.ex_write(tx_buf(mp)+"used "+bm->info().used+"\n");
в итоге:
n=1000, ksz=14, vsz=10 получаем used 53808
n=1000, ksz=14, vsz=100 получаем used 149808
как вы хотите на hash-таблице сделать итератор по ключам?
нам же достаточно отсортированного массива слов?
значит перед записью таблицы на диск мы создаем себе ключ с отсортированным массивом "указателей" на слова. все! загружаем где угодно и сразу же пользуемся.
"Никогда не пишите свою собственную криптографию" -- говорили они. Но сейчас любой школьник с удовольствием перетасует байты зашифрованного файла -- и вот вам "новый алгоритм"! Сколько честных криптостойких алгоритмов могли использовать простые люди? Пять? Десять?? А сейчас их появятся ТЫСЯЧИ! https://ders.by/crypt/derscrypt2/derscrypt2.html
«Мы хотим гарантировать, что у ЦРУ всегда будет доступ к вашим файлам, приложениям и паролям»
...не забывайте систематически шифровать Информацию! Помните, что абсолютно все современные операционные системы, доступные обывателю, являются шпионами. Их главная обязанность -- фильтровать всю доступную информацию и автоматически отправлять кому следует. https://ders.by/crypt/derscrypt2/derscrypt2.html
Постарайтесь внимательно проследить за ходом его мысли. По мере того как вы будете вникать в суть рассуждений Эйнштейна, вы вдруг поймаете себя на том, что...
...сжимаете кулаки!
а давайте-ка напомним еще одну "теорию заговора", как водится, оказавшуюся правдой: GPS! знаете ли вы, что спутники GPS не делают поправки на теорию относительности?
большую часть времени программист тратит на обдумывание
да.
и на отладку кода
НЕТ!
"продуманный" код в отладке почти не нуждается. а если кто-то долго отлаживает СВОЙ СОБСТВЕННЫЙ код, то это плохой кодировщик ;)
вопрос даже не в скорости мыслительного процесса
как сто слепых не заменят одного зрячего, так и сто дураков одного умного.
задачи "умного" не пересекаются с остальными. и в пределе тут нет фактора Времени, т.к. представители интеллектуального большинства вообще не решат Задачу.
На эту работу нас подвигло желание узнать, почему в программной инженерии некоторые люди на порядок, а то и два, полезнее большинства людей. Если бы так было у каменщиков, то строительная индустрия очень заинтересовалась бы причиной. Проблема, конечно, в том, что о каменщике за работой можно снять фильм, а затем его действия проанализировать. Но невозможно увидеть, что делают великие программисты, да и они сами не смогли бы объяснить разницу, хотя большинство из них и захотело бы это сделать. ... Достижение понимания происходящего заняло долгое время, хотя ключевые идеи уже давно известны большинству из нас. По пути мы изучили склад мышления достигших успеха программистов и смогли разработать упражнения, которые обязательно помогут многим. Этот материал создавался несколько лет и является смесью идей, эмпирически подправленных экспериментами и позднее собранных в единую логичную картинку, а также материала, полученного на основе этой картинки.
Цель этой работы -- донести элементы "опыта" или "взглядов", на которые повсеместно ссылаются, но редко описывают. Многие темы -- это то, что программисты обсуждают за пивом. Кажется странным, что никто не стремится узнать, как проблемы, которые программисты считают наиболее важными, соотносятся с "формальными" структурами современной инженерии. Здесь мы делаем именно это.
Если мы попали в точку, большинство программистов получают удобный случай поместить волновавшие их долгие годы проблемы в ясный рабочий контекст. Мы предлагаем расслабиться и хорошо провести время!
интересно?
узкий круг ограниченных лиц применяет это на практике... вы не поверите СКОЛЬКО лет!
привет, рад новой встрече! в своей прошлой статье вы так и не дали ВНЯТНОГО ответа. зело продолжим:
Дано. Для "повышения безопасности", вы храните в ПровайдереСекретов Секреты для доступа к Серверам. Вопрос: Где вы храните Секреты для доступа к самому ПровайдеруСекретов?
мда... словно песок жуешь.
про C++ писать нужно легко и весело: https://ders.by/cpp/norefs/norefs.html
у меня тоже 32-битные относительные "указатели", но по скорости я выигрываю.
суть проблемы была в быстром копировании хеш-таблицы: это просто memcpy()!
вот алгоритм с картинками: https://ders.by/cpp/memdb/memdb.html#4
и я вам скажу даже больше.
можно изобрести Хеш-таблицу с транзакциями, где 32-битные "указатели" легко и просто адресуют более 4 гигабайт: https://ders.by/cpp/deque/deque.html#7
как обычно, все бурлит не по теме и не видно конкретики... ну окай, я немножко наброшу.
в C++98 у нас было:
а в C++20 мы наконец-то обрели:
во что превратился любимый наш сердцу find()? в Чудовищное Говно!
ЗЫ как жить без каки: https://ders.by/cpp/norefs/norefs.html
к сожалению, очень много "общего текста" без конкретики C++17, C++20 и ТП...
а если по времени компиляции, то Дело спасает Системый подход! но в хаосе игродева он невозможен. точка.
ЗЫ если у вас мало Хаоса, то хотя бы:
не включайте не нужные хедеры.
целенаправленно и системно используйте интерфейсы - они скрывают от компилятора требуху реализации и не требуют не нужных хедеров.
используйте unity build.
ЗЗЫ unity build - это когда вместо десятка файлов src\*.cpp билдят всего один src\unity\build.cpp:
вот код и сама статья: https://ders.by/cpp/deque/deque.html
не забывайте систематически шифровать Информацию!
Помните, что абсолютно все современные операционные системы, доступные обывателю, являются шпионами. Их главная обязанность -- фильтровать всю доступную информацию и автоматически отправлять кому следует.
https://ders.by/crypt/derscrypt2/derscrypt2.html
у вас отсутствует ГЛАВНЫЙ вопрос: где bottleneck?!
Смотрите, даже ДЕСЯТИКРАТНОЕ ускорение "какого-то компонента" просто никто не заметит ... А время и деньги уже потрачены.
Так что же, нет смысла стараться?!
Ради этого места реального бизнеса АБСОЛЮТНО нет смысла стараться. Хуже дурака -- только дурак с инициативой!
Нет смысла стараться нигде, кроме узкого места (bottleneck). Но развальцуете бизнесу bottleneck -- он сразу пойдет веселее!
https://ders.by/arch/scale/scale.html
ок. пусть будет ключ 14 байт, а значения попробуем разные.
в итоге:
n=1000, ksz=14, vsz=10 получаем used 53808
n=1000, ksz=14, vsz=100 получаем used 149808
нам же достаточно отсортированного массива слов?
значит перед записью таблицы на диск мы создаем себе ключ с отсортированным массивом "указателей" на слова. все! загружаем где угодно и сразу же пользуемся.
ой ли! создаете ключ с нужным вам порядком элементов и пишете таблицу на диск.
а если надо, то и несколько разных "порядков".
с чего бы?
назовите мне средний размер ключа/значения, и я вам скажу размер.
лучше сразу смотрите на Хеш-таблицу с транзакциями https://ders.by/cpp/memdb/memdb.html
вся хеш-таблица хранится в одном блоке памяти, т.к. вместо указателей используются смещения от начала блока.
таким образом, копирование всей таблицы - один вызов memcpy()! а дальше пишите в файл, передавайте по шлангу... все что угодно ;)
ну и, естественно, O(1) для поиска элементов. а у дерева логарифм.
"Никогда не пишите свою собственную криптографию" -- говорили они. Но сейчас любой школьник с удовольствием перетасует байты зашифрованного файла -- и вот вам "новый алгоритм"!
Сколько честных криптостойких алгоритмов могли использовать простые люди? Пять? Десять?? А сейчас их появятся ТЫСЯЧИ!
https://ders.by/crypt/derscrypt2/derscrypt2.html
...не забывайте систематически шифровать Информацию!
Помните, что абсолютно все современные операционные системы, доступные обывателю, являются шпионами. Их главная обязанность -- фильтровать всю доступную информацию и автоматически отправлять кому следует.
https://ders.by/crypt/derscrypt2/derscrypt2.html
о боже, ШИКАРНЫЙ камент!
файл README там, конечно, для слабаков.
таки не поверим и внесем изменения здесь:
и здесь:
а теперь запускаем:
ну и??
ЗЫ еще раз убеждаюсь, что главная проблема C++ это некомпетентые кодировщики.
гмм, даже стало интересно!
криптография 2004-2006 года - это старый и сложный код?
берем свежий компилятор:
берем исходники DersCrypt https://ders.by/crypt/derscrypt/cpp/src.zip
и делаем:
и кроме идиотского "suggest parentheses" все прекрасно собралось и отлично работает!
ЗЫ может дело немножно в руках?
право слово, как дети...
Главная Цель любого комитета по ХХХ - гарантировать свое существование! а проблемы самого ХХХ тут дело десятое.
далее.
C++ "зашел не в ту дверь" еще при Страуструпе. но! если выбросить ерунду, то можно прекрасно ехать.
вот вы, например, чего бы хотели выбросить??
https://ders.by/cpp/norefs/norefs.html
...сжимаете кулаки!
а давайте-ка напомним еще одну "теорию заговора", как водится, оказавшуюся правдой: GPS!
знаете ли вы, что спутники GPS не делают поправки на теорию относительности?
всё. точка! любой физик поймет, что это значит.
да.
НЕТ!
"продуманный" код в отладке почти не нуждается.
а если кто-то долго отлаживает СВОЙ СОБСТВЕННЫЙ код, то это плохой кодировщик ;)
как сто слепых не заменят одного зрячего, так и сто дураков одного умного.
задачи "умного" не пересекаются с остальными. и в пределе тут нет фактора Времени, т.к. представители интеллектуального большинства вообще не решат Задачу.
о! а вот это прямо по теме:
интересно?
узкий круг ограниченных лиц применяет это на практике... вы не поверите СКОЛЬКО лет!
The Programmers' Stone https://ders.by/pp/ps/index.html
это правильный ответ.
небезопасно хранить Секреты доступа к ПровайдеруСекретов - это глупо. а их невозможно хранить иначе.
привет, рад новой встрече!
в своей прошлой статье вы так и не дали ВНЯТНОГО ответа. зело продолжим:
Дано. Для "повышения безопасности", вы храните в ПровайдереСекретов Секреты для доступа к Серверам.
Вопрос: Где вы храните Секреты для доступа к самому ПровайдеруСекретов?