Mergiraf — новый движок разрешения конфликтов в коде

Это я на одноплатнике запускал. Первый тест – gcc -O3 на коде:

#include <stdio.h>

int main () {

double numf = 42.42;

for (int i = 0; i < 1000000; ++i){

  printf ("%2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f

%2.2f %2.2f %2.2f %2.2f %2.2f %2.2f\n",

          numf, numf, numf, numf, numf, numf, numf,

           numf, numf, numf, numf, numf, numf, numf);

}

}

Второй тест – zig build-exe main.zig -O ReleaseFast на коде:

const std = @import("std");

pub fn main() !void {
    const numf: f64 = 42.42;

    var stdout_buffer: [1024]u8 = undefined;
    var stdout_writer = std.fs.File.stdout().writer(&stdout_buffer);
    const stdout = &stdout_writer.interface;


    for (0..1_000_000) |_| {
        _ = try stdout.print(
            "{0:.2} {1:.2} {2:.2} {3:.2} {4:.2} {5:.2} {6:.2} {7:.2} {8:.2} {9:.2} {10:.2} {11:.2} {12:.2} {13:.2}\n",
            .{ numf, numf, numf, numf, numf, numf, numf, numf, numf, numf, numf, numf, numf, numf }
        );
    }

    try stdout.flush(); // Don't forget to flush!
}

Давай еще раз продублирую результат:

$ hyperfine ./testc
Benchmark 1: ./testc
  Time (mean ± σ):     12.305 s ±  0.034 s    [User: 12.288 s, System: 0.015 s]
  Range (min … max):   12.254 s … 12.345 s    10 runs

$ hyperfine ./testzig
Benchmark 1: ./testzig
  Time (mean ± σ):      4.250 s ±  0.004 s    [User: 4.237 s, System: 0.012 s]
  Range (min … max):    4.243 s …  4.256 s    10 runs

Я не спорю что это можно сделать и и не спорю что это не так уж и сложно, НО в чем причина не использовать механизм, который позволит в compile time находить ошибку, в то время как с виртуальной таблицей на сях вы только в рантайме отловите ошибку.

Как я описал пишут и проблем не имеют с рантаймом, если удобно, то можете ссылки на функции можете в структуре разместить, а можете вообще не использовать данный механизм. А что касается плюсов Спп, то они не перекрывают его минусов для меня, т.к. если на нем писать какой-то эффективный код с точки зрения работы железа, то приходим к синтаксису Си, только вот компилятор можно найти не для всего, либо еще какие фокусы происходят похоже в связи с количеством абстракций в языке…

Вот тут я поинтересуюсь потому что не уверен. А как runtime виртуальная таблица может быть быстрее (мы же говорим про скорость исполнения) чем compile time dispatching на концептах и темплейтах? Выше вам уже писали пример кода для класса Pin на плюсах. Виртуальная таблица с указателями это же и pointer inderection и inderect jump, а в случае использовании темплейтов нужная реализация «вставится» в код при компиляции.

ну так не надо просто сравнивать несравниваемое: пользуйтесь макросами и переход по ссылке явно не должен уступать в производительности и потреблении ресурсов работе с объектом (притом разница запросто может быть «на порядок»)

Нет. Новыми компиляторами это не собирается.

4.2
Новые компиляторы всё ещё поддерживают указание стандарта для сборки старого кода, пример выше прекрасно собирается gcc-15 -std=c89

Это я на одноплатнике запускал

Я получил те же результаты, только zig из снапа юзал

gcc:

$ time ./a.out > /dev/null

real 0m1,126s

user 0m1,119s

sys 0m0,004s

zig:

$ time ./2 > /dev/null

real 0m0,365s

user 0m0,363s

sys 0m0,000s

Но к сожалению, тут комментировать мне что-то тяжело, т.к. я язык zig не очень представляю себе, тут могут быть глубокие очень оптимизации и надо бы просто на массивах данных попроверять, может тут дело именно в способе вывода информации…

Я сегодня будет время попробую поразбираться - это интересно как минимум…

Так на c++ под embedded надо правильно писать. Конечно если ты туда притащишь STL или напишешь свой STL - будет всё очень плохо. Потому пишем классы и темплейты аккуратно, без лишних аллокаций и виртуальных функций и собираем с -fno-rtti -fno-exceptions -fno-threadsafe-statics, в этом случае даже рантайм вроде supc++ не понадобится

Так погоди. Ты тут утверждал, что стандарты обратно совместимы. Никто не спорил, что можно компилировать старым стандартом. Ещё можно просто старую версию компилятора взять. Но так не интересно.

Уймись, фантазер, тебе сказано поддержка старых стандартов, на примере gcc даже с23 и педантик показано, ты вперся в clang и опять придумываешь небылицы (что я сказал - это явно не то что ты услышал, у тебя там тараканы хороводы водят походу…)

100%! И знаю как volatile пользоваться. А ты – нет.

ну расскажи тогда, чтоб люди хоть оценили, а то «знаю-знаю», а на проверку - фантазии одни…

gcc точно почти полностью на Си написан и фронт на Ада вроде, а остальное все вкусовщина и дектуется реальностью…

4.2
начиная приблизительно с 4.x с++ фронтенд там точно написан на c++, что вызывает определённую попоболь при бустрапе gcc

И потом его под aarch64 или riscv не могут запустить без тормозного транслятора...

Так на c++ под embedded надо правильно писать. Конечно если ты туда притащишь STL или напишешь свой STL - будет всё очень плохо. Потому пишем классы и темплейты аккуратно, без лишних аллокаций и виртуальных функций и собираем с -fno-rtti -fno-exceptions -fno-threadsafe-statics, в этом случае даже рантайм вроде supc++ не понадобится

Вот я примерно про это и сообразил в свое время и подумалось мне что «это излишние проблемы», плюсов от которых меньше, чем минусов (некая гибкость в подходах к железкам может пострадать к тому же).

Отключение рантаймозависимых фич это проблема? Я вот даже в не-embedded коде их отключаю, потому что если этими фичами не пользоваться, то это просто буллшит, убивающий оптимизации и раздувающий код.

Отключение рантаймозависимых фич это проблема? Я вот даже в не-embedded коде их отключаю, потому что если этими фичами не пользоваться, то это просто буллшит, убивающий оптимизации и раздувающий код.

Не совсем в этом я проблемы углядел, все таки С++ это давно не С с классами и он оброс уже абстракциями и своей внутренней кухней, которая к слову не на 100% совместима с Си, туда добавилась история что я могу взять железку на которую не будет плюсового компилятора или он будет кривовато работать, суммировал все и не захотел, по крайней мере до поры до времени, использовать Спп для железок. Кстати, мне еще интервью попадалось какой-то белоруской компании, которая производила высоконагруженные железки реального времени и там примерно то же отношение к плюсам, только «главный» на магию в основном кивал)))

Но к сожалению, тут комментировать мне что-то тяжело, т.к. я язык zig не очень представляю себе

Кто-то из лорчан сказал, что комптайм в зиге — жалкое подобие макросов в CommonLisp. Через упоминание макросов я про этот бенчмарк вспомнил. Соответственно, в коде выражены две фишки: независимость от сишного рантайма, и что в комптайме print() распарсил форматирование.

И потом его под aarch64 или riscv не могут запустить без тормозного транслятора…

Конкретно под Apple Silicon работать будет быстро. Главное пожалеть людей и AVX2 у себя убрать.

Это я на одноплатнике запускал

А теперь смотри магию (если не перенаправлять в /dev/null):

gcc:

real 0m11,608s

user 0m2,301s

sys 0m7,291s

zig:

real 0m11,612s

user 0m0,402s

sys 0m1,106s

Одна производительность, где-то в выводе собака зарыта похоже…

Так вроде как фокус похоже получился, zig похоже весь вывод разом мне в /dev/null кидал, а Си выводил в /dev/null построчно, т.к. при выводе в stdout (на экран) скорость у них одинаковая, тут-то похоже и зарыта собака, а так прикольно выходит, красиво)))

А это точно хорошая идея мерить производительность на IO bound задаче? Может лучше интерполяцию посчитать, FFT или факториал? А то эта мериловка у кого printf быстрее… ну такое…

т.к. при выводе в stdout (на экран) скорость у них одинаковая

А эмулятор терминала у тебя kitty/ghostty? Эмулятор терминала сам по себе может тормозить с выводом.

Нет, там делали по принципу «как эту штуку сделать максимально непохожей на другие такие же штуки».

А эмулятор терминала у тебя kitty/ghostty? Эмулятор терминала сам по себе может тормозить с выводом.

я на wsl debian пробую на «чем-то»)))

Вот гном-терминал:

gcc:

real 0m7,886s

user 0m2,016s

sys 0m5,606s

zig:

real 0m2,093s

user 0m0,405s

sys 0m1,094s

gcc с небольшой оптимизацией (нужно бы на корректность проверить)) ):

real 0m2,360s

user 0m1,161s

sys 0m0,667s

Но это не честно, ты пушишь за раз весь файл в стдаут)))

PS небольшая оптимизация:

#include <stdio.h>

#include <stdlib.h>

int main () {

char * c = (char *) malloc(6 * 14 * 1000000);

double numf = 42.42;

for (int i = 0; i < 1000000; ++i){

sprintf (c + i * 6*14,«%2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f %2.2f\n»,

      numf, numf, numf, numf, numf, numf, numf,

       numf, numf, numf, numf, numf, numf, numf);

}

fprintf(stdout,«%s»,c);

return 0;

}

Но добиться, чтоб в /dev/null с той же скоростью писало, пока не вышло)))

Типичный растохейтер не способен написать программу из 10 строчек на си, не накосячив в работе с памятью.

Типичный растохейтер не способен написать программу из 10 строчек на си, не накосячив в работе с памятью.

Где ошибочка, не подскажешь..? Или не знаешь просто..? Или ее нет просто..?

Подскажу, конечно. Запись и чтение за пределами аллоцированной области памяти.

То есть в обоих случаях, что софт обосрался и насрал память, что софт просрал тайминг - его задача считается не выполненной

Есть принципиальная разница: один случай надежно детектируется с принятием соответствующих мер, а другой в общем случае нет. Робот уже крушит завод, а софт считает что всё работает штатно.

Подскажу, конечно. Запись и чтение за пределами аллоцированной области памяти.

А вот ты и попался, там этой ошибки нет, ибо ты просто не умеешь в Си…

Окей, допустим, я ошибаюсь. Давай скормим твою программу валграйнду:

==1676934== Invalid write of size 1
==1676934==    at 0x490E98E: __vsprintf_internal (iovsprintf.c:97)
==1676934==    by 0x48ED927: sprintf (sprintf.c:30)
==1676934==    by 0x10923C: main (in a.out)
==1676934==  Address 0x9ad4d40 is 0 bytes after a block of size 84,000,000 alloc'd
==1676934==    at 0x4848839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1676934==    by 0x10919E: main (in a.out)
==1676934== 
==1676934== Invalid read of size 1
==1676934==    at 0x4851204: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1676934==    by 0x490CA18: fputs (iofputs.c:33)
==1676934==    by 0x109267: main (in a.out)
==1676934==  Address 0x9ad4d40 is 0 bytes after a block of size 84,000,000 alloc'd
==1676934==    at 0x4848839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1676934==    by 0x10919E: main (in a.out)

Итого я и валграйнд против тебя. Твой ход, докажи, что мы оба ошибаемся.

Окей, допустим, я ошибаюсь. Давай скормим твою программу валграйнду:

ты мне в коде покажи где я вылез за адрес 84 000 000, а там такого нет ибо твой валграйнд не понятно откуда это берет (что это за зверь такой), хочешь конечно ему верь, но в коде нет чтения за границей аллоцированного в куче…

Да и при попытке пописать рандомно из памяти и в память зачастую вылезают наружу.

Он может просто недоволен что я free не сделал…? В конце концов, у тебя код есть и инструмент есть, найди ошибку про которую заявил…

Тебе же написано, sprintf пишет один байт за пределами аллоцированного, fprintf читает один байт за пределами. Если ты не так и не понял, о чём речь - ты забыл про память для символа окончания строки.

Отсутствие free - мелочь, но инструмент и это ловит, любой может убедиться, запустив valgrind самостоятельно.

тебе сказано поддержка старых стандартов, на примере gcc даже с23 и педантик показано

Ага. Это ошибка/фича GCC. Ты всё ещё не понимаешь, что программа может быть некорректной даже если она компилируется.

Но можешь начать с википедии:

Remove K&R function definitions/declarations (with no information about the function arguments)

https://en.wikipedia.org/wiki/C23_(C_standard_revision)

ну расскажи тогда, чтоб люди хоть оценили, а то «знаю-знаю», а на проверку - фантазии одни…

Ты хочешь, чтобы я тебе цитату из стандарта пересказал? Ну так я её выше прикладывал. Можешь перечитать ещё раз.

Тебе же написано, sprintf пишет один байт за пределами аллоцированного, fprintf читает один байт за пределами. Если ты не так и не понял, о чём речь - ты забыл про память для символа окончания строки.

Что инструмент пишет я вижу, только там проблем нет и последний символ выводится без проблем (\n сложно не заметить)…

Отсутствие free - мелочь, но инструмент и это ловит, любой может убедиться, запустив valgrind самостоятельно.

вот и получается скорее всего что он поймал отсутствие фрии, который особого смысла не имеет т.к. ретурн 0 далее…

Ну да, в случае каких-то странных тулчейнов и реализаций имеет смысл избегать c++.
Я, например, видел реализации, которые не инициализировали глобальную память, c++ в этом случае мог бы поломаться.
Но в этих случаях лучше чинить тулчейн, чем менять язык из-за того, что он сломан

Это касается обоих случаев

А как же нуль-терминатор?

Ага. Это ошибка/фича GCC. Ты всё ещё не понимаешь, что программа может быть некорректной даже если она компилируется.

какая разница, даже если gcc чуть вольно к стандарту относится (и я тебе об этом, кстати, написал, что с23 странно что со всеми флагами компилится), что тебе мешает использовать соответствующий стандарту флаг?

Но можешь начать с википедии: Ты хочешь, чтобы я тебе цитату из стандарта пересказал? Ну так я её выше прикладывал. Можешь перечитать ещё раз.

Я с этим не спорил ни разу, опять где-то у тебя мысли не сошлись, т.к. я утверждал, что ты можешь прям сегодня на современном кампилляторе (если угодно) скомпилировать этот код.

Внимательно читай, вникай в разговор, не надо слова дергать и додумывать… Я последний раз так с ИИ переписывался, но он хоть признает что по задаче сел в лужу, правда дальше у него включается генератор отмазок, который должен оправдать его фантазии и что «Солнце его ослепило»…

А как же нуль-терминатор?

А я хитрый и его не передаю, поэтому у меня большааааая строка обрывается просто отступом строки))))

sprintf сам, на сколько помню, не добавляет /0 или добавляет, тут бы глянуть, тогда тут и порылась собака, тогда:

char * c = (char *) malloc(6 * 14 * 1000000 + 1);

Но это минорная история все равно ибо на скорую руку писал, поэтому не проверил поведение sprintf, а сразу не проявилась беда))))

Короче, не влияет на тест точно эта история (минорная история)

real 0m2,328s

user 0m1,144s

sys 0m0,648s

Что-то мешает распознать нарушение тайминга?

то, что в этот момент тайминг нарушается и распознано оно сможет быть в лучшем случае, когда уже будет поздно. Для ситуации с роботом. который уже рушит завод оба варианта неприемлимы, так что нужен не только безопасный язык, но и предсказуемый по времени. И runtime проверки адресов/индексов - вполне нормально, при условии что они происходят за предсказуемое время, так что всякие языки с gc тут в пролёте, а пригоден ли rust - тоже большой вопрос.
Здесь скорее важен даже не язык, а сам способ разработки ПО, Сначала нужно разработать требования, потом написать программу и доказать, что требованиям она соответствует. В случае языков с gc на последнем этапе проблема т.к сложно предсказать время исполнения, которое должно всегда не превышать какое-то значение из требования, а не лишь в большей части случаев

даже если gcc чуть вольно к стандарту относится (и я тебе об этом, кстати, написал, что с23 странно что со всеми флагами компилится), что тебе мешает использовать соответствующий стандарту флаг?

Банальный пример: есть старый проект, хочется в нём использовать фичи последних стандартов. Например, #embed. Как ни крути, придётся переписывать код.

Но можешь начать с википедии: Ты хочешь, чтобы я тебе цитату из стандарта пересказал? Ну так я её выше прикладывал. Можешь перечитать ещё раз.

Я с этим не спорил ни разу, опять где-то у тебя мысли не сошлись, т.к. я утверждал, что ты можешь прям сегодня на современном кампилляторе (если угодно) скомпилировать этот код.

Это про volatile было. Про который ты сам писал, что это вкусовщина, и что расстановку volatile ты делаешь «методом тыка».

Банальный пример: есть старый проект, хочется в нём использовать фичи последних стандартов. Например, #embed. Как ни крути, придётся переписывать код.

Опять фантазия, я сказал про компиляцию, а доработки - дело совсем другое, но вон gcc как оказалось может и это позволить (про что ты написал)

Это про volatile было. Про который ты сам писал, что это вкусовщина, и что расстановку volatile ты делаешь «методом тыка».

Фантазии опять, не говорил я про «метод тыка», я лишь писал, что проблема при глубоких степенях оптимизации встречается, и что изначально ты можешь предположить места проблемные, но вот надо ли там волатайл ты поймешь только после сборки, но никто тебе не мешает расставить волатайлы в подозрительные места и потерять, собственно, в степени оптимизации при компиляции из-за этого…

изначально ты можешь предположить места проблемные, но вот надо ли там волатайл ты поймешь только после сборки

Только если ты программировать не умеешь. Потому что случаи, где необходим volatile, вполне доступно описаны.

Фантазии опять, не говорил я про «метод тыка»,

Да, ты написал ещё хуже:

Это чистая вкусовщина, да и ты мне в коде не покажешь где точно нужен volatile, а где нет, ты его скорее всего поставишь по причине «сомнительное место», т.к. еще раз говорю, что бывает и без волатайла похожие вещи работают, а некорректность программы тут не при чем, иначе бы об этом был ворнинг от компилятора, компилятор молчит, значит программа корректна…

то, что в этот момент тайминг нарушается и распознано оно сможет быть в лучшем случае, когда уже будет поздно

Ну да. Допустим, секунду отработали в порченном состоянии, пока заметили. А порчу памяти когда заметим? Когда угодно, вполоть до никогда. Масштабы потерь несравнимые.

Потом, последствия сбитых таймингов - лишь подмножество последствий битой памяти. Второе вообще непредсказуемо.

за предсказуемое время, так что всякие языки с gc тут в пролёте

Говорят, есть детерминированные gc.

Только если ты программировать не умеешь. Потому что случаи, где необходим volatile, вполне доступно описаны.

Ты тут личным примером доказал что по русски то прочитать и понять ничего не можешь и начинаешь фантазировать на ровном месте, что ты мне про доступно написано пишешь-то?

Покажи код, расставь волатайлы, опиши словами причины расставления и попробуем его с разными оптимизациями, проверим твое «умею»/«доступно»/«знаю», а до этого не фантазируй, это глупо…

Да, ты написал ещё хуже:

Где это не бьется с тем, что я после утверждал? Где оно хуже твоего «метода тыка»? Акстись, ты в параллельной реальности живешь, где все происходит так как тебе хочется…? Это уже грустное зрелище, уймись, не все семи пядей во лбу, люди ошибаются, а с бараньим настроем ничего хорошего в голове не появится…

PS все просто: есть твои мысли, а есть реальность, соединяются они при практическом применении знаний к реальности… И не будет у тебя тогда в голове дурных мыслей: типа тебе гцц что-то должен, а он делает чуть иначе и остального бреда… Может вникать в написанное научишься, т.к. под буквами, словами и предложениями скрыты понятия, процессы, контексты и т.д.

При условии что эти gc уложатся в требования

А на зиге аналог получится?

А на зиге аналог получится?

Не знаю, что понимается под аналогом. Когда я последний раз проверял, AVR-бэкенд зига был в зачаточном состоянии.

А там, где бэкенд есть, там можно устроить веселье.

В смысле шаблонный статический диспатч, чисто язык, как это выглядеть будет, на каком железе не важно

В смысле шаблонный статический диспатч, чисто язык, как это выглядеть будет

В комптайме язык и конструкции используются те же, просто типы становятся на место переменных.

pub fn MyPin(comptime R: u8, comptime B: u8) type {
    return struct {
        fn reg(offset: i32) *volatile u8 { ... } // helper

        pub fn dirIn() void {
            reg(-1).* &= ~BIT_MASK;
        }

        pub fn dirOut() void {
            reg(-1).* |= BIT_MASK;
        }

        pub fn get() bool {
            return (reg(0).* & BIT_MASK) != 0;
        }

        pub fn set() void {
            reg(0).* |= BIT_MASK;
        }
    };
}
...
	const MyPinB0 = MyPin(PORTB_ID, PORTB0);
	const MyPinB1 = MyPin(PORTB_ID, PORTB1);
	const MyPinB2 = MyPin(PORTB_ID, PORTB2);
	const MyPinB3 = MyPin(PORTB_ID, PORTB3);
...
	const Buzzer = BuzzerImpl(MyPinD3);
	const SegmentG = MyPinB1;
	const CommonOne = MyPinC1;
...
	// real code:
	SegmentF.dirOut();
	SegmentG.dirOut();
		
	CommonOne.dirOut();
	CommonTwo.dirOut();

Ты тут личным примером доказал что по русски то прочитать и понять ничего не можешь

Я знал узбеков, китайцев и даже японца, у коих русский был на куда лучшем уровне, нежели применяемый тобой.

Покажи код, расставь волатайлы, опиши словами причины расставления и попробуем его с разными оптимизациями, проверим твое «умею»/«доступно»/«знаю», а до этого не фантазируй, это глупо…

lol

lmao even

Примеры правильного использования volatile можешь посмотреть хотя бы на cppreference.net, либо в учебнике по языку.

Где это не бьется с тем, что я после утверждал?

Больше всего мне понравилось в том комменте последнее утверждение:

некорректность программы тут не при чем, иначе бы об этом был ворнинг от компилятора, компилятор молчит, значит программа корректна…

Что означает, что в твоём мире если программа скомпилировалась, значит она корректна. У меня в универе на первом курсе одна девочка так же считала и втыкала тупыми глазами на препода, когда тот её спрашивал, херли её код полную хню делает.

Ааа! Прекрасно! По классике фриков между двумя утверждениями логических связок ровно 0. Опровергатели Эейнштейна аппрувед.

Внутренние противоречия прикладывются. Как то:

Rust community is a dangerous sect

далее по тексту:

For a group not to become a fetish, it is crucial not to give it a name

Господи, ну приведи ты к общей аксиоматике. Что за детский сад?!

Я знал узбеков, китайцев и даже японца, у коих русский был на куда лучшем уровне, нежели применяемый тобой.

Ты б и дальше русский изучал бы у узбеков, китайцев и японцев, а к носителям языка не лезь, косноязычный люмпен…

lol

lmao even

Примеры правильного использования volatile можешь посмотреть хотя бы на cppreference.net, либо в учебнике по языку.

Т.е. конкретно ты не можешь подтвердить свою точку зрения, балабол…

Что означает, что в твоём мире если программа скомпилировалась, значит она корректна. У меня в универе на первом курсе одна девочка так же считала и втыкала тупыми глазами на препода, когда тот её спрашивал, херли её код полную хню делает.

Ты опять нафантазировал, алеша, тебе ж потом пояснили, что имелась ввиду корректность в терминах языка, а вот диссонанс в некорректности «работы» программы как раз был предметом обсуждения… Я (как ты это постоянно делаешь) не утверждал, что оно Должно работать/не работать, это просто интересный факт и пример тонкостей языка, но видно в твоем случае той «девочкой» был ты и затаил боль и обиду… «Баран он и в Африке баран, алеша».

То-то в ffmpeg удивятся, что асмом нельзя пользоваться.