А Вы себя представьте в вялотекущей пробке на трассе, когда до ближайшего туалета километров 10, а желудок бурно реагирует на съеденную перед этим пищу.
Сейчас на M4 появились придорожные бесплатные туалеты, но посещение их требует немало мужества, ловкости и отсутствия брезгливости. Но на многих других трассах туалетов нет даже Московской области, не говоря уже о более дальних регионах.
И в какой столице можно проехать не 25, а всего километр, без возможности свернуть к торговому центру или фастфуду? А если встал совсем глухо, то машину можно и бросить на пять минут.
Не раз встречал в общественных туалетах фекалии чуть ли не на потолке. Что будет с беспилотным такси после подобных фонтанирований - мне даже страшно представить.
Иногда весьма удобно вместо кучи параметров сформировать и передать один JSON
Намного эффективней в качестве параметра массив композитного типа, особенно в бинарном потоке. Да и надежней, благодаря строгой типизации. При вызове хранимых процедур из микросервисов поступаю именно так. При больших объёмах, это по эффективности оказывается сопоставимым с COPY ... FROM STDIN BINARY во временную таблицу.
Несколько не честно упомянуть json[b]_array_elements, но не упомянуть json[b]_populate_recordset, который при продуктивном использовании с уже созданными композитными типами явно удобней.
Поэтому на C пишут ядра, драйверы, firmware, мало кто по доброй воле пишет прикладной код
Какая тут "добрая воля", если ABI почти всех операционных систем гвоздями прибито к C? Нужна динамически загружаемая библиотека в гетерогенной среде - извольте либо писать на C, либо ограничиваться только его ABI, как например в Rust или C++, через extern "С".
А так как ABI и API связаны, то почти все операционные системы ничего не знают про те же умные указатели и прочие инструменты безопасной работы с памятью.
Пока речь идет о разработке одного продукта, можно ограничиться одним языком программирования. Когда же речь идет о реальных потребностях, то приходится либо дублировать код, усложняя поддержку, либо переходить на взаимодействие через сериализацию и десериализацию, снижая производительность, либо возвращаться к C и его ABI.
В работе использовали короткие синтетические цепочки ДНК длиной всего 22 нуклеотида
А ниже
Теоретически один грамм ДНК способен хранить около 215 миллионов гигабайт информации
Как-то не складывается. Если память на мемристорах, диаметром 3.4 нм и высотой 4 нм, то при чём тут граммы и кодирование информации нуклеотидами в ДНК? Плотность получается явно меньше, чем в 3D NAND по 3 нм техпроцессу.
Ну конечно! И даже можете доказать, что на CPU общего назначения можно добиться латентности при реакции на внешнее событие в пределах десятка наносекунд, как, например, на таком SoC? )))
Так наоборот, на специализированном МК вполне можно достичь куда большей скорости, чем на CPU общего назначения. В данном случае наличие виртуальной памяти может только увеличить латентность, но уж никак не уменьшить.
А нет менеджера виртуальной памяти - нет и возможности неограниченного использования watchpoints, так как остаётся только весьма ограниченное количество аппаратных watchpoints. ЧТД.
Вы вообще меня удивляете. Неужели впервые слышите о том, что для систем реального времени, где низкая латентность критически важна, специализированные MK и SoC куда более предпочтительны, чем CPU общего назначения?
Именно поэтому в подобных местах повсеместно предпочитают MK и SoC (часто в виде ПЛК), вместо обычных компьютеров.
С FPGA — торгуют, с обычных x86_64 — торгуют
Ну так специализированные MK и SoC и есть золотая середина между FPGA и CPU общего назначения. Причём нисколько не исключают наличие FPGA в своём составе.
Ходят то ходят, но 15 тонн собачьих экскрементов на улицах Берлина откуда-то взялись?
А Вы себя представьте в вялотекущей пробке на трассе, когда до ближайшего туалета километров 10, а желудок бурно реагирует на съеденную перед этим пищу.
Сейчас на M4 появились придорожные бесплатные туалеты, но посещение их требует немало мужества, ловкости и отсутствия брезгливости. Но на многих других трассах туалетов нет даже Московской области, не говоря уже о более дальних регионах.
И в какой столице можно проехать не 25, а всего километр, без возможности свернуть к торговому центру или фастфуду? А если встал совсем глухо, то машину можно и бросить на пять минут.
Не раз встречал в общественных туалетах фекалии чуть ли не на потолке. Что будет с беспилотным такси после подобных фонтанирований - мне даже страшно представить.
Намного эффективней в качестве параметра массив композитного типа, особенно в бинарном потоке. Да и надежней, благодаря строгой типизации. При вызове хранимых процедур из микросервисов поступаю именно так. При больших объёмах, это по эффективности оказывается сопоставимым с COPY ... FROM STDIN BINARY во временную таблицу.
Несколько не честно упомянуть json[b]_array_elements, но не упомянуть json[b]_populate_recordset, который при продуктивном использовании с уже созданными композитными типами явно удобней.
Какая тут "добрая воля", если ABI почти всех операционных систем гвоздями прибито к C? Нужна динамически загружаемая библиотека в гетерогенной среде - извольте либо писать на C, либо ограничиваться только его ABI, как например в Rust или C++, через extern "С".
А так как ABI и API связаны, то почти все операционные системы ничего не знают про те же умные указатели и прочие инструменты безопасной работы с памятью.
Пока речь идет о разработке одного продукта, можно ограничиться одним языком программирования. Когда же речь идет о реальных потребностях, то приходится либо дублировать код, усложняя поддержку, либо переходить на взаимодействие через сериализацию и десериализацию, снижая производительность, либо возвращаться к C и его ABI.
У языков со сборщиком мусора и без него всё же несколько разные ниши. Некорректно их сравнивать.
А ниже
Как-то не складывается. Если память на мемристорах, диаметром 3.4 нм и высотой 4 нм, то при чём тут граммы и кодирование информации нуклеотидами в ДНК? Плотность получается явно меньше, чем в 3D NAND по 3 нм техпроцессу.
Чтобы Вы увидели цены на топовые SoC.
Потому что Вы не умеете читать больше одного предложения )))
"на любом CPU без аппаратной поддержки виртуальной памяти"
То, что выделено синеньким - это ссылка. Откройте и посмотрите на цену.
Потому что производительность подобных SoC определяется в первую очередь FPGA, а не CPU.
Вы ошиблись на три порядка. Такие SoC стоят десятки тысяч долларов.
Где это? Я изначально веду речь о MK и SoC, где CPU - лишь один из компонентов.
Не туда смотрите. Надо сюда.
CPU в таких случаях лишь программирует FPGA. Особой производительности от него тут не требуется.
При чем тут наносекунды процессора, если в данном случае речь о латентности FPGA Cyclone под управлением процессора?
Ага. Например, Siemens S7-1500 с TM FAST Modules, которые явно на FPGA.
Ну конечно! И даже можете доказать, что на CPU общего назначения можно добиться латентности при реакции на внешнее событие в пределах десятка наносекунд, как, например, на таком SoC? )))
https://ru.wikipedia.org/wiki/Апелляция_к_авторитету )))
Расскажите это технологам на производстве, где даже микросекунды играют роль )))
Впрочем, дискутировать с демагогом, вынужденным переходить на личности и оскорбления в технической дискуссии, смысла нет.
Так наоборот, на специализированном МК вполне можно достичь куда большей скорости, чем на CPU общего назначения. В данном случае наличие виртуальной памяти может только увеличить латентность, но уж никак не уменьшить.
А нет менеджера виртуальной памяти - нет и возможности неограниченного использования watchpoints, так как остаётся только весьма ограниченное количество аппаратных watchpoints. ЧТД.
Вы вообще меня удивляете. Неужели впервые слышите о том, что для систем реального времени, где низкая латентность критически важна, специализированные MK и SoC куда более предпочтительны, чем CPU общего назначения?
Именно поэтому в подобных местах повсеместно предпочитают MK и SoC (часто в виде ПЛК), вместо обычных компьютеров.
Ну так специализированные MK и SoC и есть золотая середина между FPGA и CPU общего назначения. Причём нисколько не исключают наличие FPGA в своём составе.