Языки, более быстрые, чем C ++ [закрыты]

Question

Говорят, что Blitz ++ обеспечивает производительность, близкая к Fortran.

Действительно ли Fortran, как правило, быстрее обычного C ++ для эквивалентных задач?

А как насчет других языков HL с исключительной производительностью во время выполнения?Я слышал о нескольких языках, превосходящих C ++ для определенных задач...Objective Caml, Java, D...

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

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

Answer 1

Fortran быстрее и почти всегда лучше, чем C ++ для чисто числового кода. Есть много причин, почему Фортран быстрее. Это самый старый скомпилированный язык (много знаний по оптимизации компиляторов). Это по-прежнему язык для числовых вычислений, поэтому многие поставщики компиляторов зарабатывают на жизнь продажей оптимизированных компиляторов. Есть и другие, более технические причины. Fortran (ну, по крайней мере, Fortran77) не имеет указателей и, следовательно, не имеет проблем с псевдонимами, которые мешают языкам C / C ++ в этой области. Многие высокопроизводительные библиотеки все еще написаны на Фортране с долгой (> 30 лет) историей. Ни C, ни C ++ не имеют хороших конструкций массивов (C слишком низкий уровень, C ++ имеет столько же библиотек массивов, сколько компиляторов на планете, которые несовместимы друг с другом, что препятствует созданию пула хорошо протестированного и быстрого кода).

Answer 2

Вопрос о том, быстрее ли fortran, чем c ++, является предметом обсуждения.Кто-то говорит "да", кто-то "нет";Я не буду вдаваться в подробности.Это зависит от компилятора, архитектуры, на которой вы его запускаете, реализации алгоритма...и т.д.

Где фортран действительно имеет большим преимуществом перед C является время, необходимое вам для реализации этих алгоритмов.И это делает его чрезвычайно хорошо подходящим для любого вида численных вычислений.Я приведу лишь несколько очевидных преимуществ по сравнению с C:

• индексация массива на основе 1 (чрезвычайно полезна при реализации больших моделей, и вам не нужно думать об этом, а просто Перевод формулы
• имеет энергетического оператора (**) (Боже, чья была идея, что подойдет функция власти?Вместо оператора?!)
• я бы сказал, что у него лучшая поддержка многомерных массивов из всех языков на текущем рынке (и не похоже, что это изменится так скоро). - A(1,2) прямо как в математике
• не говоря уже об избежании циклов - A = B * C умножает массивы (почти как синтаксис matlab с скорость компиляции)
• в нем встроены функции параллелизма на язык (ознакомьтесь с новым стандартом на этот счет)
• очень легко подключается к таким языкам, как C, python, так что вы можете выполнять свои сложные вычисления на fortran, в то время как ..неважно ...на языке по вашему выбору, если вы чувствуете такое желание
• полностью обратная совместимость (поскольку весь F77 является подмножеством F90), так что в вашем распоряжении целый век кодирования
• очень, очень портативный (это может не сработать для некоторых расширений компилятора, но в целом это работает как шарм)
• сообщество, ориентированное на решение проблем (поскольку пользователями fortran обычно являются не cs, а математики, физики, инженеры...люди, не имеющие опыта программирования, но скорее имеющие опыт решения проблем, чьи знания о твой проблема может быть очень полезной)

Прямо сейчас мне в голову не приходит ничего другого, так что придется обойтись этим.

Answer 3

С Blitz ++ конкурирует не столько язык фортранов, сколько столетия работы, посвященной математическим библиотекам фортранов. В некоторой степени язык помогает: у более старого языка было намного больше времени, чтобы получить оптимизирующие компиляторы (и, давайте посмотрим правде в глаза, C ++ является одним из самых сложных языков). С другой стороны, библиотеки C ++ высокого уровня, такие как Blitz ++ и uBLAS позволяет вам заявить о своих намерениях более четко, чем относительно низкоуровневый код на Фортране, и учитывает совершенно новые классы оптимизации во время компиляции.

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

Answer 4

FORTAN обычно быстрее, чем C ++, для обработки массивов из-за различных способов, которыми языки реализуют массивы - FORTRAN не допускает псевдонимов элементов массива, в то время как C ++ делает. Это облегчает работу компиляторов FORTRAN. Кроме того, в Фортране есть много очень зрелых математических библиотек, над которыми работали почти 50 лет - C ++ не так давно!

Answer 5

Это будет во многом зависеть от компилятора, программистов, от того, имеет ли он gc и может ли он сильно отличаться. Если он скомпилирован непосредственно в машинный код, то ожидайте, что он будет иметь большую производительность, чем интерпретируется большую часть времени, но в любом случае возможна ограниченная оптимизация, прежде чем вы получите скорость asm.

Если бы кто-то сказал, что fortran был немного быстрее, вы бы в любом случае написали новый проект?

Answer 6

С c ++ дело в том, что он очень близок к аппаратному уровню. На самом деле, вы можете программировать на аппаратном уровне (с помощью сборочных блоков). В целом, компиляторы c ++ неплохо справляются с оптимизацией (для значительного увеличения скорости включите «Link Time Code Generation», чтобы разрешить встраивание функций между различными файлами cpp), но если вы знаете аппаратное обеспечение и знаете Как, вы можете написать несколько функций в ассемблере, которые работают еще быстрее (хотя иногда вы просто не можете победить компилятор).

Вы также можете реализовать свои собственные диспетчеры памяти (чего не позволяют многие другие языки высокого уровня), поэтому вы можете настроить их для своей конкретной задачи (возможно, большинство выделений будет 32 байта или меньше, тогда вы можете просто иметь гигантский список 32-байтовых буферов, которые вы можете выделить / освободить за O (1) время). Я считаю, что c ++ МОЖЕТ побить любой другой язык, если вы полностью понимаете компилятор и используемое вами оборудование. Большинство из них сводится к тому, какие алгоритмы вы используете больше всего на свете.

Answer 7

Вы, должно быть, используете какой-то странный управляемый XML-анализатор, когда загружаете эту страницу.:)

Мы постоянно профилируем код, и выигрыш постоянен (и это не наивный C ++, это просто современный C ++ с boos).Это последовательно увеличивает любую реализацию CLR как минимум в 2 раза, а часто и в 5 раз и более.Немного лучше, чем во времена Java, когда она была примерно в 20 раз быстрее, но вы все равно можете найти хорошие экземпляры и просто удалить всю систему.Объект раздувается и явно превращает его в кашу.

Единственное, чего не понимают управляемые разработчики, это то, что аппаратная архитектура препятствует любому масштабированию виртуальных машин и корневых подходов объектов.Вы должны увидеть это, чтобы поверить в это, зависнуть, запустить браузер и перейти на "тонкую" виртуальную машину, такую как Silverlight.Вы будете поражены, насколько это медленно и требовательно к процессору.

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

Answer 8

Я написал это всего несколько минут назад:

Управление строковой памятью C ++

Answer 9

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

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

Преждевременная оптимизация - корень всех зол

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

Answer 10

D иногда может быть быстрее, чем C ++ в практических приложениях, в основном потому, что наличие сборки мусора помогает избежать накладных расходов RAII и подсчета ссылок при использовании интеллектуальных указателей. Для программ, которые выделяют большое количество небольших объектов с нетривиальными жизненными циклами, сборка мусора может быть быстрее, чем управление памятью в стиле C ++. Кроме того, встроенные массивы D позволяют компилятору выполнять лучшую оптимизацию в некоторых случаях, чем вектор STL в C ++, чего компилятор не понимает. Кроме того, D2 поддерживает неизменяемые данные и чисто функциональные аннотации, на основе которых оптимизируются последние версии DMD2. Уолтер Брайт, создатель D, написал интерпретатор JavaScript как на D, так и на C ++, и, по его словам, версия D работает быстрее.

Answer 11

Все зависит от компилятора, например, компилятор Stalin Scheme, он превосходит почти все языки в наборе микропроцессоров Debian, но упоминают ли они что-нибудь о времени компиляции?

Нет, я подозреваю (я раньше не использовал Сталина), компиляция для эталонных тестов (т.е. все оптимизации на максимальных уровнях усилий) занимает очень много времени для всего, кроме самых маленьких фрагментов кода.

Answer 12

если код не написан для повышения производительности , то C # быстрее, чем C ++ .

Необходимый отказ от ответственности: Все тесты являются злыми.

Вот тесты, которые в пользу C ++ .

Приведенные выше две ссылки показывают, что мы можем найти случаи, когда C ++ работает быстрее, чем C #, и наоборот.

Answer 13

Производительность скомпилированного языка - бесполезная концепция. Важным является качество компилятора, то есть какие оптимизации он может применить. Например, часто - но не всегда - компилятор Intel C ++ создает более производительный код, чем g ++. Итак, как вы оцениваете производительность C ++?

Суть языковой семантики в том, насколько легко программисту получить компилятор для получения оптимального результата. Например, часто проще распараллелить код на Фортране, чем код на С, поэтому Фортран по-прежнему широко используется для высокопроизводительных вычислений (например, моделирования климата).

<Ч>

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

Например, вызовы функций в ассемблере могут использовать регистры для передачи аргументов, и им не нужно создавать ненужные стековые фреймы, но хороший компилятор также может это делать (например, inlining или fastcall). Недостатком использования ассемблера является то, что более эффективные алгоритмы труднее реализовать (например, линейный поиск или двоичный поиск, поиск по хеш-таблице, ...).

Answer 14

Работа намного лучше, чем C ++, в основном сводится к тому, чтобы компилятор понимал, что означает программист. Примером этого может служить случай, когда компилятор любого языка делает вывод, что область кода не зависит от его входных данных, и просто вычисляет значение результата во время компиляции.

Другим примером этого является то, как C # создает некоторый очень высокопроизводительный код просто потому, что компилятор знает, что «означают» определенные заклинания, и может хитро использовать реализацию, которая обеспечивает наивысшую производительность, когда транслитерация той же программы в C ++ приводит к ненужные циклы выделения / удаления (скрытые шаблонами), потому что компилятор обрабатывает общий случай, а не частный случай, который дает этот фрагмент кода.

Последний пример может быть в адаптациях C для Brook / Cuda, разработанных для экзотического оборудования, которое уже не так экзотично. Язык поддерживает точные примитивы (функции ядра), которые сопоставляются с оборудованием, которое не компилируется von-neuman.

Answer 15

Именно поэтому вы используете управляемый браузер? Потому что это быстрее. Или управляемая ОС, потому что она быстрее. Нет, подожди, это база данных SQL .. Подожди, это должна быть игра, в которую ты играешь. Стоп, там должен быть кусок числового кода, с которым Java и Csharp откровенно бесполезны. Кстати, вы должны проверить, на что написана ваша виртуальная машина, чтобы зашлепать корневой язык, и сказать, что это медленно.

Что за ошибочное мнение, но покажите мне быстро управляемое приложение, чтобы мы все могли посмеяться. VS? OpenOffice?

Answer 16

C # намного быстрее, чем C ++ - в C # я могу написать синтаксический анализатор XML и обработчик данных в десятую часть времени, затрачиваемого на написание этого C ++.

О, вы имели в виду скорость выполнения?

Даже тогда, если вы берете время от первой строки кода, написанной до конца первого выполнения кода, C # все еще, вероятно, быстрее, чем C ++.

Это очень интересная статья о преобразовании программы C ++ в C # и усилиях, необходимых для того, чтобы сделать C ++ быстрее, чем C #.

Таким образом, если принять во внимание скорость разработки, почти все превосходит C ++.

Хорошо, чтобы удовлетворить только требования к производительности во время выполнения OP: Это не язык, а реализация языка , определяющая производительность во время выполнения. Я мог бы написать компилятор C ++, который производит самый медленный код, который только можно себе представить, но это все еще C ++. Теоретически также возможно написать компилятор для Java, который предназначен для инструкций IA32, а не для байтовых кодов Java VM, обеспечивая повышение скорости выполнения.

Производительность вашего кода будет зависеть от соответствия сильных сторон языка и требований кода. Например, программа, которая выполняет большое количество выделения / освобождения памяти, будет плохо работать в наивной программе C ++ (т. Е. Использовать распределитель памяти по умолчанию), поскольку стратегия выделения памяти C ++ слишком обобщена, тогда как распределитель на основе GC в C # может работать лучше (так как вышеуказанная ссылка показывает). Работа с строками медленная в C ++, но быстрая в таких языках, как php, perl и т. Д.

Answer 17

Ааа ... Старый добрый вопрос - какой компилятор делает код быстрее?

<Ол>

Это имеет значение только в коде, который фактически проводит много времени в нижней части стека вызовов, то есть в горячих точках, которые не содержат вызовов функций, таких как инверсия матриц и т. д.

(подразумевается 1) Это имеет значение только в коде, который фактически видит компилятор. Если ваш программный счетчик проводит все свое время в сторонних библиотеках, которые вы не собираете, это не имеет значения.

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

Со всеми этими переменными трудно отличить хорошие компиляторы.

Однако, как уже было сказано, если вам нужно скомпилировать много кода на Фортране, не переписывайте его.