Кобол способен читать данные из БД (которые там лежат в виде набора байтов на жёстком диске) в 5 переменных в разных местах оперативной памяти одной командой без промежуточного байтового буфера?
даже на C можно сделать рудиментарную но очень быструю "базу данных", если писать/читать структуры прямо в файл. И никаких промежуточных байтовых буферов не надо. Только на C это будет непереносимо и вообще фу-фу-фу, но возможно КОБОЛ дает большое гарантий относительно размещений полей в структурах, там что там это будет вполне рабочим вариантом.
Ну многое из этого билдбот поддерживает. Это ж все-таки CI, а не обертка над скриптом build.sh.
Вообще, у меня есть два протировечивых требования к CI: хочется иметь декларативное описание билдов и хочется иметь возможность создавать очень гибкие билды, ибо у нас тут embedded со своими приколами.
Практически никто из них не использует в коде ассемблерные вставки для обращения к MMIO.
Ну тут есть два нюанса. Во-первых, эти библиотеки для ядер типа Cortex M0-М3 где нет MMU и нет спекулятивного чтения/записи памяти, соответственно, надо бороться только з оптимизациями компилятора, что куда проще. Во-вторых - эти библиотеки непереносимые. Ни между архитектурами (что очевидно), ни между компиляторами.
существуют регистры в IO пространстве, и в этом случае уже должны быть использованы другие команды. Возможно использование ассемблерных вставок имеет свои корни из за этой особенности?
Ну с IO пространством - да, там без ассемблера не обойтись. Но ассемблерные вставки для memory mapped регистров все равно нужны в некоторых кейсах.
Например, рассмотрим архитектуру ARMv8-A, там есть MMU, память через MMU может быть замаплена в нескольких режимах. Для нас интересны два - это Normal Memory и Device Memory. Normal Memory - это обычная память, с ней можно работать как угодно, но она кешируемая и позволяет процессору делать спекулятивные обращения, что совершенно не подходит для memory mapped регистров, где даже чтение может иметь побочные эффекты. Поэтому есть режим Device Memory, где все наоборот - никаких кешей, никакого спекулятивного доступа. Но! Это не позволяет использовать, например, векторные инструкции для обращения к этой памяти. Банальная memcpy в линуксе роняет ядро, если пытаться копировать в/из device memory, потому что эта функция старается использовать самые быстрые инструкции для перемещения больших кусков памяти. Но эти инструкции нельзя применять для device memory.
Но компилятор же не знает что вот этот регион памяти - обычный, а вот этот - специальный. Компилятор волен использовать любые инструкции для работы c памятью, даже NEON, например. Компилятор может векторизировать код, перемещать местами два чтения из памяти, перемешивать чтения и запись если не видит между ними зависимостей, пропускать чтение, если видит что результат нигде не используется, пропускать запись, если видит что записали тоже самое что и прочитали и так далее. И volatile тут не спасет, потому что у volatile чуть другие гарантии, которые не покрывают все случаи описанные выше.
И кстати, компилятор ничего не знает про многопоточность, что тоже может приводить к веселым приколам, когда мы работаем с шареной памятью. Поэтому в линуксе есть хитрые макросы типа READ_ONCE чтобы гарантировать что чтение из обычного шареного буфера происходило именно в нужный момент и ровно один раз.
Я не уверен что "пропихнули" это верное слово. Вряд-ли Поттеринг кружил над мейнтейнерами Дебиана и заставлял их взять systemd. Это было их решение. Да и по факту, systemd сильно фичастее и удобнее System V init.
Ну точно так же. Он совершенно так же показывает конфликт в файле, даже синтаксис почти тот самый. Только вместо filename в первой строчке он указывает на ревизию с другой стороны. Например: https://wincent.com/wiki/Understanding_Git_conflict_markers
Единственное, что не надо ходить по ошибкам компиляции (хотя можно, если хочется), достаточно сделать git diff, он покажет неразрешенные конфликты.
Эхех, помню про прекрасную багу то ли в gnu libc то ли в bionic, которая вылезла потому что на big и LITTLE ядрах в каком-то квалкоме была разная длина кеш-лини... Либа один раз при старте определяла длину кеш-линии и запоминала где-то. Соответственно, в некоторых случаях при попытке инвалидации или очистки кеша, инвалидировалась/чистилась только половина всего.
Так а чем это поможет в ситуации "Вася вечером залочил половину репозитория и ушел домой, а на следующий день не пришел, потому что заболел"? Ну или просто, вот есть файл в репозитории, я делаю патч на одну функцию в этом файле, коллега - на другую. Почему мы не можем делать это одновременно?
А что, SVN магическим образом умеет решать конфликты? То что можно помержить автоматически, то рибейз и помержит. А если есть конфликтующие изменения, то их надо разрешать руками, что в гите, что в SVN, что при git rebase что при git pull или git merge
Кстати, не знаю как в винде, а в линуксе есть energy aware scheduling. Т.е. планировщик буквально раскидывает потоки по ядрам так, чтобы в сумме было потреблено как можно энергии:
Ну планировщик же видит насколько поток нагружает процессор. Например, мы видим что утилизация Е-ядра потоком доходит до 100%, значит пора перебросить его на P-ядро.
Ну да, я так и написал:
даже на C можно сделать рудиментарную но очень быструю "базу данных", если писать/читать структуры прямо в файл. И никаких промежуточных байтовых буферов не надо. Только на C это будет непереносимо и вообще фу-фу-фу, но возможно КОБОЛ дает большое гарантий относительно размещений полей в структурах, там что там это будет вполне рабочим вариантом.
А что значит конструкция EVALUATE TRUE ALSO TRUE с КДПВ? Очень уж забавно звучит.
Ну многое из этого билдбот поддерживает. Это ж все-таки CI, а не обертка над скриптом build.sh.
Вообще, у меня есть два протировечивых требования к CI: хочется иметь декларативное описание билдов и хочется иметь возможность создавать очень гибкие билды, ибо у нас тут embedded со своими приколами.
Для мелких проектов мне прекрасно зашел buildbot. Там конфиг - это тупо скрипт на пайтоне. Можно делать все что угодно.
Ну тут есть два нюанса. Во-первых, эти библиотеки для ядер типа Cortex M0-М3 где нет MMU и нет спекулятивного чтения/записи памяти, соответственно, надо бороться только з оптимизациями компилятора, что куда проще. Во-вторых - эти библиотеки непереносимые. Ни между архитектурами (что очевидно), ни между компиляторами.
Ну с IO пространством - да, там без ассемблера не обойтись. Но ассемблерные вставки для memory mapped регистров все равно нужны в некоторых кейсах.
Например, рассмотрим архитектуру ARMv8-A, там есть MMU, память через MMU может быть замаплена в нескольких режимах. Для нас интересны два - это Normal Memory и Device Memory. Normal Memory - это обычная память, с ней можно работать как угодно, но она кешируемая и позволяет процессору делать спекулятивные обращения, что совершенно не подходит для memory mapped регистров, где даже чтение может иметь побочные эффекты. Поэтому есть режим Device Memory, где все наоборот - никаких кешей, никакого спекулятивного доступа. Но! Это не позволяет использовать, например, векторные инструкции для обращения к этой памяти. Банальная
memcpyв линуксе роняет ядро, если пытаться копировать в/из device memory, потому что эта функция старается использовать самые быстрые инструкции для перемещения больших кусков памяти. Но эти инструкции нельзя применять для device memory.Но компилятор же не знает что вот этот регион памяти - обычный, а вот этот - специальный. Компилятор волен использовать любые инструкции для работы c памятью, даже NEON, например. Компилятор может векторизировать код, перемещать местами два чтения из памяти, перемешивать чтения и запись если не видит между ними зависимостей, пропускать чтение, если видит что результат нигде не используется, пропускать запись, если видит что записали тоже самое что и прочитали и так далее. И
volatileтут не спасет, потому что уvolatileчуть другие гарантии, которые не покрывают все случаи описанные выше.И кстати, компилятор ничего не знает про многопоточность, что тоже может приводить к веселым приколам, когда мы работаем с шареной памятью. Поэтому в линуксе есть хитрые макросы типа
READ_ONCEчтобы гарантировать что чтение из обычного шареного буфера происходило именно в нужный момент и ровно один раз.О да, если внимательно почитать мануал, то можно узнать о куче крутых фишек.
Я не уверен что "пропихнули" это верное слово. Вряд-ли Поттеринг кружил над мейнтейнерами Дебиана и заставлял их взять systemd. Это было их решение. Да и по факту, systemd сильно фичастее и удобнее System V init.
Так в Гноме ж был. GConf назывался. Точно тот же принцип. Но потом от него отказались.
Ну точно так же. Он совершенно так же показывает конфликт в файле, даже синтаксис почти тот самый. Только вместо filename в первой строчке он указывает на ревизию с другой стороны. Например: https://wincent.com/wiki/Understanding_Git_conflict_markers
Единственное, что не надо ходить по ошибкам компиляции (хотя можно, если хочется), достаточно сделать git diff, он покажет неразрешенные конфликты.
Эхех, помню про прекрасную багу то ли в gnu libc то ли в bionic, которая вылезла потому что на big и LITTLE ядрах в каком-то квалкоме была разная длина кеш-лини... Либа один раз при старте определяла длину кеш-линии и запоминала где-то. Соответственно, в некоторых случаях при попытке инвалидации или очистки кеша, инвалидировалась/чистилась только половина всего.
Так а чем это поможет в ситуации "Вася вечером залочил половину репозитория и ушел домой, а на следующий день не пришел, потому что заболел"? Ну или просто, вот есть файл в репозитории, я делаю патч на одну функцию в этом файле, коллега - на другую. Почему мы не можем делать это одновременно?
А что, SVN магическим образом умеет решать конфликты? То что можно помержить автоматически, то рибейз и помержит. А если есть конфликтующие изменения, то их надо разрешать руками, что в гите, что в SVN, что при git rebase что при git pull или git merge
Зависит от подхода. Я `git pull` вообще никогда не использую. Сначала `git fetch`, потом `git rebase`, будет похоже на то что вы описали.
(какого черта у Хабра опять сломалось форматирование кода?)
Кстати, не знаю как в винде, а в линуксе есть energy aware scheduling. Т.е. планировщик буквально раскидывает потоки по ядрам так, чтобы в сумме было потреблено как можно энергии:
https://docs.kernel.org/scheduler/sched-energy.html
А мужики то и не знают:
https://www.microchip.com/en-us/products/interface-and-connectivity/pcie-switches
Ну планировщик же видит насколько поток нагружает процессор. Например, мы видим что утилизация Е-ядра потоком доходит до 100%, значит пора перебросить его на P-ядро.
Может где-то на крутых производствах и не используют, но в мелких мастерских ими пользуются вовсю.
Хм, ни разу не встречал приложение, которое поддерживает конфиги больше чем на одном языке.
Можно пример?
Хоть так. Ну или дублировать информацию, как это уже делается лет 50 в EAN-13.