Здравствуйте, Khimik, Вы писали:
EP>>Значение имеет итоговая скорость программы. Если программа в 2x-50x медленнее за счёт того что ты взял Delphi, то это плохая программа с точки зрения "высокоскоростного кода" который мы обсуждаем. K>Итоговая скорость определяется скоростью некоторых ключевых (лимитирующих) участков,
Не всегда. Частенько неэффективность размазана толстым слоем по всем частям системы, да так что нет надежды на то что переписывание небольших частей может спасти ситуацию.
K>только их и надо оптимизировать
Ну вот на C++ оптимизировать и эти bottleneck'и, и код в целом — на порядки проще чем на Delphi.
K>(возможно, переводить на ассемблер).
Вот как раз с современными компиляторами C++ это:
во-первых не нужно — даже для рукопашного лисапедения SSE/AVX используются intrinsics, а не ассемблер
во-вторых очень сомнительно что получится написать более быстрый asm код чем генерируют компиляторы C++ даже затратив значимые усилия (ау, сейчас 2018 год).
Пример для чего сейчас реально может потребоваться ASM — это отсутствие какой-либо инструкции в intrinsics (тогда __asm__ секция будет состоять из нескольких инструкций максимум), либо крайне специфичные техники типа корутин (по типу Boost.Context)
S>>Осталось сравнить оба варианта на реальном измерении скорости. ПОдозреваю, что вариант с обычным for работать быстрее, потому что будет оптимизирован встроенным оптимизатором.
K>А в самом деле, как компилятор Delphi XE8 поддерживает многоядерность/многопроцессорность?
Просто прелестно, что на форуме программистов никто не смог или не захотел ответить на этот вопрос. Ну ладно, задам его в другом разделе
Какую задачу решаете ?
Неясно вы уже написали ваш препроцессор и хотите его улучшить ?
Если вы хотите писать то есть готовые инструменты: всякие m4, T4 и т.п.
Если нужно ещё менять синтаксис и "понимать" код, то тогда нужен полноценный парсер Delphi.
K>(По ходу вопрос – насколько можно ещё оптимизировать этот код, или это уже предел?)
Тут нужно писать тесты и прогонять их.
На глаз сказать, что лучше, у вас точно не выйдет.
Здравствуйте, Khimik, Вы писали:
K>Здравствуйте, _NN_, Вы писали:
_NN>>Если вы хотите писать то есть готовые инструменты: всякие m4, T4 и т.п.
K>У меня вопросы — есть ли в Delphi m4 и T4, и что это такое (как-то кратко на пальцах, если можно.)
Внешние препроцессоры не связаны с языком разработки.
Ими можно хоть простой текст генерировать.
Также как и препроцессором C можно генерировать что угодно, хоть Delphi.
Здравствуйте, Khimik, Вы писали:
K>У меня сильное подозрение, что Delphi — очень хороший язык, хорошо подходящий для высокоскоростных приложений, который пал жертвой неправильной моды (что-то вроде фишеровского убегания в программировании).
Не хочу спорить, просто интересно, с какими языками для высокоскоростных приложений ты сравнивал?
Насколько я помню, в делфи был довольно неплохой редактор форм. Других преимуществ что-то не припомню.
K>>У меня сильное подозрение, что Delphi — очень хороший язык, хорошо подходящий для высокоскоростных приложений, который пал жертвой неправильной моды (что-то вроде фишеровского убегания в программировании).
Z>Не хочу спорить, просто интересно, с какими языками для высокоскоростных приложений ты сравнивал?
На gamedev.ru один участник написал, что его игра на Щи++ была на 20% быстрее, чем на Delphi:
K>>А в самом деле, как компилятор Delphi XE8 поддерживает многоядерность/многопроцессорность? K>Просто прелестно, что на форуме программистов никто не смог или не захотел ответить на этот вопрос. Ну ладно, задам его в другом разделе
K>>>А в самом деле, как компилятор Delphi XE8 поддерживает многоядерность/многопроцессорность? K>>Просто прелестно, что на форуме программистов никто не смог или не захотел ответить на этот вопрос. Ну ладно, задам его в другом разделе
.
SD>странные у тебя претензии, ты ж спрашивал про какой-то маргинальный компилятор
Про низкоуровневую оптимизацмю я тоже спросил в первом посту темы.
Мой будущий перекомпилятор предполагается прежде всего как средство оптимизации — переписать код для финального релиза программы. И сразу возникает вопрос, насколько эффективной будет такая оптимизация.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Поздравляю с "изобретением" метапрограммирования. Беда здесь в том, что из всего, что я видел, оно концептуально красиво реализовано лишь в трех языках: Common Lisp, D и Nim, первый из которых ну вот вообще не выбор для твоих задач, второй всю жизнь сырой, а третий молодой и не понятно, насколько далеко двинется. МП на плюсах — это классический пример "сделанного чужими для хищников", если говорить не о разворачивании одного-трех этажей шаблонов, а о полноценном compile–time-исполнении.
Здравствуйте, Khimik, Вы писали:
K>>>У меня сильное подозрение, что Delphi — очень хороший язык, хорошо подходящий для высокоскоростных приложений, который пал жертвой неправильной моды (что-то вроде фишеровского убегания в программировании).
Z>>Не хочу спорить, просто интересно, с какими языками для высокоскоростных приложений ты сравнивал?
K>На gamedev.ru один участник написал, что его игра на Щи++ была на 20% быстрее, чем на Delphi:
На этом основании ты сделал вывод?
Delphi — очень хороший язык, хорошо подходящий для высокоскоростных приложений
S>>Осталось сравнить оба варианта на реальном измерении скорости. ПОдозреваю, что вариант с обычным for работать быстрее, потому что будет оптимизирован встроенным оптимизатором.
K>А в самом деле, как компилятор Delphi XE8 поддерживает многоядерность/многопроцессорность?
Модуль System.Threading + книжка по программированию про потоки
K>Мне пока главное — к Delphi этот m4 подключить нельзя?
Вроде ж современные Delphi имеют всякие pre-build/post-build хендлеры — так что можно (сначала пре-билдом запускаем M4 чтобы сгенерил целевые файлы, далее обычный билд эти сгенерённые файлики заюзает)
K>Интересно, не пробует ли кто-то из авторов ЯП делать кастомные прекомпиляторы, которые может написать программист-юзер?
Макропроцессоры давно используют с этой целью.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
