Итак, занялся я разработкой очень ресурсоёмкого приложения (на основе нейронных сетей) и задался вполне логичным вопросом: что эффективнее, Паскаль или C#? С одной стороны, Паскаль проще и логичнее, с другой- компилятор C# промышленный и способен оптимизировать код. Я видел официальные примеры, доказывающие, что Паскаль превосходит C#, но там приводился пример с перемножением матриц, а у меня задачи гораздо сложнее(например, двумерная свёртка трёхмерного массива).
2 лайка
оптимизациями занимается больше JIT-компилятор, а не сам компилятор. Есть вещи, которые в паскале в силу объективных причин медленные: статические массивы и вообще всякая размерная хрень (множества и т.д.)
1 лайк
По моему, если вам нужна скорость, ну прям совсем, каждая капля - пишите на C++, а то и на асемблере, отдельные куски (как подпрограмму для “двумерной свёртки трёхмерного массива” (знать бы ещё что етовае…) ), и после делайте удобную обёртку на паскале. Хотя я не уверен можно ли подключать куски кода с асемблера, никогда на нём не программировал, только чужие коды читал))).
1 лайк
Эти вещи я никогда и не использовал 
Тут дело не настолько серьёзное, просто хотелось бы понять, например, быстрее ли те же массивы(динамические) в Паскале, чем в C#. Двумерная свёртка трёхмерного массива - это по сути та-же свёртка, как с матрицами(скользящим окном), но окно в глубину имеет не 1 слой, а несколько. Сейчас я реализую нейросетевой фоторедактор, поэтому делать черепахоподобную реализацию не очень хочется.
Одинаково
1 лайк
Чисто для любопытства: а никто не может провести тест - написать две программы, делающее одно и то тоже, и сравнить результаты по времени на одинаковых (и разных) компьютерах?
Сравнивали уже много раз 
1 лайк
По мере работы появились очень странные результаты. Переписал программу с Паскаля на C#, получил скорость, более чем в 2 раза превышающую скорость Паскаля, однако результат работы гораздо хуже(очевидно, баг), хотя переводил строго дословно. Построчно. Почему так происходит? Код перепроверял несколько раз, ошибок не нашёл. Стандартных паскалевских возможностей не использовал, писал на чистом .NET. Причём основные особенности C#, которые вполне могли бы привести к таким стрёмным результатам, я знаю (например то, что деление целого на целое даёт целое и подобное). И такая странность меня “преследует” постоянно, если переводится программа не в 5 строк.
P. S. Может, кто знает C#? Можете помочь найти причину(приведу короткий код для примера)?
На Паскале надо снимать все флаги “Генерировать отладочную информацию” и выполнять по Shift-F9 без связи с оболочкой. Тогда результаты будут одинаковыми с режимом Release в C#. Плюс у Вас где-то ошибка в алгоритме при переводе.
1 лайк
В том то и дело, что всё запускались в Release и без оболочки.
Ну, значит, если вам сложно сравнить что не так переведено - надо сравнивать отдельные части программы. Или скиньте обе версии, паскаль и C#, вместе с кодом которым вы замеряли. Я попробую найти что не так, но ничего не обещаю, если будет слишком сложно)).
2 лайка
У меня новость. Правда не знаю, хорошая или плохая. Мне удалось переписать FastNeuralColor на C# и откомпилировать. Версия зеркальна паскалевской. Паскаль, к сожалению, проиграл C# по скорости со счётом 1:2. На Паскале программа выполнялась 62 секунды, на C# - 34 секунды, то есть почти в 2 раза медленнее. Я рад, ведь моя программа теперь работает быстрее. И огорчён, ведь её исходник стал не таким красивым, как на Паскале. Исходник: FastNeuralColor.cs (52,2 КБ) Вызов csc.exe(компилятора): Compile.bat (511 Байты)
Для компиляции заменить в папке с ГитХаба паскалевский файл на сишный, поместить батник в ту же папку и запустить.
А ссылка на гитхаб? А дать рядом с исходниками на C# исходники паскаля? Вы что, в наш век без этого нельзя)))
А компилировать как будете? Без Bat?
- Смотря что.
- А зачем компилировать, .exe, если что, у вас в репозитории есть, а я хотел только на исходники посмотреть.
C#, естесственно.
Да, но это Паскалевский exe. А с чем Вы его сравнивать будете?
Ну так для C# исходник вы вместе с .bat файлом дали, в чём проблема?
Bat - файл ни разу не скачан.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021