А кто-нибудь может прояснить логичекую цепочку, следуя которой if constexpr(false) ограничили до "during the instantiation of an enclosing templated entity" при инсталляции substatement?
Т.е. что помешало сделать поведение if constexpr более регулярным и удобным (как мне представляется)?
Насчет "FreeBSD лучше Linux на multicore" — это давно устаревшая информация, очень давно. Кто-то даже может резонно спорить что это "совсем не правда и быть не может", но я просто помню что когда-то это было именно так.
Но "эпоха" закончилось где-то перед Linux 2.6.32. Хотя еще можно найти бенчмарки, в которых какой-то софт быстрее работает во FreeBSD (как правило из-за того, что делает что-то не правильно в Linux и/или не использует splice/sendfile т.д.). Еще есть бенчмарки (сомнительные, если разобраться), в которых FreeBSD внезапно в 2 раза быстрее (а в Linux при этом забывают выключить THP, SELinux и т.п.).
FreeBSD — хорошая система, но в Linux огромный объем превосходного кода. Тот случай, когда лучшее не враг хорошего, а просто превзошло его.
"Толсто намекаю" но не только на AVX/AVX2, а в том числе на SSE2 (пример), ибо доступно на всех 64-битных x86 и дает ~4-х кратное ускорение в сравнении с 7-ю инструкциями (насколько помню, код в примере быстрее "просто сканирования" в ~10 раз).
Понял, спасибо за ответ. Посредством git grep получил остальные ответы.
fork мне нужен только для тестов и может быть заменен на exec с передачей контекста через аргументы (как в Windows).
основной "блокер" видимо в отсутствии mmap(file) и msync(), соответственно требуется заменять mmap() на malloc() + read(), а запись в mmap-регион заменять на memcpy() + write().
Антон, у меня off-topic вопрос. Меня попросили оценить возможность и трудоемкость поддержки Embox в libmdbx, но я не смог быстро найти информацию что именно и из какой версии POSIX у вас поддерживается.
Можете по-быстрому подсказать что есть в наличии из списка: fork, mmap(MAP_SHARED), mutex(PTHREAD_PROCESS_SHARED), msync(MS_ASYNC/MS_ASYNC), fdatasync(), fcntl(F_OFD_SETLK или F_SETLK)? Как вариант — просто покажите список символов из libc, librt/libpthread.
От приложения до условной поверхности диска у вас могут быть несколько посредников: какой-нибудь asyncio-фреймворк, ядро, гипервизор, кеширующий контроллер с батарейкой или без, контроллер диска с батарейкой/конденсатором или без.
Если хотя-бы кто-то из посредников "без батарейки" пере-упорядочивает запись, то целостность данных не гарантируется.
В упомянутом цикле не ожидание блокировки, а сканирование битовой карты.
Качество кода, с точки зрения оптимизации производительности, в Windows (aka mustdie) местами уже давно никакое, даже в некоторых критичных местах. Почему — отдельный разговор. Но в качестве "пруфа" просто посмотрите на эти несчастные семь инструкций: на 64-битой супер-скалярной платформе поиск ведется тупым циклом с 32-битным сравнением (надо примерно так).
В описанной ситуации добавляется еще какой-то системный/алгоритмический просчет или ошибка, ибо достаточно глупо (даже для Windows) каждый раз сканировать всё карту блоков с самого начала (хотя такое уже видели). Т.е. видимо какая-то ошибка в поддержке индекса/кэша, либо в его постоянной инвалидации. Но вникать нет никакого желания (в том числе читать треды по ссылкам) — гораздо проще и эффективнее на больших серверах использовать подходящую ОС, а не садиться на desktop-кактус ;)
Гугл и DWare так много говорили о своем "отжиге", а потом о 51-кубитном симуляторе, что я перестал следить за новостями от них.
Более того, я (пока еще) не до конца верю в их 51-кубитный вычислитель. Логично предположить что они сделали аналогичный по-параметрам симулятор именно для верификации реального вычислителя. Но возникает глупое сомнение — может они и считали на симуляторе ;)
Можно верифицировать решение, в том числе переформулируя задачу (т.е. получая другой ландшафт вероятностей для локальных минимумов). С некоторой вероятностью это будет давать решение некоторой точности… Тем не менее, IMHO это видится более "перспективным" в сравнении с "универсальным вычислителем" (хайп похож на распил бюджетов на пост-квантовую криптографию).
Если смотреть на struct Queue, то два первых атомика будут в одной кеш-линии, которую продьюсер и консьюмер будут отбирать друг у друга. Хотя вероятно в реальном коде не так, но в 1Hippeus очереди всё равно были быстрее ;)
Там же классический циклический буфер фиксированного размера. До mostly-lockfree mpmc растовцы еще не доросли. Короче, это false cache sharing, но сейчас разнесение по кэш-линиями даст эффект только в очень специфичных сценариях.
У гугла 51 физический кубит в схеме "квантового отжига", что соотносится с универсальным квантовым вычислителем (пожалуй) как изобретение арабских цифр с созданием калькулятора.
Схемы коррекции требуют не просто много кубитов, а много сильно связанных кубитов. Разница как между мешком детекторых приемников и ядром Intel386.
Чтобы "взломать" SHA256 "грубой квантовой силой" (алгоритмом Гровера) нужно не менее 256 кубитов чтобы просто задать входные данные и считать результат (на самом деле больше, но уже не важно) и 2^127 шагов алгоритма (Солнце погаснет раньше).
Короче, при случае спросите у доцента где он грибы собирает и что при этом курит.
Первое (Quantum annealing) имеет успешные практические реализации и перспективы роста в кратко- и средне-срочной перспективе, но полностью безопасно для современной до-квантовой криптографии и (тем более) пост-квантовой. В частности, к этой категории относится 51-кубитный "квантовый компьютер" построенный D-Wave для Google.
Второе (Quantum computing) имеет призрачные шансы на воплощение на ценном для практического применения уровне. Дело тут не только в количестве кубит, а в их связности и количество операций (шагов алгоритма), которые могут быть выполнены. Практическую ценность представляет "квантовый компьютер" с большим (>100) количеством кубит, с высокой связностью (в идеале непосредственное соединение каждого с каждым) и способный выполнить большое (>100) шагов алгоритма. Грубо говоря, произведение кол-ва связей на кол-во шагов и есть полезная вычислительная мощность квантового компьютера.
Проблема в том, что (даже если будут преодолена масса огромных технических сложностей по поддержанию 100 кубит и "соединения" их плотной сетью связей) при работе в нашей (а не отдельной) вселенной каждое "квантовое соединение" на каждом шаге алгоритма будет глючить с некоторой ненулевой вероятностью. Соответственно, вероятность получить правильный ответ от "компа" с M связями за N шагов равна Power(P, M * N), где P — вероятность правильного "срабатывания отдельной связи". Так вот, в свете современных познаний о природе вещей (квантовая механика) и математике (теория алгоритмом и теоретическая информатика), N и M обещают быть большими (>1000), а P маленькой (< 0.9). Проще говоря, вероятность получить верный ответ сопоставима с его угадыванием через генератор случайных чисел.
Поэтом IMHO нас "спасут" не квантовые вычисления, а только новые алгоритмы нацеленные на взлом конкретных схем, т.е. на эксплуатацию отдельных недочетов (а тут у SHA256 пока всё хорошо).
Поситы — это чтобы меньше потерять при сохранении некого float-результата в меньшем кол-ве бит.
В сравнении с 754 поситы теряют они действительно меньше, но иначе.
При неправильном использовании, ни 754, ни поситы не спасут.
Однако, при правильном использовании поситы позволяют потерять меньше.
А статья дурная, начиная с заголовка.
Интерферометр тоже за уши притянут — при их объемах и бюджете можно ASIC-и использовать для delta-кодирования и т.п.
Заголовок статьи совсем не совпадает со смыслом.
Никакого "избавления" нет, только альтернативное представление для хранения, которое лучше в одних случаях и хуже в других.
А кто-нибудь может прояснить логичекую цепочку, следуя которой
if constexpr(false)ограничили до "during the instantiation of an enclosing templated entity" при инсталляции substatement?Т.е. что помешало сделать поведение
if constexprболее регулярным и удобным (как мне представляется)?Насчет "FreeBSD лучше Linux на multicore" — это давно устаревшая информация, очень давно. Кто-то даже может резонно спорить что это "совсем не правда и быть не может", но я просто помню что когда-то это было именно так.
Но "эпоха" закончилось где-то перед Linux 2.6.32. Хотя еще можно найти бенчмарки, в которых какой-то софт быстрее работает во FreeBSD (как правило из-за того, что делает что-то не правильно в Linux и/или не использует splice/sendfile т.д.). Еще есть бенчмарки (сомнительные, если разобраться), в которых FreeBSD внезапно в 2 раза быстрее (а в Linux при этом забывают выключить THP, SELinux и т.п.).
FreeBSD — хорошая система, но в Linux огромный объем превосходного кода. Тот случай, когда лучшее не враг хорошего, а просто превзошло его.
"Толсто намекаю" но не только на AVX/AVX2, а в том числе на SSE2 (пример), ибо доступно на всех 64-битных x86 и дает ~4-х кратное ускорение в сравнении с 7-ю инструкциями (насколько помню, код в примере быстрее "просто сканирования" в ~10 раз).
Понял, спасибо за ответ. Посредством
git grepполучил остальные ответы.Антон, у меня off-topic вопрос. Меня попросили оценить возможность и трудоемкость поддержки Embox в libmdbx, но я не смог быстро найти информацию что именно и из какой версии POSIX у вас поддерживается.
Можете по-быстрому подсказать что есть в наличии из списка: fork, mmap(MAP_SHARED), mutex(PTHREAD_PROCESS_SHARED), msync(MS_ASYNC/MS_ASYNC), fdatasync(), fcntl(F_OFD_SETLK или F_SETLK)? Как вариант — просто покажите список символов из libc, librt/libpthread.
Никак, кроме как попросить посадить вас на медленные HDD и мониторить latency ;)
Проще и сложнее одновременно:
Не надо такие статьи писать, это сильно мешает естественному отбору (а он — мудрый)!
;)
Действительно так.
Гугл и DWare так много говорили о своем "отжиге", а потом о 51-кубитном симуляторе, что я перестал следить за новостями от них.
Более того, я (пока еще) не до конца верю в их 51-кубитный вычислитель. Логично предположить что они сделали аналогичный по-параметрам симулятор именно для верификации реального вычислителя. Но возникает глупое сомнение — может они и считали на симуляторе ;)
Можно верифицировать решение, в том числе переформулируя задачу (т.е. получая другой ландшафт вероятностей для локальных минимумов). С некоторой вероятностью это будет давать решение некоторой точности… Тем не менее, IMHO это видится более "перспективным" в сравнении с "универсальным вычислителем" (хайп похож на распил бюджетов на пост-квантовую криптографию).
Если смотреть на
struct Queue, то два первых атомика будут в одной кеш-линии, которую продьюсер и консьюмер будут отбирать друг у друга. Хотя вероятно в реальном коде не так, но в 1Hippeus очереди всё равно были быстрее ;)Там же классический циклический буфер фиксированного размера. До mostly-lockfree mpmc растовцы еще не доросли. Короче, это false cache sharing, но сейчас разнесение по кэш-линиями даст эффект только в очень специфичных сценариях.
Угу, испанский стыд за покусанный кактус.
Усугублю:
Короче, при случае спросите у доцента где он грибы собирает и что при этом курит.
Думаю даже в такой популярной статье стоит различать (и давать понимание читателям) квантовый отжиг и универсальный квантовый компьютер.
Первое (Quantum annealing) имеет успешные практические реализации и перспективы роста в кратко- и средне-срочной перспективе, но полностью безопасно для современной до-квантовой криптографии и (тем более) пост-квантовой. В частности, к этой категории относится 51-кубитный "квантовый компьютер" построенный D-Wave для Google.
Второе (Quantum computing) имеет призрачные шансы на воплощение на ценном для практического применения уровне. Дело тут не только в количестве кубит, а в их связности и количество операций (шагов алгоритма), которые могут быть выполнены. Практическую ценность представляет "квантовый компьютер" с большим (>100) количеством кубит, с высокой связностью (в идеале непосредственное соединение каждого с каждым) и способный выполнить большое (>100) шагов алгоритма. Грубо говоря, произведение кол-ва связей на кол-во шагов и есть полезная вычислительная мощность квантового компьютера.
Проблема в том, что (даже если будут преодолена масса огромных технических сложностей по поддержанию 100 кубит и "соединения" их плотной сетью связей) при работе в нашей (а не отдельной) вселенной каждое "квантовое соединение" на каждом шаге алгоритма будет глючить с некоторой ненулевой вероятностью. Соответственно, вероятность получить правильный ответ от "компа" с
Mсвязями заNшагов равнаPower(P, M * N), гдеP— вероятность правильного "срабатывания отдельной связи". Так вот, в свете современных познаний о природе вещей (квантовая механика) и математике (теория алгоритмом и теоретическая информатика),NиMобещают быть большими (>1000), аPмаленькой (< 0.9). Проще говоря, вероятность получить верный ответ сопоставима с его угадыванием через генератор случайных чисел.Поэтом IMHO нас "спасут" не квантовые вычисления, а только новые алгоритмы нацеленные на взлом конкретных схем, т.е. на эксплуатацию отдельных недочетов (а тут у SHA256 пока всё хорошо).
Ерундовая статья.
Сходите к Косте Осипову, если писать не о чем.
Всё верно, но...
Поситы — это чтобы меньше потерять при сохранении некого float-результата в меньшем кол-ве бит.
В сравнении с 754 поситы теряют они действительно меньше, но иначе.
При неправильном использовании, ни 754, ни поситы не спасут.
Однако, при правильном использовании поситы позволяют потерять меньше.
А статья дурная, начиная с заголовка.
Интерферометр тоже за уши притянут — при их объемах и бюджете можно ASIC-и использовать для delta-кодирования и т.п.
Заголовок статьи совсем не совпадает со смыслом.
Никакого "избавления" нет, только альтернативное представление для хранения, которое лучше в одних случаях и хуже в других.