» Самый перспективный язык программирования

Цитата:

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

Цитата:

Цитата: по секциям исполняемого модуля

это еще зачем? речь идёт об оптимизации узких мест а не всего модуля в целом.

Цитата:

Проверять-то нужно поглобальней, чем просто тот кусочек, который "патчится".

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

Цитата:

Да и не все критичные факторы я перечислил. Есть ещё предсказание ветвлений, переупорядочивание подвыражений, подмена элементарных операций, оптимизация нагрузки на двухканальную шину... Что-то ещё наверняка есть, чего я не знаю.

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

Цитата:

В общем, "из спортивного интереса" я б с ним соревноваться не стал.

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


Цитата:

Мда, с товарищем уже даже спорить не хочется, так как убедить хотя бы призадуматься невозможно в принципе...

О чём призадуматься? О том что Java быстро «ездит», как вы говорили? Я вам даже пример независимого тестирования привёл, на котором видно, что Java в несколько раз медленне C++, неговоря уже о десякратном требовании к оперативной памяти. Если вдруг в системе станет нехватать памяти при работе несольких программ, то падение производительности будет куда существенней, чем при нехватки ресурсов процессора.


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

Добавлено:
Хочу процитировать Boris Kolar:
Цитата:

My advice: use the best or the most popular language for the platform.
Don't bother with "slightly better but less popular" category. So, if
you target .NET, use C# (most popular) or Boo/Nemerle (best), don't
bother with VB.NET, J# and others.

If you target JVM, use Java (also take a look at Scala - I don't like
it too much because it seems more complex than necessary).

If you must have fast startup times, or must integrate with OS API, use
C++ (most popular) or D (best). Maybe Eiffel is also worth considering.
D is not (yet) very good for real-time programming (see all garbage
collection, deterministic finalization threads for reasons), but Walter
will likely fix that soon.

I personally use D for OS-integrated projects and Java for all others.
If Boo for JVM (or native) existed, I would definitely use Boo (I'm almost
tempted to write JVM port of Boo myself).

в переводе, если вы выбираете язык под конкретную платфору, то берите либо самый популярный язык, либо же самый оптимальный, если вам нужен быстрый запуск программы, то следует отказаться от Java или .NET

Добавлено:
В качестве самого перспективного языка программирования я считаю D
Цитата:

Gregor Richards has found a way to compile D code to JVM compatible
programs, that can be run in a JVM. So, if this is taken a bit further,
maybe we can even say "D runs in a VM, too, if you want".

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

Добавлено:
http://www.codu.org/nestedvm-gdc/

Quark Fusion
Как говорят в Черноморске "Kolar конечно голова", но не может являться истинной в последней инстанции, тем более Ваш перевод более чем волен.

перевод был в форме обобщения — видно же, что в оригинале слов намного больше

Quark Fusion
Я сам умею читать по английски, перевод воистину оригинален =))) Ладно, я сам попробую некоторое тестирование производительности провести. Если сделаю, то результат предоставлю.

ну не «в переводе», а «обобщая» — просто я когда писал передумал переводить

Quark Fusion
Думаю результаты тестирования предоставлю нескоро, так как хочу хорошенько разобраться, и поиздеваться над большими числами. Потестирую пока только вычисления с большими числами... Сравню Java и C++. Самому интересны результаты =) Потом может продолжим тестирование и в других областях, если кому-то интересно. Сравнивать буду только скорость выполнения, занимаемая память меня мало волнует, так как не для КПК ведь пишу, и не для всяких микрочипов встроенных в бытовую аппаратуру %)

Цитата:

занимаемая память меня мало волнует

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

Добавлено:
кстати, попробуйте откомпилировать программу на С++ компилятором от Intel или GCC 4.1 — скорость может вырасти, а программу на Java надо протестировать на серверной VM и на десктопной

"Движенья нет!" - сказал мудрец брадатый.
Другой смолчал и стал пред ним ходить.
Сильнее он не смог бы возразить.
Хвалили все ответ замысловатый.
© Пушкин, вроде. А спорим на шаблонах выражений в C++ я одной левой любой ассемблерный алгоритм сделаю? Пусть потом докручивают перспективный D сколько угодно.

А в D есть mixins и ассемблерные вставки тоже, и что значит «сделаете»? по скорости выполнения?

Цитата:

... и что значит «сделаете»? по скорости выполнения?

Ну да. Мне компилятор в процессе компиляции сам будет "строить" наиболее эффективный цикл независимо от сложности выражения. D так умеет? Или ассемблер? Впрочем, на ассемблере можно самомодифицирующийся код навернуть, но по сложности патчить исполняемый код никак не конкурент шаблонному метапрограммированию.

с точки зрения компилятора цикл будет наиболее эффективен
А вообщее в D один из самых лучших компиляторов, автор языка как раз их разработкой и занимается, причём уже довольно давно.


Добавлено:
Кстати сам язык разрабатывается еще и с точки зрения возможности оптимизации компилятором, поэтому там оптимизируется почти что всё, что можно оптимизировать
Но алгортим программы он за вас, конечно же, кардинально не перепишет — если есть другой, более эффективный способ решить задачу, то лучше воспользоваться им, а компилятор уже позаботиться, чтобы этот код хорошо работал.

Quark Fusion
Ты откуда эти тупые графики берёшь? Что там тестируется? Простые столбики без комментариев ни о чём не говорят, мало ли чего там сравнивали.

я же линк на них вешаю — незаметно, чтоли? там всё расписано и даже исходные коды программ есть.

Добавлено:
или надо внизу подписывать «щёлкните на картинку для получения подробностей»?

Quark Fusion
А я те чё, картинки щупаю чтоль??? Тыб сцылку снизу указал, и то бы заметнее было!!!

XDiaBLo, мог бы хотя бы для приличия попробовать или посмотреть откуда картинка грузится, прежде чем говорить о «тупых» графиках… а еще полезно поискать в сети сравнения и понять разницу между bytecode и native, прежде чем утверждать, что Java такая быстрая, просто «медленно запрягает».

Аналитика: Рынок средств разработки в 2006 году
http://www.interface.ru/home.asp?artId=3149

Quark Fusion
Я знаю разницу между байткодом и родным кодом. А на C++ я бы всё равно не стал приложения связанные с бизнес-логикой писать. А то что Ява быстрей чем ПХП я уже проверял. Руби говорят вообще тормоз...

статья в основном о рынке, средах разработки и платформах, а не о языках программирования, технологии упоминаются лишь вскользь
для примера под Visual Studio можно программировать на разных языках, даже на PHP, тоже можно сказать и о Eclipse

в статье больше всего понравилась фраза «сделали AJAX достоянием гласности» — а раньше кто мешал его изобрести и использовать? технологии уже были, просто у веб-программистов было недостаточно навыков.

Добавлено:

Цитата:

А то что Ява быстрей чем ПХП я уже проверял.

PHP вроде вообще скриптовый язык — естественно, что он медленне, тут даже проверять нечего. И это не делает яву быстрее компилируемых языков. Или вы считаете что PHP и С++ языки из одной категории?

Цитата:

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

А кардинально и не надо. Достаточно объяснить компилятору, как должен выглядеть оптимальный цикл, т.е. снабдить его способом построения такого цикла для произвольного выражения. Это и будет метаалгоритмом. Когда он его выполнит при компиляции, т.е. наинстанцирует шаблонов, дальше начнётся обычная оптимизация.
Плюсовые шаблоны обладают качеством алгоритмической полноты. Это означает, что теоретически на этапе компиляции можно выполнить любой алгоритм. Мало кто это осознаёт. Поэтому когда я слышу, что кто-то говорит, будто бы он профессионал в плюсах, но "не любит" (термины могут отличаться) шаблоны, так и хочется заметить, что этот товарищ не знают плюсов, а знает C с объектами.

P.S. Кстати, первая в мире метапрограмма искала простые числа. Её даже не надо было запускать, только откомпилировать, т.к. найденные простые числа выводились в виде ошибок компиляции, в формулировках которых они присутствовали. Что-то типа
Код: error: incomplete type is not allowed: prime<2> x;
error: incomplete type is not allowed: prime<3> x;
error: incomplete type is not allowed: prime<5> x;
...

Цитата:

т.е. снабдить его способом построения такого цикла для произвольного выражения

одно дело оптимизировать выражения, и совсем другое — алгоритмы, к тому же, если вы в выражении вызываете кучу функций почём зря, то компилятор не сможет это определить и ваше выражение будет выполняться на порядок медленнее, чем могло бы, если бы вы заметили, что функции всегда выдают один и тот же результат.
тривиальный пример: isqrt(power2(x)), где isrqt(x) — «{uint a; for (a=0;x>=(2*a)+1;x-=(2*a++)+1); return a;}», а power2(x) — рассчёт квадрата по таблице.
нетривиальный — это реализация алгоритма для рассчёта выражения , где число квадратных корней передаётся функции — компилятор вряд ли сможет додуматься до того, что это число и есть результат выражения.

Добавлено:
нельзя взваливать оптимизацию алгоритма на компилятор — его задача это оптимизация кода, а поиск и реализация оптимального алгортима — задача программиста

Quark Fusion

Цитата:

Или вы считаете что PHP и С++ языки из одной категории?

Сейчас век интернета, и я думаю перспективнее языки направленные на интернет приложения. Поэтому я и смотрю с той точки зрения. И PHP я вообще-то не с С++ сравнивал, раскрой глаза пошире!

Гм... Ты вообще не понял, а чём это я. Алгоритм в частности может описывать метод построения другого алгоритма. Например, описание метода математической индукции - это алгоритм, но сам метод математической индукции - это тоже алгоритм. Чтобы ты не сомневался в потенциале шаблонного метапрограммирования, [more=вот]/***************************************************************************\
|************** Решение квадратного уравнения в **************|
|******************** во время компиляции ********************|
\***************************************************************************/

#include <iostream>
#include <limits>
#include <cmath>
#include <cstddef>

#ifdef SHOW_DEBUG_INFO
/*
Отладочный шаблон для вывода значения I типа T в виде сообщения компилятора
об ошибке, в котором присутствует значение I.
Вложенный шаблон используется для более лёгкого нахождения требуемых данных
в тексте сообщения. Так значение I должно быть выведено в самом начале,
в противном случае оно будет закопано в глубине многострочного сообщения.
По крайней так происходит с Intel C++ Compiler-ом. Впрочем, в связи с тем,
стандарт не определяет - даже формально - форматы текстов об ошибках, нет
никакой гарантии, что информация будет читабельной. Например, Visual C++ 7.1
вообще выводит значение I в hex.
Значение выводится в compile-time, да ещё и в виде текста об ошибке, поэтому
при этом компиляция закончится неудачей.
*/
template <typename T, T I>
class outT
{
template <typename valueT, valueT J> struct OUTPUT;

public:
OUTPUT<T, I> _dummy;
};
#endif

// Шаблон класса - делителя двух чисел с математическим округлением
template <typename T, T X, T Y>
class Div
{
static const T quot=X/Y, // частное
part=quot-(quot<0 && X!=quot*Y),// поправка для отрицательных
Z1 =part*Y, // точность с недостатком
Z2 =(part+1)*Y; // точность с избытком

public:
static const T value=X-Z1 > Z2-X ? part+1 : // выбрать лучшее
X-Z1 !=Z2-X ? part :
part%2 == 0 ? part : part+1; // чётное
};

/*
К сожалению, форматы с плавающей точкой в качестве аргументов
шаблонов не разрешаются. Поэтому будет использоваться формат
с фиксированной точкой. Даже long на 32-битных платформах черезчур
мал для достаточной точности, поэтому тип аргументов параметризируется.
По это причине в классах вместо enum используются static const.
*/

// Параметры: тип аргументов, коэффициенты и количество разрядов
// в дробной части (по умолчанию - точность float)
template <
typename T,
T Ax2, T Bx, T C,
int Frac=6
>
class Qwur
{
// Вычисление корней по коэффициентам при неизвестном, дискриминанте и
// поправочном множителе вида std::pow(10, Frac)
template <
typename valueT,
valueT A, valueT B, valueT Discr,
valueT Pow
>
class Roots
{
/*
По хорошему нужна ещё специализация для нуля, но так как здесь она
не используется, то я её и не определил.
*/
// Вычисление квадратного корня методом Ньютона.
// Параметры: подкоренное значение и поправочный множитель.
template <
typename valueT1,
valueT1 X0,
valueT1 Pow1
>
class Sqrt
{
// Итерации по Ньютону (объявление).
// Параметры: подкоренное значение, очередное приближение
// и поправочный множитель.
template <
typename valueT2,
valueT2 X, valueT2 Xn,
valueT2 Pow2
>
struct Iterate;
// Выбор между продолжением итераций и их завершением.
// Параметры: подкоренное значение, предыдущее и очередное приближения,
// поправочный множитель и признак перехода итерации через точное значение.
// Последний параметр важен для частичной специализации.
template <
typename valueT2,
valueT2 X, valueT2 Xpred, valueT2 XN,
valueT2 Pow2,
bool Gt
>
struct Compare
{
static const valueT2 value=Iterate<valueT2, X, XN, Pow2>::value;
};
// Специализация для окончания рекурсии.
template <
typename valueT2,
valueT2 X, valueT2 XN,
valueT2 Pow2
>
struct Compare<valueT2, X, XN, XN, Pow2, false>
{ // Округление аналогично Div<>
static const valueT2 value=X-XN*XN > (XN+1)*(XN+1)-X ? XN+1 :
X-XN*XN !=(XN+1)*(XN+1)-X ? XN :
XN%2 ==0 ? XN : XN+1;
};
// Специализация для предотвращения бесконечной рекурсии в случае, если две
// (а может и больше) итерации начинают чередоваться.
// В целочисленной арифметике это нередкий случай.
template <
typename valueT2,
valueT2 X, valueT2 Xpred, valueT2 XN,
valueT2 Pow2
>
struct Compare<valueT2, X, Xpred, XN, Pow2, false>
{ // Округление аналогично Div<>, но...
static const valueT2 value=X-Xpred*Xpred > XN*XN-X ? XN :
X-Xpred*Xpred !=XN*XN-X ? Xpred :
// ... учитывая, что Xpred и XN могут отличаться более чем на 1,
// берём их среднее. Если всё же ровно на 1, то оно уже будет
// округлено до чётного, иначе - не факт.
Div<valueT2, XN+Xpred, 2>::value%2 == 0 ?
Div<valueT2, XN+Xpred, 2>::value : Div<valueT2, XN+Xpred, 2>::value+1;
};

// Итерации по Ньютону (определение).
template <
typename valueT2,
valueT2 X, valueT2 Xn,
valueT2 Pow2
>
struct Iterate // X = /X +A/X \ / новое
{ // n+1 \ n / n/ / 2 приближение
static const valueT2 Xnext=Div<valueT2, Xn+Div<valueT2, X*Pow2, Xn>::value, 2>::value;

public: // Определиться с окончанием/продолжением итераций
static const valueT2 value=Compare<valueT2, X, Xn, Xnext, Pow2, (Xn > Xnext)>::value;
};

public:
// Запустить итерации. Начальное приближение - подкоренное значение.
static const valueT1 value=Iterate<valueT1, X0, X0, Pow1>::value;
};

// Шаблон вычисления sign(x)
template <typename valueT1, valueT1 X>
struct Sign
{
static const valueT1 value = X<0 ? -1 : X==0 ? 0 : +1;
};

// Объявление шаблона выбора алгоритма вычисления корней
// в зависимости от знака дискриминанта.
// Параметры: коэффициенты при неизвестном, дискриминант,
// поправочный множитель и знак дискриминанта.
template <
typename valueT1,
valueT1 A, valueT1 B, valueT1 D,
valueT1 P,
int
>
struct Select;
// Специализация для отрицательного дискриминанта
template <
typename valueT1,
valueT1 A, valueT1 B, valueT1 D,
valueT1 P
>
class Select<valueT1, A, B, D, P, -1>
{
static const valueT1 sqrtD=Sqrt<valueT1, -D, P>::value;

public:
static const valueT1 x1Re =Div<valueT1, -B*P , 2*A>::value,
x2Re =x1Re ,
x2Im =Div<valueT1, sqrtD*P, 2*A>::value,
x1Im =-x2Im;
#ifdef SHOW_DEBUG_INFO
outT<valueT, D> _dummy1;
outT<valueT, sqrtD> _dummy2;
#endif
};
// Специализация для нулевого дискриминанта (не обязательна, но с ней проще)
template <
typename valueT1,
valueT1 A, valueT1 B, valueT1 D,
valueT1 P
>
struct Select<valueT1, A, B, D, P, 0>
{
static const valueT1 x1Re =Div<valueT1, -B*P, 2*A>::value,
x2Re =x1Re ,
x1Im =0 ,
x2Im =0;
#ifdef SHOW_DEBUG_INFO
outT<valueT, D> _dummy1;
#endif
};
// Специализация для положительного дискриминанта
template <
typename valueT1,
valueT1 A, valueT1 B, valueT1 D,
valueT1 P
>
class Select<valueT1, A, B, D, P, +1>
{
static const valueT1 sqrtD=Sqrt<valueT1, D, P>::value;

public:
static const valueT1 x1Re =Div<valueT1, (-B-sqrtD)*P, 2*A>::value,
x2Re =Div<valueT1, (-B+sqrtD)*P, 2*A>::value,
x1Im =0 ,
x2Im =0;
#ifdef SHOW_DEBUG_INFO
outT<valueT, D> _dummy1;
outT<valueT, sqrtD> _dummy2;
#endif
};

// Получить результаты и вытащить наружу
public:
static const valueT
x1Re=Select<valueT, A, B, Discr, Pow, Sign<valueT, Discr>::value>::x1Re,
x2Re=Select<valueT, A, B, Discr, Pow, Sign<valueT, Discr>::value>::x2Re,
x1Im=Select<valueT, A, B, Discr, Pow, Sign<valueT, Discr>::value>::x1Im,
x2Im=Select<valueT, A, B, Discr, Pow, Sign<valueT, Discr>::value>::x2Im;
};

// Вычисление целой степени десяти для преобразования количества дробных
// разрядов в значении с фиксированной точкой в поправочный множитель
template <T I> struct Pow10 { static const T value = Pow10<I-1>::value * 10; };
template <> struct Pow10<0>{ static const T value = 1; };

// Вычисление дискриминанта
template <
typename valueT,
valueT A, valueT B, valueT C,
valueT Pow
>
struct Discr
{
static const valueT value=Div<valueT, B*B-4*A*C, Pow>::value;
};

static const T pow =Pow10<Frac>::value; // поправочный множитель
static const T discr=Discr<T, Ax2, Bx, C, pow>::value;// дискриминант

public:
// Найти корни и вытащить наружу - x1=a1+i*b1, x2=a2+i*b2
static const T x1Re=Roots<T, Ax2, Bx, discr, pow>::x1Re, // a1
x2Re=Roots<T, Ax2, Bx, discr, pow>::x2Re, // a2
x1Im=Roots<T, Ax2, Bx, discr, pow>::x1Im, // b1
x2Im=Roots<T, Ax2, Bx, discr, pow>::x2Im; // b2
};

/*
Для тестирования правильности работы шаблона Qwur<> проверяем результаты
вычислениями в run-time и с плавающей точкой
*/

// Простой манипулятор для вывода табуляции
template <typename Ch, class Tr>
std::basic_ostream<Ch, Tr>& tab(std::basic_ostream<Ch, Tr>& os)
{
// static const Ch tabSymbol=os.widen('\t');
// return os.width(10)<<tabSymbol;
os.width(10);
return os;
}

// Получить коэффициенты и вернуть составные части комплексных корней
void qwur(float a, float b, float c, float& x1re, float& x1im, float& x2re, float& x2im)
{
float d=b*b-4*a*c;

// Отладочный вывод дискриминанта и квадратного корня его модуля
std::cout<<"d="<<d<<'\t'<<"sqrt(|d|)="<<std::sqrt(abs(d))<<std::endl;

// Разумная погрешность при сравнении на равенство (после трёх умножений)
if(std::abs(d) < std::numeric_limits<float>::epsilon()*3)
{
x1re=x2re=-b/(2*a);
x1im=x2im=0;
}
else if(d<0)
{
x1re=x2re=-b/(2*a);
x1im=-(x2im=-std::sqrt(-d)/(2*a));
}
else
{
x1re=(-b-sqrt(d))/(2*a);
x2re=(-b+sqrt(d))/(2*a);
x1im=x2im=0;
}
}

// Шаблон для итерирования по количеству разрядов в дробной части
// значений с фиксированной точкой.
// В связи с невозможностью (запрещено стандартом) шаблонам функций иметь
// частичные специализации итерирации выполняются перегруженным operator()
// в шаблоне класса.
// В тесте не будем параметризировать тип параметров
template <__int64 a, __int64 b, __int64 c, int step>
class testOut
{
static const Qwur<__int64, a, b, c, step> qw;

public:
void operator()() const
{
std::cout<<tab<<qw.x1Re<<tab<<qw.x2Re<<tab<<qw.x1Im<<tab<<qw.x2Im<<std::endl;
testOut<a*10, b*10, c*10, step+1>()(); // Следующая точность
}
};
// Специализация теста для остановки рекурсии.
// Точность в семь знаков является по факту предельной для __int64.
// Однако и точность float неплоха для фиксированной точки в compile-time
template <__int64 a, __int64 b, __int64 c>
struct testOut<a, b, c, 7>
{
void operator()() const {}
};

int main()
{
float x1re, x1im, x2re, x2im;

testOut<7, 70, 175, 0>()();// Нулевой дискриминант
qwur (7, 70, 175, x1re, x1im, x2re, x2im);
std::cout<<tab<<x1re<<tab<<x2re<<tab<<x1im<<tab<<x2im<<std::endl<<std::endl;

testOut<7, 28,-315, 0>()();// Положительный дискриминант
qwur (7, 28, -315, x1re, x1im, x2re, x2im);
std::cout<<tab<<x1re<<tab<<x2re<<tab<<x1im<<tab<<x2im<<std::endl<<std::endl;

testOut<4, 16, 180, 0>()();// Отрицательный дискриминант
qwur (4, 16, 180, x1re, x1im, x2re, x2im);
std::cout<<tab<<x1re<<tab<<x2re<<tab<<x1im<<tab<<x2im<<std::endl<<std::endl;

testOut<1, 1, -1, 0>()(); // "Золотое сечение" (под корнем не полный квадрат)
qwur (1, 1, -1, x1re, x1im, x2re, x2im);
std::cout<<tab<<x1re<<tab<<x2re<<tab<<x1im<<tab<<x2im<<std::endl<<std::endl;
/*
К слову сказать, без реализации математического округления результат
последнего выводимого compile-time const отличался от run-time computable
*/
}[/more]тебе для примера. Там тебе в частности и реализация твоей isqrt() в частности. Если у меня получилось так, что мне в программе потребуется решить квадратное уравнение, но при этом его коэффициенты являются константами, то из трёх вариантов - решить в run-time, решить на бумажке и подставить в программу результаты (фиии!), решить в compile-time - я предпочту последнее. Особенно, если их будет не одно. И тем более, если в ТЗ от версии к версии меняются их коэффициенты.
Заметь, выражение - это тоже константная сущность. Как в программу вобъёшь, так оно и откомпилится (калькуляторы не рассматриваем - это отдельная тема и для скриптовых языков куда как более подходящая). Если я снабжу компилятор метаалгоритмом построения оптимального цикла по этому выражению... в общем теперь ты понял, я надеюсь. Пусть работает компилятор, а не я.

P.S. К слову сказать, напомнило. Как-то на работе коллега пришёл и задал всем задачку: написать числа от 1 до 10 четырьмя четвёрками и математическими операциями. Оказывается его дочери (в смысле всему классу) её в школе задали. У них возникли сложности с 10. Ну, не догнали они, что четвёрки можно и вместе написать, без операций: (44-4)/4. Когда я ради смеха предложил ещё вариант (4!-4)/pow(4, 1/sqrt(4)) (надеюсь, смог передать исходную форму выражения), то у него случился припадок, а когда ещё добавил твою (кстати, я её впервые увидел у Перельмана в "Занимательной алгебре") слегка видоизменённую формулу с пирамидой корней (только там их было двенадцать, под самим нижним - произведение двух четвёрок, а основания логарифмов тоже были записаны как квадратные корни из четвёрок - он сказал, что его дочь обязательно принесёт в школу именно это решение. Потом рассказывал, в каком шоке был учитель.

Qraizer, если вы имели ввиду решение выражения типа sqrt(4) или поиск корней заданного! уравнения во время компиляции, то это никак не относится к оптимизации выражения от X или решения произвольного уравнения, где коэффициенты — переменные.
кто мешает в программе определить константу, значение которой она сама и рассчитывает? не все языки, конечно, способны откомпилировать код и запустить его на рассчёт выражения, а уже потом слинковать его с результатами. Не проверял лично, есть ли такие вообще. Потому как компилятор может и не определить есть ли какие-либо внешние последствия у вызываемого кода или нет, особенно когда в нём используются внешние библиотеки.

Цитата:

Если у меня получилось так, что мне в программе потребуется решить квадратное уравнение, но при этом его коэффициенты являются константами, то из трёх вариантов - решить в run-time, решить на бумажке и подставить в программу результаты (фиии!), решить в compile-time - я предпочту последнее.

а как насчёт варианта «решить в run-time и подставить в программу», почему обязательно на бумажке считать? К тому же очень малую часть можно реализовать на этапе компиляции.

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

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


Цитата:

Заметь, выражение - это тоже константная сущность. Как в программу вобъёшь, так оно и откомпилится (калькуляторы не рассматриваем

однако нас интересует результат выражения и причём тут калькуляторы? разве eval(x) сильно отличается от function(x)?

Добавлено:

Цитата:

Чтобы ты не сомневался в потенциале шаблонного метапрограммирования

В пользе шаблонов никто и не сомневается, вот только назначение их не в рассчёте чего-либо при компиляции, а в автоматической генерации кода.


Цитата:

Потом рассказывал, в каком шоке был учитель.

оффтопик: гы-гы-гы дочка в школе: «а у меня папа — математик! »




Добавлено:

Цитата:

И PHP я вообще-то не с С++ сравнивал, раскрой глаза пошире!

XDiaBLo, вы просто сначала высказались, что Java быстрее C++, а потом что вы проверяли как она быстрее PHP, вроде как в подтверждение того, что она самая быстрая (байткод против компиляции), сложилось впечатление, что вы разделили языки на «Java» и «не-Java»

Цитата:

Сейчас век интернета, и я думаю перспективнее языки направленные на интернет приложения.

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

Кстати, с точки зрения интернет-приложений перспективен ActionScript 3.0 (Flash9, Flex) в связке с другим языком (проще всего с Java). Т.к. Java VM автоматически клиенту не устанавливается.

Добавлено:
P.S. тема назыыается «Самый перспективный язык программирования», а не язык для интернет-приложений

Quark Fusion
Не разговаривай пожалуйста как с ребёнком, я знаю что я говорил. Я говорил что Ява бывает быстрее чем С++, но млин, ладно, забудем про это. А что самая быстрая я не утверждал!!! Я сам пишу в основном на С++, и немного на Яве, и ещё иногда на С#, а так, могу на чём угодно. Не разделяю мир на Ява и не-Ява. И предпочитаю не разговаривать с теми, кто коверкает мои слова.
А писать я понимаю что интернет-приложения можно на чём угодно, только вот C++ не самый подходящий язык для этого.
А насчёт названия темы, так я повторяю ещё раз, для непонимающих: "Сейчас век интернета, и я думаю перспективнее языки направленные на интернет приложения."

Добавлено:
Quark Fusion
Да, а что Ява бывает быстрее С++ я говорил не на собственном опыте основываясь. И про медлительность сборщика мусора опять же могу дать ссылку почитать, что он по производительности сравнителен с менеджером памяти(или как там его) в С++.

Цитата:

А что самая быстрая я не утверждал!!! … Не разделяю мир на Ява и не-Ява. И предпочитаю не разговаривать с теми, кто коверкает мои слова.

я и не коверкал, лишь сказал что косвенно сложилось впечатление, но забудем об этом — рад, что я ошибся


Цитата:

Сейчас век интернета, и я думаю перспективнее языки направленные на интернет приложения

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

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

Добавлено:

Цитата:

"Сейчас век интернета, и я думаю перспективнее языки направленные на интернет приложения."

Перспективнее не сами языки, а их изучение. Сейчас необходимо знать JavaScript, ActionScript, Java и C#, а также соответствующие платформы. С++ идёт отдельно и находится в другой области применения. (точнее у первых языков область применения ограничена)
Я уж не говорю о языках разметки, таких как HTML, CSS и XML.

Ребята хочу у вас спросить стоит ли сейчас изучать C++ Builder или вместо него надо изучать Visual C++?
Сейчас в сети много объвлений о приеме на работу программистов владеющими Visual C++ (и C#), а вот на счет С++ Builder'a что-то не видно.
Сам я пытался изучать Visual C++ но он более сложный, как мне показалось чем C++ Builder и что C++ Builder хорош тем, что в нем легко создаются прикладн. пр-мы чем на Visual C++.

Цитата:

Ребята хочу у вас спросить стоит ли сейчас изучать C++ Builder или вместо него надо изучать Visual C++?

надо в первую очередь язык изучать, а потом уже IDE, набор библиотек и WinAPI



Добавлено:

Цитата:

C++ Builder хорош тем, что в нем легко создаются прикладн. пр-мы

прикладные программы в C# еще проще создаются, но это более заслуга IDE и платформы, чем языка

Quark Fusion
Цитата:

Qraizer, если вы имели ввиду решение выражения типа sqrt(4) или поиск корней заданного! уравнения во время компиляции, то это никак не относится к оптимизации выражения от X или решения произвольного уравнения, где коэффициенты — переменные.

Кажется, до меня тоже кое-что дошло. Что такое "шаблоны выражений", представление имеется? Если нет, то большую часть поста можно просто опустить, что и делаю. Замечу только, что эту ссылку я привёл только для того, для чего и указал - для демонстрации потенциала шаблонов. К "шаблонам выражений" это не имеет никакого отношения.
Цитата:

Кстати в C шаблоны обрабатываются препроцессором, а не компилятором.

Кстати, в C шаблонов нет. Препроцессор - это такой же "механизм шаблонов", как машина Тьюринга - "язык для практического применения". Боюсь, что я даже приуменьшил.
Цитата:

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

В корне неверно. Во-первых, шаблоны - часть языка, а отнюдь не другой язык, во-вторых, "с таким же успехом" не получится, ибо это будет использованием двух языков, а если рассмативать ещё и такие варианты, то этот топик просто теряет смысл, ибо все тут признают, что сАмой перспективностью будет именно связка нескольких.
Цитата:

В пользе шаблонов никто и не сомневается, вот только назначение их не в рассчёте чего-либо при компиляции, а в автоматической генерации кода.

Ага, вот значит как. А назначение классов тогда в реализации принципов ООП? Интересная точка зрения.

Цитата:

Что такое "шаблоны выражений", представление имеется?

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


Цитата:

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

Приношу извенения — перепутал шаблоны и макросы.


Цитата:

А назначение классов тогда в реализации принципов ООП?

Класс скрывает разделяемый код, а шаблон — копируемый. Или я не прав?