В 2001-м году я менял в одном офисе коаксиал на utp 100 Мбит. Это был совсем небольшой офис, свитч был то ли 8, то ли 16 дырок. После замены осталась кучка коаксиала и платы. Руководитель офиса спросил, что можно сделать с этим, думая, что может куда-то продать. Пришлось его расстроить, сказав, что максимум на что это годится - отдать детям, соединить компы в соседних квартирах, чтобы в квейк по сети играть, а через годик-другой выкинуть окончательно.
Так я как раз про то, что нет таких максималистских по-детски правил, что "всегда синтетика" или "естественный ключ есть? а если найду?". Более того, догматичность тоже не догма: иногда отход от догм позволяет увидеть крутое решение, иногда приводит к винегрету решений.
Как-то бессмысленно дискутировать с переводом, но таки напишу. Синтетические ключи - неплохой (часто лучший) выбор для сущностей, т.е. строк, в БД обладающих идентичностью. 2 человека - как ни меняй их имена, пол, дату рождения и паспорт всё равно остаются двумя разными людьми. Используйте синтетический ключ. Если же запись таблицы не является сущностью или её сущность полностью описывается естественным ключом, то синтетический ключ только поломает всё. Примеры, когда сущность полностью описывается ключом: таблица недействительных паспортов, таблица праздничных дней (часто любой календарь). Примеры, когда запись таблицы не является сущностью: отношения многие ко многим (там просто составной ключ родительских таблиц какие бы они ни были).
Плюс есть гора особых случаев. Не всё сводится к классическим справочникам и OLTP. Есть и time-series и OLAP, и куча того, что вообще отвратительно в таблицы ложится.
Смотрите. Рассмотрим простой-простой "uFP8" тип беззнаковый и 8-битный. 4 бита на порядок, 4 на экспоненту. Забудем о NaN, Inf и нормализацию и уникальность нуля. Будем считать, что экспонента всегда положительная. Будем считать, что старший бит мантиссы соответствует 1*2^exp, где exp это порядок. Упрощений много, но на самом деле они почти не влияют на конечную картину. Т.е. у нас есть 0 (0000-0000, где первые 4 бита порядок, потом мантисса) и числа от 1/8 (0000-0001) до 15*2^15=491520 (1111-1111). При этом из-за отсутствия нормализации некоторые числа имеют несколько представлений. Например, 4 может быть представлено как 0010-1000 или как 0011-0100 или как 0100-0010 или как 0101-0001. Теперь будем раскладывать наше uFP8 число, например 1280 (1010-1010) на 4-битные непересекающиеся компоненты:
Для примера, самое маленькое число:
0000-0001 xxxxxxxxxxxxxxx0001 - это 1/8, на местах x неявные нулевые биты
Самое большое число:
1111-1111 1111xxxxxxxxxxxxxxx - это 15*2^15=491520, на местах x неявные нулевые биты
Наше число:
1010-1010 xxxxx1010xxxxxxxxxx
порядок мантисса
0000 0000
0100 0000
1000 1000
1100 0010
10000 x000 - тут на месте x всегда неявный 0
Таким образом мы каждое наше исходное число можем разложить в 4 числа по 4 бита и одно по 3, т.е. в 19 бит. Технически (для управления переполнениями при сложении), наверное чуть удобнее раскладывать в 4 пятибитовых числа и 1 четырёхбитовое - 24 бита суммарно. Но это непринципиально. Ну и да, раскладка сожрёт несколько тактов. Аналогично, но с учетом других размеров, знака, NaN, Inf и нормализации можно раскладывать и FP32/FP64.
Другой способ заключается в хранении большого буфера целых чисел... Этот способ требует времени 𝑂(𝑛), но использует большой, хотя и константный объём памяти (≈≈ 1 КБ в случае f32, ≈≈ 16 КБ в случае f64).
Это неправильная оценка. В f32 8 бит экспонента (порядок) и 23 мантисса. Итого достаточно 279 бит. Не то чтобы много, но никаких килобайт не надо. Это 9 32-битных чисел, 5 64-битных или 3 128-битных xmm регистра. В f64 11 бит порядок и 52 мантисса. 66 32-битных, 33 64-битных, 17 128-битных чисел.Опять же - ужас, но не ужас-ужас. Другой вопрос, что по ним распихивать слагаемые неудобно (навскидку - 5-10 тактов запросто уйдёт).
Виктимблейминг в современном обществе не одобряется и считается практически неприличным, и не должен проявляться ни в отношениях в быту, ни в воспитании детей, ни в руководстве коллективом. Можно было придумать более удачные примеры с взятием ответственности, но то что у вас есть именно этот пример - это может быть одним из "красных флажков" (не единственным) для того, кто знакомится с вашим "контрактом". По ситуации:
200 метров это очень странная дистанция для примера. Это 2 футбольных поля в длину, ГУМ на красной площади 250 метров в длину. Вечером в темноте "почти без фонарей" на этом расстоянии я не знаю что можно достоверно разглядеть.
Антагонистов вашей истории корректнее называть не "пацанчики", а "преступники". Причём скорее всего они по сценарию совершают тяжкое преступление (грабёж или разбой группой лиц).
Мой жизненный опыт мне также подсказывает, что подобные ограбления слабо зависят от освещённости, нередко происходят буквально в 20-30 метрах от других людей, и что в реальной ситуации нормальный неподготовленный человек не успевает уйти от тех, кто целенаправленно готов пойти на тяжкое преступление.
Еще к собеседованиям я бы добавил, что надо учитывать при выборе не только компанию, но и конкретную команду. В любой компании, где больше 50-100 разработчиков скорее всего есть сильно разные команды. С разным стеком, разным руководителем, разной культурой и традициями. Особенно это касается больших компаний - там отзывы сотрудников о работодателе могут быть противоположными и при этом объективными.
Да просто в статье всё верно написано, но есть разделы "Что делать с ...", А, собственно, какой смысл делать, если блокировки не должно было быть в принципе. Только поэтому и прокомментировал.
Стоит сказать, что первым делом имеет смысл проверить, использует ли 1С RCSI. Сейчас в 2024 году уже осталось очень мало систем, где не включен RCSI, но всё же.
Если он в отдельной песочнице, то пусть в своей песочнице переделывает секции хоть каждый день :) Другое дело, что именно эта оптимизация будет уж совсем бесполезна и ничего он не наоптимизирует, но именно это и вызывает удивление в статье.
Оптимальным решением по скорости проверки в данном случае было заранее вычислить все простые числа, соответствующие нашим требованиям, и положить их в массив/хеш-таблицу, чтобы потом делать там поиск. Всего их вышло бы около 105 миллионов. Этого я делать не буду, чтобы избежать долгих предварительных вычислений.
Всё-таки не хватает сравнения с этим вариантом. Насколько я помню из своих экспериментов, хорошее решето Эратосфена на этих числах будет очень эффективным и "долгие предварительные вычисления" безо всяких векторизаций укладываются в несколько секунд или около того. Для "хорошести" надо использовать wheel optimization и не совершать грубых ошибок (часто забывают, что "вычёркивать" надо числа начиная с квадрата простого). Хранить числа конечно же стоит в битовом массиве - это 256 МБ всего лишь даже без оптимизаций. С той же wheel optimization в 3-4 раза меньше.
Wheel optimization это когда мы учитываем, что простые числа могут давать только некоторые из остатков от деления на небольшие произведения различных простых чисел. Если wheel только число 2, то остаются только нечётные и 2, если wheel = 2 * 3 = 6, то простые числа больше 3 дают только +-1 по модулю 6 (уже 1/3 чисел осталась), если wheel = 2*3*5 = 30, то остаются 1,7,11,13,17,19,23,29 - 8 из 30. Цикл 2*3*5*7 уже не очень практичен, но возможен. Это можно использовать и в цикле решета и при хранении.
Для баз данных не так важно "выводить ошибки на местных языках". Гораздо важнее правильно сортировать списки по алфавиту, причем не только в выводе но и внутри БД (в индексах). И часто получается, что символы к кодировке (в том числе в юникодных) в лучшем случае отсортированы для одного языка. А для той же кириллицы алфавитов разных языков целая куча.
Могут быть другие моменты, типа привязки формата дат к локали, но это уже не должно на самом деле "утекать" в БД. В 1999 году, когда я только начинал программировать я замучался исправлять баг, который был связан именно с датами - я передавал данные из строки напрямую в SQL запрос и происходила путаница между форматами DD.MM.YYYY и MM/DD/YYYY. Очевидно, что в моём случае ошибка была в том, что в БД надо было передавать дату в формате ISO 8601 и не зависеть от локали.
В 2001-м году я менял в одном офисе коаксиал на utp 100 Мбит. Это был совсем небольшой офис, свитч был то ли 8, то ли 16 дырок. После замены осталась кучка коаксиала и платы. Руководитель офиса спросил, что можно сделать с этим, думая, что может куда-то продать. Пришлось его расстроить, сказав, что максимум на что это годится - отдать детям, соединить компы в соседних квартирах, чтобы в квейк по сети играть, а через годик-другой выкинуть окончательно.
Так я как раз про то, что нет таких максималистских по-детски правил, что "всегда синтетика" или "естественный ключ есть? а если найду?". Более того, догматичность тоже не догма: иногда отход от догм позволяет увидеть крутое решение, иногда приводит к винегрету решений.
Как-то бессмысленно дискутировать с переводом, но таки напишу. Синтетические ключи - неплохой (часто лучший) выбор для сущностей, т.е. строк, в БД обладающих идентичностью. 2 человека - как ни меняй их имена, пол, дату рождения и паспорт всё равно остаются двумя разными людьми. Используйте синтетический ключ.
Если же запись таблицы не является сущностью или её сущность полностью описывается естественным ключом, то синтетический ключ только поломает всё.
Примеры, когда сущность полностью описывается ключом: таблица недействительных паспортов, таблица праздничных дней (часто любой календарь).
Примеры, когда запись таблицы не является сущностью: отношения многие ко многим (там просто составной ключ родительских таблиц какие бы они ни были).
Плюс есть гора особых случаев. Не всё сводится к классическим справочникам и OLTP. Есть и time-series и OLAP, и куча того, что вообще отвратительно в таблицы ложится.
Смотрите. Рассмотрим простой-простой "uFP8" тип беззнаковый и 8-битный. 4 бита на порядок, 4 на экспоненту. Забудем о NaN, Inf и нормализацию и уникальность нуля. Будем считать, что экспонента всегда положительная. Будем считать, что старший бит мантиссы соответствует
1*2^exp, где exp это порядок. Упрощений много, но на самом деле они почти не влияют на конечную картину. Т.е. у нас есть 0 (0000-0000, где первые 4 бита порядок, потом мантисса) и числа от 1/8 (0000-0001) до 15*2^15=491520 (1111-1111).При этом из-за отсутствия нормализации некоторые числа имеют несколько представлений. Например, 4 может быть представлено как 0010-1000 или как 0011-0100 или как 0100-0010 или как 0101-0001.
Теперь будем раскладывать наше uFP8 число, например 1280 (1010-1010) на 4-битные непересекающиеся компоненты:
Таким образом мы каждое наше исходное число можем разложить в 4 числа по 4 бита и одно по 3, т.е. в 19 бит.
Технически (для управления переполнениями при сложении), наверное чуть удобнее раскладывать в 4 пятибитовых числа и 1 четырёхбитовое - 24 бита суммарно. Но это непринципиально. Ну и да, раскладка сожрёт несколько тактов.
Аналогично, но с учетом других размеров, знака, NaN, Inf и нормализации можно раскладывать и FP32/FP64.
Это неправильная оценка. В f32 8 бит экспонента (порядок) и 23 мантисса. Итого достаточно 279 бит. Не то чтобы много, но никаких килобайт не надо. Это 9 32-битных чисел, 5 64-битных или 3 128-битных xmm регистра. В f64 11 бит порядок и 52 мантисса. 66 32-битных, 33 64-битных, 17 128-битных чисел.Опять же - ужас, но не ужас-ужас.
Другой вопрос, что по ним распихивать слагаемые неудобно (навскидку - 5-10 тактов запросто уйдёт).
А есть замер?
Виктимблейминг в современном обществе не одобряется и считается практически неприличным, и не должен проявляться ни в отношениях в быту, ни в воспитании детей, ни в руководстве коллективом. Можно было придумать более удачные примеры с взятием ответственности, но то что у вас есть именно этот пример - это может быть одним из "красных флажков" (не единственным) для того, кто знакомится с вашим "контрактом".
По ситуации:
200 метров это очень странная дистанция для примера. Это 2 футбольных поля в длину, ГУМ на красной площади 250 метров в длину. Вечером в темноте "почти без фонарей" на этом расстоянии я не знаю что можно достоверно разглядеть.
Антагонистов вашей истории корректнее называть не "пацанчики", а "преступники". Причём скорее всего они по сценарию совершают тяжкое преступление (грабёж или разбой группой лиц).
Мой жизненный опыт мне также подсказывает, что подобные ограбления слабо зависят от освещённости, нередко происходят буквально в 20-30 метрах от других людей, и что в реальной ситуации нормальный неподготовленный человек не успевает уйти от тех, кто целенаправленно готов пойти на тяжкое преступление.
Еще к собеседованиям я бы добавил, что надо учитывать при выборе не только компанию, но и конкретную команду. В любой компании, где больше 50-100 разработчиков скорее всего есть сильно разные команды. С разным стеком, разным руководителем, разной культурой и традициями. Особенно это касается больших компаний - там отзывы сотрудников о работодателе могут быть противоположными и при этом объективными.
Скриптом на VBS, который не хотел уходить на пенсию :)
Одновременно с выпуском Intel Xeon Athlon
Часто пользуюсь посмотреть простые случаи и в качестве демо. В сложных всё равно лучше локально разгребать, но для простых - отлично подходит.
Или поглотят как Mono
И обязательно Tear Tier - "мы не хотели, но оно появилось и есть" :)
Да просто в статье всё верно написано, но есть разделы "Что делать с ...", А, собственно, какой смысл делать, если блокировки не должно было быть в принципе. Только поэтому и прокомментировал.
Да ладно, они же такие милые и уютные IUnknown и IDispatch, компилятор MIDL, OLE,
Стоит сказать, что первым делом имеет смысл проверить, использует ли 1С RCSI. Сейчас в 2024 году уже осталось очень мало систем, где не включен RCSI, но всё же.
Интересно читать такую статью в блоге провайдера хостинга.
Если он в отдельной песочнице, то пусть в своей песочнице переделывает секции хоть каждый день :) Другое дело, что именно эта оптимизация будет уж совсем бесполезна и ничего он не наоптимизирует, но именно это и вызывает удивление в статье.
Всё-таки не хватает сравнения с этим вариантом. Насколько я помню из своих экспериментов, хорошее решето Эратосфена на этих числах будет очень эффективным и "долгие предварительные вычисления" безо всяких векторизаций укладываются в несколько секунд или около того. Для "хорошести" надо использовать wheel optimization и не совершать грубых ошибок (часто забывают, что "вычёркивать" надо числа начиная с квадрата простого). Хранить числа конечно же стоит в битовом массиве - это 256 МБ всего лишь даже без оптимизаций. С той же wheel optimization в 3-4 раза меньше.
Wheel optimization это когда мы учитываем, что простые числа могут давать только некоторые из остатков от деления на небольшие произведения различных простых чисел. Если wheel только число 2, то остаются только нечётные и 2, если
wheel = 2 * 3 = 6, то простые числа больше 3 дают только +-1 по модулю 6 (уже 1/3 чисел осталась), еслиwheel = 2*3*5 = 30, то остаются 1,7,11,13,17,19,23,29 - 8 из 30. Цикл2*3*5*7уже не очень практичен, но возможен. Это можно использовать и в цикле решета и при хранении.Для баз данных не так важно "выводить ошибки на местных языках". Гораздо важнее правильно сортировать списки по алфавиту, причем не только в выводе но и внутри БД (в индексах). И часто получается, что символы к кодировке (в том числе в юникодных) в лучшем случае отсортированы для одного языка. А для той же кириллицы алфавитов разных языков целая куча.
Могут быть другие моменты, типа привязки формата дат к локали, но это уже не должно на самом деле "утекать" в БД. В 1999 году, когда я только начинал программировать я замучался исправлять баг, который был связан именно с датами - я передавал данные из строки напрямую в SQL запрос и происходила путаница между форматами DD.MM.YYYY и MM/DD/YYYY. Очевидно, что в моём случае ошибка была в том, что в БД надо было передавать дату в формате ISO 8601 и не зависеть от локали.