И компиляторы уже такие умные стали, что автоматически векторизуют всё, что можно векторизовать?
Ну у меня например, софтварный растеризатор треугольников на Си без интрисинков с опцией -O3 ~180мс на отрисовку сцены 8к полигонов в 4к (3840*2160) в 1поток на ноутбучном CPU, а с интрисинками (SSE4.2), оптимизацией размещения данных в структуре и выравниванием в памяти ~160мс. Пожалуй под неон забью на ручную векторизацию.
Может, оно вам и AoS в SoA само конвертирует?
А зачем? Я сразу пишу как надо.
У меня бывают проекты, где приходится писать свои аллокаторы, с аренами и вот этим всем.
В линуксовой libc аллокатор с аренами как раз. Если что, можно её статически линковать, не уверен правда, позволяет ли лицензия.
Благодарю за комплимент, очень приятно слышать, что я делаю невозможное. У меня сложность не в UI, он уже есть и работает на 2х платформах как минимум (Android + Linux + Mac (?) Windows(?)), где (?) — не протестировано, но должно работать без изменений. Профит для меня как разработчика самый прямой — если раньше я просто шлёпал формочки, то сейчас в резюме могу дописать больше интересных вещей и продать своё время дороже, + 50%...100% — это более чем окупит потраченное время, если пересчитать на стандартную оплату труда. Это минимум. Цель — запустить крутой продукт и заработать о***лиарды)
Только какие тут преимущества у Си?
Вы видели эти божественные скобочки, которые я выше привёл? Я могу частично инициализировать структуру! Да это же как JSON! Я могу на си описывать UI с такой же лёгкостью, как JSON написать! В С++ такого нет, в джаве нет, в андроид блеклая эмуляция декларативного описания через XML, в iOS муки и матюки на StoryBoard или как там их инструмент разметки называется, несовместимый с git, в котлин чуть удобнее сделали, но всё равно не то.
Кроме того, Си на мой взгляд меньше всего ограничивает свободу, и при этом при помощи нехитрых макросов ему можно придать выразительность, не уступающую модным фишкам из С++, в т.ч. тем что только готовятся для включения в стандарт. for с ренжами например. Мне нравится его гибкость.
На Си можно писать в функциональном стиле, с функциями можно обращаться как с переменными, надеюсь вы не станете отказывать функциональному программированию в праве на существование? Си — это как Хаскель на минималках, достаточно функциональный для практического применения, но всё ещё с ручным контролем памяти.
Си замечательно дружит со многими другими языками. Я могу просто закинуть сишные файлы в проект на С++/objective-C/D, вроде Swift тоже, могу подключить к проекту на Java через jni, могу сишную либу слинковать с любым другим компилируемым языком. У С++ тут уже начинаются проблемы.
Далее, Си — простой для чтения и написания язык. Я могу показать код программисту на Java/C++/JS/C# и пр., и он гарантированно поймёт, что тут проиходит. Можно смотреть его в плейнтекст и не ломать голову, что это за auto.
Си программы быстро компилируются и быстро запускаются, за 1 секунду я могу собрать (инкрементально) проект и запустить приложение, полная пересборка всего ~4c, а в Java я успею попить кофе, пока всё соберётся, в С++ и подавно.
У меня приложение, и есть все нужные для него виджеты, аналоги андроидных ImageView, TextView, ListView с линейным списком и сеткой, скроббары, прогрессбар, кнопки. Всё, к чему привык на андроид, в облегченном варианте и кроссплатформенно.
Во-первых, что под UE нужно писать на плюсах, под юнити на C# или UnityScript.
Я уже писал, что по моим ощущениям, С уменьшает сложность по сравнению с C++ или C#. На С++ код иногда без боли не взглянуть.
Зачем вам именно мой код, есть известные игровые движки Unreal Engine / Unity с большим сообществом, и некоторые другие, позволяющие собирать игры на Windows/Mac/Linux/Web/Android/iOS.
И есть простые примеры типа такого github.com/redblobgames/helloworld-sdl2-opengl-emscripten
Себе я запилил удобный фреймворк, на котором приятно работать, вот например разметка + внешний вид + добавление кнопки:
Вы видите здесь что-то платформоспецифичное? Разметку и другие параметры я могу объявить в другом файле, если захочется разный вид приложения на разных платофрмах сделать, могу как есть оставить.
Си как-то странно причислять к неустоявшимся технологиям, языку ~50 лет, инструментов и кейсов применения для него наработано огромное количество, множество платформ имеют официальную поддержку, есть стандарты, при соблюдении которых эта поддержка гарантирована.
Получается не один раз, а под каждую платформу придётся писать что-то, а переиспользуется только какая-то небольшая часть?
Переиспользуется как раз почти всё, написание чего требовало каких-то усилий. Обёртка под андриод — уровня хэлловорлда, причём даже не написанная, а тупо позаимствованная из NDKшных примеров.
Я вам подскажу, таким занимается куча людей из устоявшихся технологий, и пока даже просто между iOS и Android настолько большая разница, что всё чаще возникают вопросы имеют ли смысл все эти Xamarin и React Native, если приложение больше пары простых скринов.
Ну если есть деньги на N команд разработки, то почему бы и не писать под каждую платформу отдельно. У меня нет)
Пока рано что-то показывать, однако не вижу, что мне помешает OpenGL приложение собрать под разные платформы. Схема «пишу под десктоп — иногда поглядываю, что там на андроид» уже работает, хотя конечно под андроид отдельная обёртка и шейдеры отличаются и OpenGL ES вместо обычного OpenGL, и отдельный проект в Android Studio, но сишное ядро приложения одно.
Аллокатор, я надеюсь, у вас тоже не требует синхронизации между потоками?
Не требует.
И программа работает на x84/x64/arm/aarch64 без компиляции?
Какая разница, +1 архитектура — всего лишь строчку в мейфайл добавить и поставить компилятор, что куда проще и симпатичнее, чем например, jvm под iOS запихнуть в дистрибутив приложения.
И векторизация инструкций тоже будет использоваться, да?
Да, автовекторизация и прочие оптимизации весьма недурно производительность поднимают.
И порядок инструкций поменяется на лету, ради скорости, да?
Если порядок меняет результат вычисления, и при этом нет грубых нарушений правил языка, ничего не поменяется.
Аллокатор не фрагментарнтирует память, да? И free у Вас работает в отдельном потоке, как на Java, да?
На практике вклад malloc/free во время исполнения с лупой искать надо.
Модель памяти у Вас простая, сама память не течёт, грязную память вы не используете, да?
Да вроде не течёт, тем более сама)
А для боевого применения?
Проще 1 раз на 1 языке написать, чем писать на # под венду, java на андроид, swift на ios и js для веба. Для этого не так много языков годится.
А отладку сможете делать на нем, если у Вас на рабочей машине другая ОС/архитектура процессора?
Для отладки компилятор зашивает в бинарник всё необходимое, при чём здесь ОС и процессор. В С я могу включить в отладочных целях проверки обращения к памяти например, как в той же Java, в релизе могу выключить и получить прирост производительности, а в Java — нет, не доверяет она разработчику.
Да ну, перешёл с джавы на си для своих проектов — наоборот, всё стало гораздо проще. Не нужно писать ненужный бойлерплейт в угоду ООПшным шаблонам проектирования, питать надежды, что всё это влезет в память, а не упадёт с OOM, профилировать перформанс — и так ясно, что всё предельно быстро будет и без задержек на GC, не нужно думать о том, откуда на клиентском устройстве JVM возьмётся, почти не нужен рефакторинг, т.к. без классов функции никак друг с другом не связаны.
Отличный язык для быстрого прототипирования) Просто фигачишь функции и они просто работают)
Orange pi lite2 с радиатором работает стабильно, проверял бенчмарком 7z — все 4ядра на 1800мгц работают, не снижая частоту. Производительность в этом бенчмарке примерно соответсвует x86 процессорам, при стоимости платы ~1800р. Минус а том что из дистрибутивов только старый дебиан и убунту 16.04, все пакеты там старые, видеодрайвер закрытый (хотя у кого он открыт) и прибит гвоздями к какой-то древней версии ядра.
Ну так и молекула вдвое легче гелия, ~216 МДж тоже неплохо, по сравнению с обычным топливом. Можно попробовать эксимерную молекулу из возбждённого неона и атомарного водорода сделать, водород захватит поднятый электрон неона и заполнит свою S орбиталь, вопрос кто сильнее этот электрон будет удерживать.
4.1.2 Смутные указания ([500], [510]) на трёх- и более высокие валентности цезия и бария намекают, что хотя бы иногда, при каких-то условиях, для образования химических связей можно использовать не только валентные, но и внутренние электроны атомов. От самого этого понимания до «абсолютного топлива» ещё как до Луны пешком (pun intended), но обоснованно помечтать есть о чём.
Так используют же в эксимерных лампах и лазерах, пишут, что до 10эВ энергия кванта излучения выходит при распаде эксимерной молекулы. Только вот время жизни известных эксимеров очень невелико, может, в будущем найдутся соединения получше. Нужна прога, в которой вводишь конфигурацию молекулы и заполнения электронных оболочек и её атомов, и получаешь на выходе её энергию и время жизни)
Ахаха, даёшь безопасный браузер на джаваскрипт, с js движком на питон) Раст ещё сырой, чуть что быстрое надо — используй unsafe, за синтаксическим сахаром — в ночные сборки компилятора. Вобщем выбор без выбора.
А зачем? Я сразу пишу как надо.
В линуксовой libc аллокатор с аренами как раз. Если что, можно её статически линковать, не уверен правда, позволяет ли лицензия.
Вы видели эти божественные скобочки, которые я выше привёл? Я могу частично инициализировать структуру! Да это же как JSON! Я могу на си описывать UI с такой же лёгкостью, как JSON написать! В С++ такого нет, в джаве нет, в андроид блеклая эмуляция декларативного описания через XML, в iOS муки и матюки на StoryBoard или как там их инструмент разметки называется, несовместимый с git, в котлин чуть удобнее сделали, но всё равно не то.
Кроме того, Си на мой взгляд меньше всего ограничивает свободу, и при этом при помощи нехитрых макросов ему можно придать выразительность, не уступающую модным фишкам из С++, в т.ч. тем что только готовятся для включения в стандарт. for с ренжами например. Мне нравится его гибкость.
На Си можно писать в функциональном стиле, с функциями можно обращаться как с переменными, надеюсь вы не станете отказывать функциональному программированию в праве на существование? Си — это как Хаскель на минималках, достаточно функциональный для практического применения, но всё ещё с ручным контролем памяти.
Си замечательно дружит со многими другими языками. Я могу просто закинуть сишные файлы в проект на С++/objective-C/D, вроде Swift тоже, могу подключить к проекту на Java через jni, могу сишную либу слинковать с любым другим компилируемым языком. У С++ тут уже начинаются проблемы.
Далее, Си — простой для чтения и написания язык. Я могу показать код программисту на Java/C++/JS/C# и пр., и он гарантированно поймёт, что тут проиходит. Можно смотреть его в плейнтекст и не ломать голову, что это за auto.
Си программы быстро компилируются и быстро запускаются, за 1 секунду я могу собрать (инкрементально) проект и запустить приложение, полная пересборка всего ~4c, а в Java я успею попить кофе, пока всё соберётся, в С++ и подавно.
выбор коэффициента масштабирования — задача платоформозависимой обёртки, можно положить =1, если лучшего решения не найдётся.
Масштабируемых единиц, конечно же)
У меня приложение, и есть все нужные для него виджеты, аналоги андроидных ImageView, TextView, ListView с линейным списком и сеткой, скроббары, прогрессбар, кнопки. Всё, к чему привык на андроид, в облегченном варианте и кроссплатформенно.
Я уже писал, что по моим ощущениям, С уменьшает сложность по сравнению с C++ или C#. На С++ код иногда без боли не взглянуть.
И есть простые примеры типа такого github.com/redblobgames/helloworld-sdl2-opengl-emscripten
Себе я запилил удобный фреймворк, на котором приятно работать, вот например разметка + внешний вид + добавление кнопки:
//…
Вы видите здесь что-то платформоспецифичное? Разметку и другие параметры я могу объявить в другом файле, если захочется разный вид приложения на разных платофрмах сделать, могу как есть оставить.
Переиспользуется как раз почти всё, написание чего требовало каких-то усилий. Обёртка под андриод — уровня хэлловорлда, причём даже не написанная, а тупо позаимствованная из NDKшных примеров.
Ну если есть деньги на N команд разработки, то почему бы и не писать под каждую платформу отдельно. У меня нет)
gist.github.com/ph0b/69586260bc20c58136ef
Какая разница, +1 архитектура — всего лишь строчку в мейфайл добавить и поставить компилятор, что куда проще и симпатичнее, чем например, jvm под iOS запихнуть в дистрибутив приложения.
Да, автовекторизация и прочие оптимизации весьма недурно производительность поднимают.
Если порядок меняет результат вычисления, и при этом нет грубых нарушений правил языка, ничего не поменяется.
На практике вклад malloc/free во время исполнения с лупой искать надо.
Да вроде не течёт, тем более сама)
Проще 1 раз на 1 языке написать, чем писать на # под венду, java на андроид, swift на ios и js для веба. Для этого не так много языков годится.
Для отладки компилятор зашивает в бинарник всё необходимое, при чём здесь ОС и процессор. В С я могу включить в отладочных целях проверки обращения к памяти например, как в той же Java, в релизе могу выключить и получить прирост производительности, а в Java — нет, не доверяет она разработчику.
Отличный язык для быстрого прототипирования) Просто фигачишь функции и они просто работают)
ru.wikipedia.org/wiki/%D0%93%D0%B5%D0%BB%D0%B8%D0%B9#%D0%A1%D0%B2%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%B0_%D0%B2_%D0%B3%D0%B0%D0%B7%D0%BE%D0%B2%D0%BE%D0%B9_%D1%84%D0%B0%D0%B7%D0%B5