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

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

Там просто порой есть много тупых действий  ну как например - перемножить массив из 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

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