влияет ли использование в C++ классов на скорость проги?
имхо в зависимости от компилятора будут небольшие вариации по производительности в обе стороны.
в обе потому что еще неизвестно, как ты на чистых сях все это реализуешь.
если будешь использовать RTTI, возможно C++ будет немного проигрывать.
там где возможно, лучше заменить RTTI шаблонами.
зы: насколько я понимаю, плюсовые классы преобразуются компилятором в C-style структуры.
методы устроены так же, как сишные функции, только добавляется еще указатель this в качестве аргумента.
поправьте, если ошибаюсь.
в обе потому что еще неизвестно, как ты на чистых сях все это реализуешь.
если будешь использовать RTTI, возможно C++ будет немного проигрывать.
там где возможно, лучше заменить RTTI шаблонами.
зы: насколько я понимаю, плюсовые классы преобразуются компилятором в C-style структуры.
методы устроены так же, как сишные функции, только добавляется еще указатель this в качестве аргумента.
поправьте, если ошибаюсь.
> придется использовать много объектов типа матриц
BLAS, LAPACK и никаких сей, тем более --- приплюснутых.
---
"Real Programmers do Accounting (if they do it at all) in Fortran."
BLAS, LAPACK и никаких сей, тем более --- приплюснутых.
---
"Real Programmers do Accounting (if they do it at all) in Fortran."
насколько, в принципе, будет различаться скорость работы, к примеру, с матрицами, реализованными в виде класса и скорость работы с матрицами, работа с которыми реализована процедурами в стиле обычного си?Программа, написанная на Си, будет работать медленнее, чем написанная на Си++. Только ты вряд ли сможешь написать программу именно на Си++, да ещё так, чтобы она работала быстрее каких-то специализированных математических пакетов или других языков, типа C# и Java. Ключевым моментом в программировании таких вещей на Си++ будут шаблоны и, как сейчас видится, правильное использование оператора new.
Так же стоит посмотреть на uBLAS в boost.
нужно писать с нуля.Нужно все совсем самому писать? или можно не изобретать велосипед, и использовать уже готовое, отлаженное, и хорошо работающее?
Я, вообще, согласен с КОНТРОй. Мне еще вспоминается название ATLAS. Но я пользовался всеми этими blas/lapack'ами очень давно и мало.
PS: может и оффтопик, но все же хоть как-то связано с C vc C++
Первоисточник можно найти на форуме ФДС в архивах примерно год назад.
Вопрос (автор: Jikon):
Исходя из простейших представлений о компиляции, можно предположить, что
int a;
cin >> a;
будет компилироваться с оптимизацией в простое чтение int, поскольку на этапе компиляции уже известно, какой тип надо считывать, в то время как вариант
int a;
scanf("%d", &a);
должен определять этот тип во время исполнения, разбирая по косточкам форматную строку.
Тем не менее, на практике (VC++ 2003) второй вариант быстрее на порядок. Почему?
мне нужно написать вычислительную прогу. считать будет много. нужно писать с нуля. придется использовать много объектов типа матриц и т.д.http://www.mathcom.com/corpdir/techinfo.mdir/q160.html#q160....
Библиотека blitz++ существует уже больше 10 лет
и хорошо себя зарекомендовала
http://www.oonumerics.org/blitz/
http://www.oonumerics.org/blitz/benchmarks/acoustic.html
> Почему?
потому что смысл библиотеки iostream не в том чтобы работало быстро, а в том чтобы удобно было писать и получалось без ошибок. оператор >> синхронизует треды, синхронизует потоки между собой (см. tie и делает много чего другого, что scanf-у и не снилось. а если нужно чтобы io работал быстро, то пользуются write/read или даже mmap.
потому что смысл библиотеки iostream не в том чтобы работало быстро, а в том чтобы удобно было писать и получалось без ошибок. оператор >> синхронизует треды, синхронизует потоки между собой (см. tie и делает много чего другого, что scanf-у и не снилось. а если нужно чтобы io работал быстро, то пользуются write/read или даже mmap.
scanf("%d", &a);от компилятора зависит
должен определять этот тип во время исполнения, разбирая по косточкам форматную строку.
кажись gcc если включенаоптимизация - парвит этот %d во время компиляции
если отключена, то не парсит
Ну не знаю, мне это кажется маловероятным. Все же компилит gcc, а scanf берется из glibc. Ну это и не очень важно.
Вот что мне больше всего не нравится в glibc, так это то, что вот такой код:
Вот что мне больше всего не нравится в glibc, так это то, что вот такой код:
char* pc; // указатель на ОЧЕНЬ длинную строкуТакой код работает за время линейно зависящее от длины "строки" pc. Не знаю зачем, но sscanf явно ищет первый '\0' после pc, и только потом начинает парсить форматную строку
int n;
sscanf(pc, "%d", &n); // считать только первый int
во помню свой диплом обсчитывал на серверах лаборатории о скорости не парился, главное было распаралелить. писал на сипипи, научнику так приспечело, стока гемора поимел 
Если есть множественное наследование и много виртуальных функций, то может значительно притормаживать.
мне нужно написать вычислительную прогу. считать будет много. нужно писать с нуля. придется использовать много объектов типа матриц и т.д. насколько, в принципе, будет различаться скорость работы, к примеру, с матрицами, реализованными в виде класса и скорость работы с матрицами, работа с которыми реализована процедурами в стиле обычного си?смысла писать вычислительные программы на цепепе нет вообще, Си достаточно. Максимум, что цепепе в данном случае может предложить удобного - autoptr (auto_ptr ?).
Ну а если использовать в качестве массивов векторы, то, по сравнению с обычными массивами при хорошо написанной программе, скорость падает раза в 3.
> смысла писать вычислительные программы на цепепе нет вообще, Си достаточно
срочно иди ботай, чем отличается си от си++
> Максимум, что цепепе в данном случае может предложить удобного - autoptr (auto_ptr ?)
жесть! ты советуешь то, чем никогда не пользовался (ибо даже не знаешь как правильно пишется)
> если использовать в качестве массивов векторы, то, по сравнению с обычными массивами при хорошо написанной программе, скорость падает раза в 3
а вот это хит сезона! ты код вектора из стл-я какого-нибудь компилятора вообще смотрел когда-нибудь?
срочно иди ботай, чем отличается си от си++
> Максимум, что цепепе в данном случае может предложить удобного - autoptr (auto_ptr ?)
жесть! ты советуешь то, чем никогда не пользовался (ибо даже не знаешь как правильно пишется)
> если использовать в качестве массивов векторы, то, по сравнению с обычными массивами при хорошо написанной программе, скорость падает раза в 3
а вот это хит сезона! ты код вектора из стл-я какого-нибудь компилятора вообще смотрел когда-нибудь?
а вот это хит сезона! ты код вектора из стл-я какого-нибудь компилятора вообще смотрел когда-нибудь?Насколько я помню, автор пишет свои "крутые" массивы, т.к. не может эффективно использовать stl.
В любом случае, можно реализовать многомерные массивы через вектор, при этом, грамотно их используя, не особо потерять в производительности.
При этом в сравнении с сишными массивами, появится доп. приемущества.
При этом в сравнении с сишными массивами, появится доп. приемущества.
а вот это хит сезона! ты код вектора из стл-я какого-нибудь компилятора вообще смотрел когда-нибудь?
более того, я пытался его использовать как раз в вычислительной задаче
. В случае тупо написанного метода вращений скорость при использлвании вектора и сишного массива была одинаковой. При использовании блочного метода с одномерным вектором скорость была как раз в три раза ниже чем с сишным массивом (примерно 4.3 секунды у Си и > 15 секунд у вектора). Уверен, что в многомерном векторе получилась бы мегажесть.жесть! ты советуешь то, чем никогда не пользовался (ибо даже не знаешь как правильно пишется)
ну так я знаю про него только по книжке, чего мне его название запоминать?
срочно иди ботай, чем отличается си от си++
я знаю чем он отличается, поэтому и не советую его использовать для численных методов, смысла нет никакого.
В любом случае, можно реализовать многомерные массивы через вектор, при этом, грамотно их используя, не особо потерять в производительности.ну это просто лол, ты предлагаешь матрицу делать как
При этом в сравнении с сишными массивами, появится доп. приемущества.
std::vector<std::vector<double>>
?
Уахаха!
я знаю чем он отличается, поэтому и не советую его использовать для численных методов, смысла нет никакогоКак минимум ты не знаешь про шаблоны, на которых можно легко поднять производительность вычислительной задачи.
использовании блочного метода с одномерным вектором скорость была как раз в три раза ниже чем с сишным массивом (примерно 4.3 секунды у Си и > 15 секунд у вектора). Уверен, что в многомерном векторе получилась бы мегажесть
- Я не люблю кошек.
- Посто вы не умеете их готовить.
Обычный массив ничем не отличается от вектора. В случае, когда последний правильно используют.
std::vector<std::vector<double>>нет, я пробел добавлю между двумя последними символами
Насколько я помню, автор пишет свои "крутые" массивы, т.к. не может эффективно использовать stl.Во-первых, "свой крутой массив" в том алгоритме был лучше вектора (нужно было часто увеличивать вместимость, при этом никакой верхней оценки не было, размер мог становиться очень большим, частенько доходил до 100-120Мб).
Во-вторых, многие контейнеры из std довольно неэффективные. Например, стринги.
Ну а в-третьих, лучше бы я тогда изменил алгоритм, на самом деле, чтобы использовать вектор и не клеить велосипеды
> При использовании блочного метода с одномерным вектором скорость была как раз в три раза ниже чем с сишным массивом
Ты знаешь о том, что компилятор умеет оптимизировать код, а также умеет добавлять кучу ненужных (а иногда очень даже нужных) проверок для упрощения отладки прог? В соптимизированном коде скорость работы с одномерными векторами ничем не отличается от сишных массивов.
> я знаю чем он отличается, поэтому и не советую его использовать для численных методов, смысла нет никакого.
Я это вот к чему. Ты преспокойно можешь писать c-стайл код и компилировать его с++ компилятором. Только когда тебе захочется/понадобится использовать возможности с++, автоматически отпадет проблема переноса проги с с на с++. Не используешь шаблоны/ооп/исключения/ртти - нет оверхеда в производительности.
Ты знаешь о том, что компилятор умеет оптимизировать код, а также умеет добавлять кучу ненужных (а иногда очень даже нужных) проверок для упрощения отладки прог? В соптимизированном коде скорость работы с одномерными векторами ничем не отличается от сишных массивов.
> я знаю чем он отличается, поэтому и не советую его использовать для численных методов, смысла нет никакого.
Я это вот к чему. Ты преспокойно можешь писать c-стайл код и компилировать его с++ компилятором. Только когда тебе захочется/понадобится использовать возможности с++, автоматически отпадет проблема переноса проги с с на с++. Не используешь шаблоны/ооп/исключения/ртти - нет оверхеда в производительности.
я знаю чем он отличается, поэтому и не советую его использовать для численных методов, смысла нет никакогопопробуй Blitz++ хотя бы, прежде чем что-то советовать по данной теме
Ты знаешь о том, что компилятор умеет оптимизировать код, а также умеет добавлять кучу ненужных (а иногда очень даже нужных) проверок для упрощения
отладки прог? В соптимизированном коде скорость работы с одномерными векторами ничем не отличается от сишных массивов.
ну-ну, -O3 --ffast-math --march=....
Во-первых, "свой крутой массив" в том алгоритме был лучше вектораЯ видел этот код. Помнится, у тебя там было что-то вроде массива буферов. Мало того, я даже протестировал в сравнении с вектором. По моим тестам твой массив проиграл по всем параметрам.
Значит ты гонишь. С двумерными массивами - еще можно поверить, с одномерными оптимизатор сделает свое дело.
ну-ну, -O3 --ffast-math --march=....Давай поступим иначе. Напиши код, в котором вектор проигрывает обычному массиву. А то совсем не понятно, что ты имеешь ввиду.
попробуй Blitz++ хотя бы, прежде чем что-то советовать по данной темекак он по сравнению с линпаком?
я линпак буду советовать, не надо самому писать - это главное.
Я видел этот код. Помнится, у тебя там было что-то вроде массива буферов. Мало того, я даже протестировал в сравнении с вектором. По моим тестам твой массив проиграл по всем параметрам.в твоём тесте не было интенсивного неограниченного увеличения размера. А проигрывал он сильно только в произвольном случайном доступе - специально для этого я сделал реализацию через сбалансированное дерево.
Как минимум ты не знаешь про шаблоны, на которых можно легко поднять производительность вычислительной задачи.valarray штоле? ну нафек, между взбатыванием валаррея и взбатыванием уже готовой счётной библиотеки я всеми силами буду советовать второе.
valarray штоле?Нет, я говорю про слово template в коде Си++ и о том, как с его помощью писать производительный код. Мы уже давно не говорим об использовании готовых решений. Обсуждаем проблемы производительности Си++ vs Си.
Давай поступим иначе. Напиши код, в котором вектор проигрывает обычному массиву. А то совсем не понятно, что ты имеешь ввиду.Я обычный vector<vector<double> > и struct { int row, col; double* } и имею ввиду. В этом случае при блочном методе и происходило падение скорости. Использовать vector<double> уже не имело смысла, т.к. нужно хранить две размерности.
Я обычный vector<vector<double> > и struct { int row, col; double* } и имею ввиду. В этом случае при блочном методе и происходило падение скорости. Использовать vector<double> уже не имело смысла, т.к. нужно хранить две размерности.Напиши тест, начиная от функции main? А я перепишу так, чтобы векторы не проигрывали Си-шным массивам.
Ну так и чего, сишные массивы инкапсулировать? Это нужно? Я говорю, что почти всегда разницы в скорости между c++ и c решением в данной области почти не будет. Так же, как почти не будет разницы во времени разработки. А с понятностью, боюсь, проблемы будут как раз у c++ программ. Так что смысла в использовании c++ здесь нет, имхо.
Ну так и чего, сишные массивы инкапсулировать? Это нужно?Ты не понимаешь. Шаблоны - они гораздо интереснее.
Почитай про template expressions. Подумай про другие возможности шаблонов, типа compile-time вычислений.compile-time вычисленийво-во
Joe , почитай что-нибудь из статей, которые на сайте рядом с Blitz++ лежат: http://www.oonumerics.org/blitz/papers/
Почитал, судя по бенчмаркам фортран быстрее, значит, линпак быстрее. При этом, насколько я понимаю, эти либы, в отличии от c++-ных, можно использовать в любом языке, который понимает сишные либы, т.е. практически в любом. Ну а связка, скажем, руби+линпак, имхо, поудобнее будет чем чистый c++.
ну вот, например. Перемножение матриц.
ну вот, например. Перемножение матриц.Нет, это не то. Это код на Си, где, кроме прочего, куча неточностей, свойственных этому языку. И вообще при выходе из main, если это готовая программа, принято освобождать память.
Меня интересует твой бенчмарк, где ты используешь либо std::vector, либо Си-шный массив; и где у тебя получается так, что вектор работает медленнее.
свойственных этому языкувот ты фанатик, а в сиплюсплюс нет типа ни одной неточности ?
принято освобождать память.бугога, правда, отвык уже. Вот почему цепепе тоже отстой - надо вручную освобождать.
либо std::vector, либо Си-шный массив
как тут предлагал товарищ пропеллер, надо заменить в matrix_block double* на vector<vector<double>>, после чего наблюдать картину всоса
Перед тем, как что-нибудь использовать надо головой подумать.
Ты, как уже замечено, головой не думаешь, значит и будешь продолжать сосать как прежде.
Ты, как уже замечено, головой не думаешь, значит и будешь продолжать сосать как прежде.
вот ты фанатик, а в сиплюсплюс нет типа ни одной неточности ?Есть. Причём довольно много. Но в этой ветке настоящие проблемы этого языка не озвучены.
бугога, правда, отвык уже. Вот почему цепепе тоже отстой - надо вручную освобождать.В Си++ как раз вручную не надо.
как тут предлагал товарищ пропеллер, надо заменить в matrix_block double* на vector<vector<double>>, после чего наблюдать картину всосаВот я и прошу: напиши простой для понимания тест, где ты сравниваешь vector<double> и double* или какие ты хочешь. (Мягко говоря не ясно, как ты предлагаешь заменять double* на vector<vector<double>>) Строчек 20-100, иначе разбираться нет смысла.
Но в этой ветке настоящие проблемы этого языка не озвученыа ты этого хочешь ?
а ты этого хочешь ?Мне это как-то до лампочки. Просто устал слышать откровенные глупости, которые пропагандируют некоторые личности, не умеющие программировать. Те же заявления о проблемах с ресурсами от .
напиши простой для понимания теств "простом для понимания" разница вряд ли будет значительной. Она выявляется на блочных алгоритмах, в которых как раз, разница между кодом на С и С++ будет очень незначительной, и шаблоны здесь ничуть не помогут, они в данном случае не нужны.
в "простом для понимания" разница вряд ли будет значительной. Она выявляется на блочных алгоритмах, в которых как раз, разница между кодом на С и С++ будет очень незначительной, и шаблоны здесь ничуть не помогут, они в данном случае не нужны.Напиши простой блочный алгоритм. Вмести свои проблемы в короткий отрезок кода. Если ты не можешь этого сделать - это значит, что ты не понимаешь ни как работает код на Си++, ни как работает код на Си. Я могу помочь сделать производительную программу на Си++ и переубедить, но для этого мне нужно видеть, какую именно ошибку ты совершаешь.
Ну не знаю, мне это кажется маловероятным. Все же компилит gcc, а scanf берется из glibc. Ну это и не очень важно.http://www.ciselant.de/projects/gcc_printf/gcc_printf.html
правда это про printf, а scanf может он и не оптимизит
Мне довелось писать один вычислительный алгоритм (MSU Super Resolution) на С++ и С (Real Networks любит чистый С, понимаете ли). По скорости работы разницы не было. По скрорости и удобству разработки разница значительная. Например, на С++ шаблоны позволили один раз реализовать множество алгоритмов работы с изображением, и было не важно, из чего оно состоит - из байтов, из даблов или из троек-четверок байтов или даблов. При переписывании на С пришлось некоторые методы реализовывать по несколько раз для каждого типа изображения.
На D ещё лучше было бы 
И не знаю, как соотносится обработка изображений с традиционным представлением о вычислительных задачах.
И не знаю, как соотносится обработка изображений с традиционным представлением о вычислительных задачах.
При переписывании на С пришлось некоторые методы реализовывать по несколько раз для каждого типа изображения.Это препроцессором делается.
> И вообще при выходе из main, если это готовая программа,
> принято освобождать память.
Нафиг?
Кем, когда и где это принято?
Освобождением неразделяемой памяти занимается ОС,
большого смысла освобождать то, что и так окажется свободным,
нет.
---
SINT VT SVNT AVT NON SINT
> принято освобождать память.
Нафиг?
Кем, когда и где это принято?
Освобождением неразделяемой памяти занимается ОС,
большого смысла освобождать то, что и так окажется свободным,
нет.
---
SINT VT SVNT AVT NON SINT
Нафиг?могу привести как минимум две причины.
Кем, когда и где это принято?
Освобождением неразделяемой памяти занимается ОС,
большого смысла освобождать то, что и так окажется свободным,
нет.
1. Если в дальнейшем программа будет преобразована в библиотеку, освобождать ее все равно придется.
2. При отладке можно будет убедиться в отсутствии утечек памяти.
>> compile-time вычислений
> во-во
Очевидно, что идеальный оптимизатор должен произвести все
расчёты во время компиляции, только где при этом выигрыш
времени, если оптимизатор может работать медленнее, чем
неоптимизированная программа, пока неясно.
---
...Я работаю антинаучным аферистом...
> во-во
Очевидно, что идеальный оптимизатор должен произвести все
расчёты во время компиляции, только где при этом выигрыш
времени, если оптимизатор может работать медленнее, чем
неоптимизированная программа, пока неясно.
---
...Я работаю антинаучным аферистом...
> 1. Если в дальнейшем программа будет преобразована в библиотеку,
А если нет?
> освобождать ее все равно придется.
Даже при однократном использовании и быстром выходе.
> 2. При отладке можно будет убедиться в отсутствии утечек памяти.
Если они несущественны, то время, затрачиваемое на их устранение,
ничем не оправдывается.
---
...Я работаю антинаучным аферистом...
А если нет?
> освобождать ее все равно придется.
Даже при однократном использовании и быстром выходе.
> 2. При отладке можно будет убедиться в отсутствии утечек памяти.
Если они несущественны, то время, затрачиваемое на их устранение,
ничем не оправдывается.
---
...Я работаю антинаучным аферистом...
Даже при однократном использовании и быстром выходе.Библиотека на то и создается, что она не знает кто и как ее будет использовать. Утечка памяти в библиотеке — это уже серьезная уязвимость.
только где при этом выигрышВыигрыш берётся оттуда, что в большинстве случаев, на одну компиляцию приходится от десяти до бесконечности запусков. Один раз потратим час на оптимизацию, и засчёт этого сэкономим секунду при каждом запуске - уже выигрыш.
времени, если оптимизатор может работать медленнее, чем
неоптимизированная программа, пока неясно
> Я могу помочь сделать производительную программу на Си++ и переубедить,
> но для этого мне нужно видеть, какую именно ошибку ты совершаешь.
Раньше ты говорил вот это:
M> Напиши тест, начиная от функции main? А я перепишу так,
M> чтобы векторы не проигрывали Си-шным массивам.
Кроме того, если инструмент слишком сложен для использования,
то он просто не годится. Например, очевидно, что если правильно
использовать двоичный редактор, можно уделать и компилятор сей,
и компилятор приплюснутых сей. Только это надо уметь, но для
этого надо нехило много знать, причём сразу много. Кроме того ---
обладать, мягко говоря, не средними человеческими способностями.
---
...Я работаю антинаучным аферистом...
> но для этого мне нужно видеть, какую именно ошибку ты совершаешь.
Раньше ты говорил вот это:
M> Напиши тест, начиная от функции main? А я перепишу так,
M> чтобы векторы не проигрывали Си-шным массивам.
Кроме того, если инструмент слишком сложен для использования,
то он просто не годится. Например, очевидно, что если правильно
использовать двоичный редактор, можно уделать и компилятор сей,
и компилятор приплюснутых сей. Только это надо уметь, но для
этого надо нехило много знать, причём сразу много. Кроме того ---
обладать, мягко говоря, не средними человеческими способностями.
---
...Я работаю антинаучным аферистом...
> Библиотека на то и создается, что она не знает кто и как ее
> будет использовать.
Ой, насмешил!
И многие могут использовать Blitz++, не зная плюсов?
К BLAS, LAPACK и иже с ними хотя бы куча обёрток идёт,
почти ко всем языкам.
Не будем пока касаться случаев, когда библиотека создаётся
исключительно для внутреннего использования или просто из
технических удобств.
> Утечка памяти в библиотеке — это уже серьезная уязвимость.
Ну и каковы убытки при взломе? При неправильной работе?
У тебя на руках экспертная оценка риска?
Тогда числа на стол.
---
...Я работаю антинаучным аферистом...
> будет использовать.
Ой, насмешил!
И многие могут использовать Blitz++, не зная плюсов?
К BLAS, LAPACK и иже с ними хотя бы куча обёрток идёт,
почти ко всем языкам.
Не будем пока касаться случаев, когда библиотека создаётся
исключительно для внутреннего использования или просто из
технических удобств.
> Утечка памяти в библиотеке — это уже серьезная уязвимость.
Ну и каковы убытки при взломе? При неправильной работе?
У тебя на руках экспертная оценка риска?
Тогда числа на стол.
---
...Я работаю антинаучным аферистом...
>> только где при этом выигрыш времени, если оптимизатор может
>> работать медленнее, чем неоптимизированная программа, пока неясно
> Выигрыш берётся оттуда, что в большинстве случаев,
> на одну компиляцию приходится от десяти до бесконечности запусков.
Я не знаю никакого "большинства случаев", у нас вполне
определённый вопрос, с которым каждый может ознакомиться
на первой странице.
---
...Я работаю антинаучным аферистом...
>> работать медленнее, чем неоптимизированная программа, пока неясно
> Выигрыш берётся оттуда, что в большинстве случаев,
> на одну компиляцию приходится от десяти до бесконечности запусков.
Я не знаю никакого "большинства случаев", у нас вполне
определённый вопрос, с которым каждый может ознакомиться
на первой странице.
---
...Я работаю антинаучным аферистом...
Ну и каковы убытки при взломе? При неправильной работе?- Оценки убытков при взломе оцениваются не только исходя из степени "опасности" уязвимости, и даже стоимости взломанной вычислительной системы. Еще важно, например, знать ценность (или критичность) объекта автоматизации, скажем так.
У тебя на руках экспертная оценка риска?
- Прямое следствие утечки памяти в библиотеке, равно как и любой накапливающейся утечки памяти (в цикле, например) — приводит к отказу в обслуживании. Дальнейшее зависит от того где и при каких обстоятельствах отказ происходит.
Стоимость рассчитывается исходя из всех перечисленных параметров, кстати какие-то эвристические методики оценки рисков уже существуют, хотя я не буду утверждать, что они сильно хорошие.
Ну так числа у тебя есть готовые или нет?
Вопрос-то конкретный.
---
"Абстрактной истины нет."
Вопрос-то конкретный.
---
"Абстрактной истины нет."
Ну так числа у тебя есть готовые или нет?А ты мне задашь конкретные значения всех параметров — будут числа.
Вопрос-то конкретный.
Ну так числа у тебя есть готовые или нет?Ему п-ц будет, если он что раскроет.
А ты мне задашь конкретные значения всех параметров — будут числа.Ну ладно, так ещё можно. Но один раз.
у нас вполнеИменно поэтому я сказал "от десяти раз". Программа автора треда, скорее всего, около десяти раз и будет запущена; программы же, которые используются многими людьми, запускаться будут уже тысячи раз.
определённый вопрос, с которым каждый может ознакомиться
на первой странице.
Да на самом деле хоть миллионы.
Или ты стал писать сайты на высокооптимизированных сях?
---
...Я работаю антинаучным аферистом...
Или ты стал писать сайты на высокооптимизированных сях?
---
...Я работаю антинаучным аферистом...
Раньше ты говорил вот это:Я вижу мастер "придерусь хуй знает к чему, хотя сам нихуя не знаю" снова активировался... И как обычно, не в той теме, где он что-то соображает. Думаешь, мы забыли твои самые очевидные проёбы, где ты так и не сказал "да, ребята, я проебался, извините"? Про Ленина
, Паскаль, а также отмазки на scheme, которые ты назвал "рабочим кодом", и где я потом отловил ряд багов? Нет, не забыли. Можем напомнить ссылками. А ты определённо забыл, что тебе надо поботать что-нибудь про программирование, прежде чем писать в этот раздел.http://www.ciselant.de/projects/gcc_printf/gcc_printf.htmlВ любом случае в приведенной статье printf меняется только на puts/putchar. И все случаи тривиальны. Нет ни одного, где в форматной строке встретился бы вывод числа.
правда это про printf, а scanf может он и не оптимизит
И это правильно, так как вывод printf("%.2f", 3.1415926) может зависеть от LC_NUMERIC во время выполнения программы.
Рассмотрим такую задачу.
Есть массив каких-нибудь данных. Ну, это будут какие-нибудь простенькие структуры с 2-3 перемеными типа int или double, например. И нам надо этот массив несколько раз отсортировать по каким-нибудь простым (по временной сложности сравнения но запутанным критериям, вроде такого:
если старший бит первого int отличается у двух данных, то раньше должны идти данные, у которых он 0.
если старший бит первого int равен, и равен 0, то сортируем по возрастанию второго int,
а если равен 1, то по убыванию третьего int.
Ну, лили что-то такого рода. Таких способов сортировки у нас пара десятков, скажем.
Как решить задачу на C? Надо написать метод сортировки, которому в качестве параметра передавать указатель на нужную функцию, задающую порядок данных.
Как решить задачу на C++? Надо написать шаблонную функцию (или метод) сортировки, которому в качестве параметра шаблона передаётся класс, у которого есть inline-функция, задающая порядок данных.
Разнича, на первый взгляд не существенная. Но в случае С++ функция сортировки будет inline, и она при компиляции подставится в коде, съэкономив накладные расходы на вызов функции (сворацивание и разворачивание стека). Если метод сравнения достаточно простой, то эти накладные расходы будут занимать очень сущесвенную часть времени сортировки, и код на С++ может работать в несколько раз быстрее, чем код на С. Чтобы добиться на C того же результата надо тупо писать несколько десятков одинаковых методов сортировки.
Спасибо за внимание.
Есть массив каких-нибудь данных. Ну, это будут какие-нибудь простенькие структуры с 2-3 перемеными типа int или double, например. И нам надо этот массив несколько раз отсортировать по каким-нибудь простым (по временной сложности сравнения но запутанным критериям, вроде такого:
если старший бит первого int отличается у двух данных, то раньше должны идти данные, у которых он 0.
если старший бит первого int равен, и равен 0, то сортируем по возрастанию второго int,
а если равен 1, то по убыванию третьего int.
Ну, лили что-то такого рода. Таких способов сортировки у нас пара десятков, скажем.
Как решить задачу на C? Надо написать метод сортировки, которому в качестве параметра передавать указатель на нужную функцию, задающую порядок данных.
Как решить задачу на C++? Надо написать шаблонную функцию (или метод) сортировки, которому в качестве параметра шаблона передаётся класс, у которого есть inline-функция, задающая порядок данных.
Разнича, на первый взгляд не существенная. Но в случае С++ функция сортировки будет inline, и она при компиляции подставится в коде, съэкономив накладные расходы на вызов функции (сворацивание и разворачивание стека). Если метод сравнения достаточно простой, то эти накладные расходы будут занимать очень сущесвенную часть времени сортировки, и код на С++ может работать в несколько раз быстрее, чем код на С. Чтобы добиться на C того же результата надо тупо писать несколько десятков одинаковых методов сортировки.
Спасибо за внимание.
а помойму контра в этот раз прав
вы петушитесь как незнамо кто
а на деле ничего не можете
другой вопрос что все петушаться
видимо так принято
но это не мешает контре спросить: хули петушитесь?
вы петушитесь как незнамо кто
а на деле ничего не можете
другой вопрос что все петушаться
видимо так принято
но это не мешает контре спросить: хули петушитесь?
Микробенчмарка (автор: , я надеюсь он не против будет)
C++
gcc 4.1.2
Ключи (первый запуск был с -fprofile-generate)
Результаты: (время в секундах, среднее по нескольким последовательным запускам, размер файла ~256Mb)
Задача: считать несколько строчек из символов 'a'..'z' (по 1000 символов разделённые '\n', отсортировать, вывести.C
В сишном варианте для строк использовались char[1024] (*char[1024] для сортировки - sort(data, n, 1024, strcmp) , для ввода/вывода - printf/scanf. В приплюснутом — string (vector<string> шаблонный алгоритм sort (из STL >>/<< соответственно.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
typedef char str[1024];
int main
{
str *x = malloc(4096*sizeof(str;
int alloc=4096, i;
time_t t = clock t1;
for (i=0; scanf("%s", x[i])==1; i++)
if (i+1==alloc)
x = realloc(x, (alloc*=2)*sizeof(str;
t1 = clock;
fprintf(stderr, " read: %lld\n", (long longt1-t;
qsort(x, i, sizeof(str strcmp);
t = clock;
fprintf(stderr, " sort: %lld\n", (long longt-t1;
for (i--; i>=0; i--)
printf("%s\n", x[i]);
t1 = clock;
fprintf(stderr, "print: %lld\n", (long longt1-t;
free(x);
return 0;
}
C++
#include <iostream>
#include <string>
#include <ctime>
#include <vector>
int main
{
typedef std::vector<std::string> Vi;
Vi x;
int y;
std::string s;
std::ios_base::sync_with_stdio(0);
std::time_t t1, t = std::clock;
while (std::cin >> s)
x.push_back(s);
t1 = std::clock;
std::cerr << " read: " << t1-t << std::endl;
std::sort(x.begin x.end;
t = std::clock;
std::cerr << " sort: " << t-t1 << std::endl;
for (y = x.size-1; y>=0; y--)
std::cout << x[y] << std::endl;
t1 = std::clock;
std::cerr << "print: " << t1-t << std::endl;
return 0;
}
gcc 4.1.2
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
Ключи (первый запуск был с -fprofile-generate)
-W -Wall -Wextra -O3 -march=prescott -fprofile-use
Результаты: (время в секундах, среднее по нескольким последовательным запускам, размер файла ~256Mb)
C C++
read: 3.480 0.995
sort: 3.890 0.680
print: 0.260 0.260
в сишном варианте malloc и qsort все тормозят.
если массив размещать в стеке, в первой строчке результатов должно получиться меньше расхождение.
впрочем, на фоне тормозов qsort-а это будет незаметно.
если массив размещать в стеке, в первой строчке результатов должно получиться меньше расхождение.
впрочем, на фоне тормозов qsort-а это будет незаметно.
а помойму контра в этот раз правТы посты-то читаешь или нет?.. В чём он прав в ответе на мои сообщения? Простая придирка к словам и мозгоёбство. За это я его и посылаю куда подальше.
Как показала многолетняя практика, каждый, кто говорит "кохтпа прав" обычно просто не читает форум. Кохтпа бывает прав, но в разделе "Development" в 5% случаев, в 95% он просто ебёт всем мозг.
Ты посты-то читаешь или нет?.. В чём он прав в ответе на мои сообщения? Простая придирка к словам и мозгоёбство. За это я его и посылаю куда подальше.ну я сам с ним частенько не соглашаюсь
Как показала многолетняя практика, каждый, кто говорит "кохтпа прав" обычно просто не читает форум. Кохтпа бывает прав, но в разделе "Development" в 5% случаев, в 95% он просто ебёт всем мозг.
но тут он прав
числа ты фиг покажешь, но орать что так делать нельзя будешь, потому что все орут, а не потому что ты понимаешь что так делать нельзя
попросту петушиться
qsort понятно что тормозит, про это ещё выше писал, но вот malloc-то каким боком?
и как ты предлагаешь массив переменной длины размещать на стеке?
и как ты предлагаешь массив переменной длины размещать на стеке?
числа ты фиг покажешь, но орать что так делать нельзя будешь, потому что все орут, а не потому что ты понимаешь что так делать нельзяКакие числа? Давай подождём пока напишет либо краткий Си код, который он не может производительно перевести с double* на vector либо код, где у него получается, что vector медленнее. Затем, если я откажусь или не смогу переписать этот код, то буду не прав. А пока что мы ждём ответа от Си-шника.
В имеющемся примере с матрицами делать вообще нечего, я могу просто заменить double* на vector, malloc на ::resize, обход на итератор или double*. И код будет абсолютно эквивалентен, даже 5% производительности не убавится. Это ничего не покажет, потому что никто не будет копать такой огромный кусок кода.
сорри, я не заметил сходу, что он у тебя умеет расти. 
вставлю и свои пять копеек
на тему эффективных программ на С++ (в частности, и для математических вычислений) может кому-нибудь будет интересна/полезна книга "Efficient C++ Performance Programming Techniques" товарищей Dov Bulka и David Mayhew (например, тут http://lib.mexmat.ru/books/3918, ну и в инете много где лежит)
Там про то, что на C++ вполне можно писать эффективные (по быстродействию) программы.
Ну и обоих Мейерсов (Effective... и More Effeсtive...) тоже можно посоветовать; там кое что на тему эффективности есть.
на тему эффективных программ на С++ (в частности, и для математических вычислений) может кому-нибудь будет интересна/полезна книга "Efficient C++ Performance Programming Techniques" товарищей Dov Bulka и David Mayhew (например, тут http://lib.mexmat.ru/books/3918, ну и в инете много где лежит)
Там про то, что на C++ вполне можно писать эффективные (по быстродействию) программы.
Ну и обоих Мейерсов (Effective... и More Effeсtive...) тоже можно посоветовать; там кое что на тему эффективности есть.
Или ты стал писать сайты на высокооптимизированных сях?А какое это имеет отношение к разговору?
Повторяю ещё раз - гораздо выгоднее, если компилятор (машина, а не человек!) один раз всё соптимизирует, чтобы потом запросы выполнялись быстрее.
На тех же сайтах обычно (если они написаны на каком-нибудь php) кэшируется байт-код, правда, это немного не в тему, потому что такая однократная компиляция занимает ровно столько же времени, сколько и компиляция перед каждым запуском. Но тем не менее, если бы каждая компиляция для кэша была в сто раз медленнее - ей бы всё равно пользовались.
> Это препроцессором делается.
Подскажи, пожалуйста, как препроцессором сделать так, чтобы код
A = B*k + (C-D)*(1-k);
будучи написан единожды, работал бы с байтами, даблами и тройками байтов и даблов.
Подскажи, пожалуйста, как препроцессором сделать так, чтобы код
A = B*k + (C-D)*(1-k);
будучи написан единожды, работал бы с байтами, даблами и тройками байтов и даблов.
Подскажи, пожалуйста, как препроцессором сделать так, чтобы код
A = B*k + (C-D)*(1-k);
будучи написан единожды, работал бы с байтами, даблами и тройками байтов и даблов.
Это ты уже о перегрузке операций говоришь, а не о шаблонах. На C придётся, видимо, использовать бинарные операции в префиксной записи.
Да, перегрузка используется, но именно благодаря шаблонам достаточно описать это выражение единожды.
Реально код содержал выражения типа
GT t = (pData[si]+pData[si+1])*9 - pData[si-1] - pData[si+2] +8)>>4;
(полупиксельный сдвиг бикубиком где GT - параметр шаблона.
Если это int, то получается обычная операция с целыми числами. А когда в качестве GT подставлялся мой класс для работы с RGB с определенными в нем нужными операциями (тоже шаблонный - для разных типов компонентов то получалось уже нечто посложнее.
На макросах это было бы не слишком удобно.
Реально код содержал выражения типа
GT t = (pData[si]+pData[si+1])*9 - pData[si-1] - pData[si+2] +8)>>4;
(полупиксельный сдвиг бикубиком где GT - параметр шаблона.
Если это int, то получается обычная операция с целыми числами. А когда в качестве GT подставлялся мой класс для работы с RGB с определенными в нем нужными операциями (тоже шаблонный - для разных типов компонентов то получалось уже нечто посложнее.
На макросах это было бы не слишком удобно.
> На макросах это было бы не слишком удобно.
Слишком удобно не бывает, но писать всё по 4 раза всё-таки незачем.
Слишком удобно не бывает, но писать всё по 4 раза всё-таки незачем.
Если макрос получается маленький, то согласен. Но сопровождать макрос в сотню-другую строк все-таки напряжнее, чем 4 функции с почти одинаковым кодом.
> Но сопровождать макрос в сотню-другую строк все-таки напряжнее,
А чем он отличается от шаблона функции с таким же количеством строк?
А чем он отличается от шаблона функции с таким же количеством строк?
Ну, например, тем, что ни компилятор, ни отладчик не скажут тебе конкретно, в какой из этой сотни строк макроса ошибка.
Оставить комментарий
NataNata
мне нужно написать вычислительную прогу. считать будет много. нужно писать с нуля. придется использовать много объектов типа матриц и т.д. насколько, в принципе, будет различаться скорость работы, к примеру, с матрицами, реализованными в виде класса и скорость работы с матрицами, работа с которыми реализована процедурами в стиле обычного си?если у кого был подобный опыт сравнения - напишите плз