Скажите пожалуйста, если сравнивать по работоспособности С и С++.. оправдана ли будет скорость выполнения программы против скорости её написания? 

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

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

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

Ну в общем-то я про это и спрашиваю, будет ли 
Это я в качестве примера привёл возможность использования в такой ситуации асма 

Вообще я слышал, что С работает быстрее С++. Но честно говоря, понятия не имею почему. Чем он действительно быстрее-то? На чём С выигрывает перед С++?

Это сообщение отредактировал(а) Proger10 - 26.3.2009, 03:37

как может работать один язык быстрее другого?

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

Скорость падает не от компилированного кода, а от кривых алгоритмов и их кривой реализации... так что не заморачивайтесь - пишите на чем угодно.

jonie, скорость падает еще и от кривого компилятора
так что с точки зрения быстродействия писать нада не на каком-то языке, а под конкретный компилятор 

нету

Добавлено через 40 секунд
есть смысл написать это на haskell =)

Lazin, у haskell'а быстродействие больше чем у С\С++ ? ниверю

я думаю предложение Haskella было не из за преимуществ в скорости (но думаю что он не сильно отстает от Си/Cpp), 
а как более удобный для решения такого ряда задач (н.с.) , так как он  функциональный.

Это сообщение отредактировал(а) mes - 26.3.2009, 10:40

зависит от реализации, у GHC быстродействие ниже чем у большинства компиляторов с++, у JHC в среднем не меньше, но он еще сырой
чисто теоретически, производительность кода написанного на haskell, может быть даже выше, чем у с++ кода из-за частичного применения ф-й, например, пишешь ты ф-ю на с++

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

что можно представить как 

ф-ю принимающую один аргумент и возвращающую ф-ю принимающую один аргумент и возвращающую Int
чисто теоритичесски, компилятор, или даже рантайм, может генерировать такие частично примененные ф-ии, вместо одной общей реализации, что может привести к увеличению производительности

Будет проигрыш в производительности   Хороший оптимизирующий компилятор сможет сделать такой цикл более производительным, чем тупо написанный на асм. На асм можно написать цикл более производительно, чем сможет сделать компилятор, но для этого надо быть экспертом по performance analysis, а таких считанные единицы. Кроме того, компилятор даже может этот цикл распараллелить (если он умеет), что даст привар на всяких Core Duo и пр.
А С/С++ дадут одинаковую производительность, если не использовать С++ run-time конструкции в узких местах.

Ну в C++ компилятор также может заинлайнить все вызовы, как, например, при сортировке через std::sort. А в runtime, конечно, уже никак. 

Чтобы в runtime инлайнить функции нужен уже какой-то JIT компилятор. Вот он может, чисто теоретически, проанализировать весь загруженный на тот момент код и заинлайнить вызов виртуальной функции. 

Да и в number crunching вроде не принято пользоваться JIT компиляторами, там в основном Fortran/C/C++.

вроде бы это не та задача, где надо оптимизировать в run-time
да и передачи параметров через стек можно избежать, если юзать __fastcall
а на асме можно например оптимизировать то что не оптимизировал компилятор, может распараллеливает он хорошо, зато в других местах генерит очень неоптимальный код, кроме того компиляторы С++ не поддерживают достаточно большое количество полезных инструкций х86

OMFG!!1 ну надо-же, это каких интересно?

it depends... во первых, любая задача может выиграть от оптимизации в рантайме, во вторых, помимо оптимизации в рантайме(которую пока еще никто не делает), у компилятора haskell предостаточно средств для оптимизации, так-как переменных нет, mutable state - отсутствует, по типу(!) функции можно определить будет ли эта ф-я изменять состояние чего-либо или нет и так далее...
это просто другой подход к решению проблемы, программируя на с++(си, паскале) ты не столько работаешь над алгоритмом, сколько над его реализацией(в этой переменной у нас будте одно значение, в той - другое, потом мы делаем с ними следующее ... и вон в той переменной оказывается результат); программируя на функциональных языках(а особенно на haskell) используют совершенно другой подход, обычно ФП программа это императивная программа наоборот, мы не определяем как будет вычисляться результат конкретно, вместо этого мы вводим набор правил для получения результата, как конкретно и в какой последовательности это будет реализовано уже не важно  
ну и определять вручную как вызывать ту или иную ф-ию, передавать параметры через стэк или регистры, это прошлый век, даже для с++  

Lazin, это обсуждалось уже много раз, покажи С++ код без асм вставок, который приведет к генерации bswap, fldpi/fldlg2/fld*, и много чего еще
в msvc есть intrinsic'и но далеко не для всех инструкций

Добавлено через 4 минуты

на уровне инструкций процессора тоже нет переменных, и практика показывает, что нет способа быстрее способа сложить два произвольных числа чем add reg,reg

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

А какой это - кривой?   

Писать я кстати буду под компайлер GNU GCC. (линуксовый)

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

а в какой не ткни - то кривой, msvc например

скомпили какойнить код сложнее helloworld и увидишь

Это сообщение отредактировал(а) GoldFinch - 26.3.2009, 22:54

GoldFinch, а G++ кривой? 
Какой, по-вашему, прямой?

По версии GoldFinch - все кривые, он сам как компилятор, пишет все на ассемблере, и знает какой код процессор будет быстрее выполнять, performance guru одним словом 

Добавлено через 1 минуту и 31 секунду

любой современный, более или менее распространенный с++ компилятор, другого все-равно не дано

Ну G++ (gcc) относится к хорошим компайлерам или не очень? Зато свободный.. а то компилятор от visual studio денег стоит, а компилить на нелицухе как-то не модно 

Proger10, кто тебе сказал, что он денег стоит?

Не уж-то майкрософтовский и бесплатный? Эти понятия разве совместимы? 

Proger10, у MS КУЧА бесплатных продуктов.
Например Visual Studio Express(основное отличие - возможность ставить сторонние плагины. Остальные отличия ты не заметишь)

не обязательно (даже без инлайна). в x64 параметры не будут передаваться в стеке.... а можно и в х86 сделать __fastcall ....

хренасе. MSVC по оптимизации кода очень не плох, и врядли g++ его догонит... в общем GoldFinch сказал что хреновый - примеры где он лоханулся в студию!

Platform SDK бесплатен. В него входит MSVC компилер и, собственно, хедеры....

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

то что конмпелировалось


а должно было бы скомпилироваться так


еще у msvc багнутый встроенный ассемблер %)

Ох уж эти сказочники 

Результат
Строки 27-29
cl:
 (из 2003 студии)
Алгоритм измерения кривизны рук знаешь?   

xvr, а у меня

из 2008 студии, удали свое старье и поставь новую версию)

листенг:


Это сообщение отредактировал(а) GoldFinch - 27.3.2009, 12:51

Нет уж увольте - ищите, чему у нее теперь соотвествует /G6 и как теперь выглядит /Ox (у меня это /Ogityb1 /Gs, в 2008 - /Ogtpy судя по листингу)
, потом поговорим о кривых компиляторах   

С практической стороны возможно будет быстрее, безглючнее и дешевле написать на плюсах без всяких асмовых вставок.
Скорость догонять железом ( в тяжелых случаях построить распределённую систему аля Folder@Home  ).
Прошу не считать пост холиваром  .

[irony]
о да, это самый простой и дешевый вариант, доступный любому  
[/irony]

алюминием.
если руки кривые, конечно проще склепать тормознутую прогу, объявить нереальные системные требования, и сказать что это прога high-end класса

 Если твоя ЗП меньше цены аренды железа - не думай, что другие тоже нахаляву работают ;)

Считаю, что оптимальнее всего написать на С++, затем, если скорость не устроит, прогнать через профайлер (только нужно прогонять прогу скомпилированную с опциями (для gcc): -O3 -g -pg - максимальная оптимизация, отладочная информация, информация для профилирования), а затем оптимизировать узкие места всеми доступными способами.

GoldFinch а у меня вот так скомпилолось (vc9):

мне застрелиться? (оптимизация SSE2)

можно и так получить:

опция /fp:strict


так где лоханулся компилятор-то?

не может такого быть, это не полный код main


и mov [esp],imm32 хуже чем push imm32

Это сообщение отредактировал(а) GoldFinch - 2.4.2009, 09:01

речь шла о функциях принимающих float через стек

M bsa

Давайте вернёмся к теме обсуждения.

bsa, вроде бы тема себя уже исчерпала к середине 1й страницы

GoldFinch скмпилируй да посмотри

jonie, чего посмотри? ты там не всю функцию привел %)
сам посмотри ^^

Это сообщение отредактировал(а) GoldFinch - 2.4.2009, 19:21