Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 14.10.09 17:07
Оценка:
Здравствуйте, iZEN, Вы писали:

M>>Потому, что С++ часть потом можно будет переписать на ассемблере (SSE и пр).

ZEN>Ну-ну, удачи в делах.

Тут лучше так: "Потому, что С++ часть потом можно будет скомпилировать так, чтобы использовался SSE любых версий". И попробуй тут поспорить.

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

ZEN>Уверен?

Я уверен. Легко можно написать обработку массива, при которой цикл в ассемблере будет развёрнут, а индексы исчезнут.
https://elibrary.ru/author_counter.aspx?id=875549
Re[4]: Почему математику лучше писать на C++, чем на Java ил
От: iZEN СССР  
Дата: 14.10.09 17:21
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Здравствуйте, iZEN, Вы писали:


M>>>Потому, что С++ часть потом можно будет переписать на ассемблере (SSE и пр).

ZEN>>Ну-ну, удачи в делах.

N>Тут лучше так: "Потому, что С++ часть потом можно будет скомпилировать так, чтобы использовался SSE любых версий". И попробуй тут поспорить.


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

ZEN>>Уверен?

N>Я уверен. Легко можно написать обработку массива, при которой цикл в ассемблере будет развёрнут, а индексы исчезнут.


На Java тоже можно заоптимизировать контейнерные типы:
http://javolution.org/doc/benchmark.html
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: IID Россия  
Дата: 14.10.09 18:28
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, IID, Вы писали:


IID>>Например вот поэтому
Автор: IID
Дата: 20.05.09
. Тут С++ порвал С# в пять(!) раз. Именно на математике, причём пример был предложен C#истом.


S>Именно на математике — соглашусь, порвал. А комплексного решения предложенной именно мной задачи на C++ так никто и не увидел. А до тех пор, пока решение на C++ не появится, попрошу не упоминать о том что C++ порвал C# в задаче моей постановки.


А тебе нужны шашечки или ехать ? Кстати, о производительности. Я открыл второй раунд
Автор: IID
Дата: 21.09.09
. Welcome!
kalsarikännit
Re[4]: Почему математику лучше писать на C++, чем на Java ил
От: samius Россия http://sams-tricks.blogspot.com
Дата: 14.10.09 18:54
Оценка:
Здравствуйте, IID, Вы писали:

IID>Здравствуйте, samius, Вы писали:


S>>Именно на математике — соглашусь, порвал. А комплексного решения предложенной именно мной задачи на C++ так никто и не увидел. А до тех пор, пока решение на C++ не появится, попрошу не упоминать о том что C++ порвал C# в задаче моей постановки.


IID>А тебе нужны шашечки или ехать ? Кстати, о производительности. Я открыл второй раунд
Автор: IID
Дата: 21.09.09
. Welcome!


Да, решения задачи в своей постановке я так и не увидел, но зато развлекся
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 15.10.09 10:17
Оценка:
Здравствуйте, iZEN, Вы писали:

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


ZEN>Уверен?


Хорошо, допустим у меня есть массив индексов в другом массиве. В С++ я могу просто написать "мамой клянусь, индексы валидны". И никаких дополнительных проверок выполнено не будет. Обращение A[indexes[i]] будет закодировано 1-2 инструкциями. А что в случае Java?
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: IID Россия  
Дата: 15.10.09 22:23
Оценка: +2
Здравствуйте, iZEN, Вы писали:

ZEN>(Задачка с ферзями на C и Java — в последней версии java делает си — 103 против 110 секунд.)


Гыгы, тормозная жаба якобы уделывает плюсы Дотнет сливает в 5-10 раз, а жаба уделывает LOL! Давай исходники на том и на другом. Будем компилить и выводить жабистов на чистую воду.
kalsarikännit
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: minorlogic Украина  
Дата: 16.10.09 18:38
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Потому что лучше писать вообще на фортране...


Не так просто. Сейчас С++ интеловский компилятор +IPP +MKL могут быть производительнее фортрановского компилятора.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: CreatorCray  
Дата: 17.10.09 23:39
Оценка:
Здравствуйте, minorlogic, Вы писали:

LVV>>Потому что лучше писать вообще на фортране...

M>Не так просто. Сейчас С++ интеловский компилятор +IPP +MKL могут быть производительнее фортрановского компилятора.
Дело в том, что у интела есть еще и Intel Fortran компилер
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Почему математику лучше писать на C++, чем на Java ил
От: drol  
Дата: 18.10.09 18:18
Оценка:
Здравствуйте, IID, Вы писали:

IID>Кстати, о производительности. Я открыл второй раунд
Автор: IID
Дата: 21.09.09
. Welcome!


Посмотрел я на этот "раунд". Так и не понял — чем мерялись-то И что измеряли

Предложенные топовые C/C++ решения никакого отношения к этим языкам как таковым не имеют. Там куча платформозависимого кода, включая анализ потрохов процессора + хардкодинг устройства кэша данной конкретной железяки; да ещё и стадо intrinsic'ов впридачу. Однако при всей этой пьянке арифметику для вычисления цветов условия задачи почему-то запрещают

С таким развратом я вот вполне могу предложить решение на C#/.NET, в котором ключевой момент реализован, например, через interop-вызов. Ничем не хуже intrinsic'ов
Re[5]: Почему математику лучше писать на C++, чем на Java ил
От: IID Россия  
Дата: 21.10.09 23:26
Оценка:
Здравствуйте, drol, Вы писали:

D>Здравствуйте, IID, Вы писали:


IID>>Кстати, о производительности. Я открыл второй раунд
Автор: IID
Дата: 21.09.09
. Welcome!


D>Посмотрел я на этот "раунд". Так и не понял — чем мерялись-то И что измеряли


Плохо смотрел значит. Скоростью выполнения мерялись. Ну и потребляемой памятью тоже, хотя там потреблять нечего.

D>Предложенные топовые C/C++ решения никакого отношения к этим языкам как таковым не имеют.


Что за бред ? Решения написаны исключительно и полностью на C/C++. Что ещё надо, чтобы "иметь отношение" ?

D>Там куча платформозависимого кода, включая анализ потрохов процессора


Скорее OS зависимого. И не куча, не обманывай. Только получение информации о CPU да выровненное выделение памяти. Причём для выровненного выделения можно убрать велосипед и использовать функции ОС а не самопал. А за многословное получение инфы о CPU надо сказать "спасибо" линуксу, за парсинг текстового конфига. В винде это делается значительно лаконичнее.


D>+ хардкодинг устройства кэша данной конкретной железяки;


Лукавишь. Программа одинаково хорошо будет работать и не на Quad. Зато на Quad она будет работать эффективнее, чем сферическая в вакууме универсальная реализация.

D>да ещё и стадо intrinsic'ов впридачу.


Под "стадом" ты имеешь в виду единственный __sync_val_compare_and_swap ? Дык это просто Interlocked операция. В C++, к сожалению, их, встроенных в язык, нет. Поэтому необходимо пользоваться сервисами, либо OS либо компилятора.

D>Однако при всей этой пьянке арифметику для вычисления цветов условия задачи почему-то запрещают


Ты о чём ?

D>С таким развратом я вот вполне могу предложить решение на C#/.NET,


Давай, именно это и нужно.

D>в котором ключевой момент реализован, например, через interop-вызов. Ничем не хуже intrinsic'ов


Не подменяй понятия. Ключевые моменты в примере написаны как раз на C/C++. Interlocked-операции, выделение памяти, первоначальный анализ конфигурации — вот их можешь interop-ить сколько угодно. Только врядли тебе это поможет.
kalsarikännit
Re[5]: Почему математику лучше писать на C++, чем на Java ил
От: IID Россия  
Дата: 21.10.09 23:53
Оценка:
Здравствуйте, samius, Вы писали:

S>Да, решения задачи в своей постановке я так и не увидел, но зато развлекся


Твоя постановка задачи — Runtime Scripting. Я готов согласиться, что как встраиваемый скрипт-язык C# вполне себе хорош. Впрочем, LuaJIT практически не отстаёт по скорости от C# Mono, а по аппетитам к памяти неплохо так его уделывает. Так что за первенствно им можно ещё поспорить
kalsarikännit
Re[6]: Почему математику лучше писать на C++, чем на Java ил
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.10.09 05:09
Оценка:
Здравствуйте, IID, Вы писали:

IID>Здравствуйте, samius, Вы писали:


S>>Да, решения задачи в своей постановке я так и не увидел, но зато развлекся


IID>Твоя постановка задачи — Runtime Scripting.

Не совсем согласен. Скриптовые языки рулят приложениями, джобами, и т.п. Они ближе к автоматизации, управлению движками. В моей постановке достаточно рулить только низкоуровневым счетом. В идеале достаточно узкозаточенного JIT-а (я использовал более широкозаточенный), на худой конец можно использовать узкозаточенный VM и транслятор в свой байткод. Да и скриптами эту задачу решать можно. Только скрипты — это большее, чем для этой задачи нужно.

IID>Я готов согласиться, что как встраиваемый скрипт-язык C# вполне себе хорош.

Вообще я не понимаю, что тебя в этой задаче цепляет. Это лишь пример, где приемлемое по производительности решение в конкретной постановке задачи оказалось доступнее на C#-е, чем на C++. Достаточно было признать только лишь это, а не соглашаться что C# вплне хорош как встраиваемый скрипт-язык. Как встраиваемый скрипт язык он как раз не сильно то и хорош (требует либо COM либо .NET обвязки).

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

Эта задача не делает C# божественным и не ущемляет своим существованием C++, т.к. задача все-таки из специфической области. И я предпочитаю C# не потому что есть такая задача, а потому что я и команда, в которой я работаю, гораздо продуктивнее на C# чем на C++.
Лично мне больше чем C# нравятся Nemerle и F#. Но боюсь, что команда их не потянет и продуктивность будут ниже чем на C++, т.к. потребуется командный парадигм шифт, который невозможно спланировать (это к тому, что я не фанатик C#-а, если вдруг такое тебе показалось).

IID>Впрочем, LuaJIT практически не отстаёт по скорости от C# Mono, а по аппетитам к памяти неплохо так его уделывает. Так что за первенствно им можно ещё поспорить


Заглянул сюда. По памяти — да, уделывает. Но сказать что практически не отстает по скорости от C# Mono — это ты немного приврал. Здесь так практически раз в 20 навскидку отстает. Хотя допускаю, что тесты не адекватны, или ты говорил о LuaJIT2, бенчмарки которого я не нашел.

Впрочем, к чему ты помянул LuaJIT, это аргумент в пользу C++, против C#, или чтобы вставить что-то про скриптинг?
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.10.09 06:08
Оценка:
Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, barn_czn, Вы писали:


_>>Пиши на том где быстрее и удобнее дописать проект до конца. Я вот пишу математику на том же C#, и плевать мне на то что C# код действительно работает медленнее С++. После того как я напишу и отлажу алгоритм (а именно на это уходит большая часть времени) я профайлером легко определю все узкие места. А затем эти узкие места просто переписываю на С++.. И все работает!


Y>Потом какому-то бедняге надо будет поддерживать этот безумный микс из С#'a & C++'а. Опять же, заморочки при отладке и дальнейшей модификации. Хотя, конечно все зависит от конкретной ситуации.


Ну работают же люди на языках, которые не C/C++, но у которых рантайм на нём написан?;)) От бутерброда никуда не деться. Грамотное разделение функций между слоями и чёткое API нижних слоёв — и заморочек не будет.
Re[7]: Почему математику лучше писать на C++, чем на Java ил
От: IID Россия  
Дата: 22.10.09 07:43
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, IID, Вы писали:


IID>>Здравствуйте, samius, Вы писали:


S>>>Да, решения задачи в своей постановке я так и не увидел, но зато развлекся


IID>>Я готов согласиться, что как встраиваемый скрипт-язык C# вполне себе хорош.

S>Вообще я не понимаю, что тебя в этой задаче цепляет. Это лишь пример, где приемлемое по производительности решение в конкретной постановке задачи оказалось доступнее на C#-е, чем на C++. Достаточно было признать только лишь это, а не соглашаться что C# вплне хорош как встраиваемый скрипт-язык. Как встраиваемый скрипт язык он как раз не сильно то и хорош (требует либо COM либо .NET обвязки).

В твоей задаче прежде всего была куча вычислений. И я продемонстрировал что вычисления эти на С++ выполняются в 5-10 раз быстрее. Что цепляет ? Просто Just For Fun, в пику сложившемуся неадекватному мнению что вычисления на C# медленее на какие-то проценты. Это не так.

S>И то что я его применил к решению той задачи — заслуга больше не C#-а, а CLR-а со встроенными компиляторами. И будь в C++-е такие же возможности, я бы и его смог применить для решения той задачи, но не стал бы использовать от этого повседневно.


S>Лично мне больше чем C# нравятся Nemerle и F#. Но боюсь, что команда их не потянет и продуктивность будут ниже чем на C++, т.к. потребуется командный парадигм шифт, который невозможно спланировать (это к тому, что я не фанатик C#-а, если вдруг такое тебе показалось).


Во! Грамотная мысль! "Не потянет". Именно так. C# замечательно подходит для мало- и средне- квалифицированных разработчиков. И позволяет получить от них приемлемый результат в приемлемые сроки. Осталось только развенчать миф, что этот результат по скорости _ИСПОЛНЕНИЯ_ будет близок к аналогичному на С++. А то что ты не фанатик C# я уже понял. Фанатики они неадекватные в принципе.


IID>>Впрочем, LuaJIT практически не отстаёт по скорости от C# Mono, а по аппетитам к памяти неплохо так его уделывает. Так что за первенствно им можно ещё поспорить


S>Заглянул сюда. По памяти — да, уделывает. Но сказать что практически не отстает по скорости от C# Mono — это ты немного приврал.


Да, все тесты я не удосужился посмотреть. По твоей ссылке у Lua не очень хорошо дела идут. Зато в этих тестах вполне себе:

http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&amp;lang=all&amp;box=1
1.3 Lua #5 5.01 1,728
1.8 C# Mono #3 6.78 5,528
1.8 Lua LuaJIT 6.80 1,676

http://shootout.alioth.debian.org/u32q/benchmark.php?test=knucleotide&amp;lang=all&amp;sort=fullcpu
4.9 Lua LuaJIT #2 93.11 664,512
5.6 C# Mono 105.95 452,684



S> Здесь так практически раз в 20 навскидку отстает.


Эээээ... какие 20 раз ? 5 раз максимум. Заметь, при почти в 5-ро меньшем потреблении памяти.
1.3 C# Mono #2 15.73 4,544
6.3 Lua LuaJIT #3 74.47 1,364

S>Хотя допускаю, что тесты не адекватны, или ты говорил о LuaJIT2, бенчмарки которого я не нашел.


Я говорил только о LuaJIT. Цифры #2, #3 ... #6 в постфиксе это, ИМХО, номер семпла, если их несколько. Для mono тоже есть C# mono #2

S>Впрочем, к чему ты помянул LuaJIT, это аргумент в пользу C++, против C#, или чтобы вставить что-то про скриптинг?


Только чтобы вставить что-то про скриптинг. Если производительность не является жизненно важной (читай: С++ применять смысла нет), а необходимо решение "по месту" и с быстрой сменой логики то LUA не самый плохой выбор. К тому же LUA очень компактный язык, замечательно расширяемый и без кучи зависимостей.
kalsarikännit
Re[8]: Почему математику лучше писать на C++, чем на Java ил
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.10.09 08:40
Оценка:
Здравствуйте, IID, Вы писали:

IID>Здравствуйте, samius, Вы писали:


IID>В твоей задаче прежде всего была куча вычислений. И я продемонстрировал что вычисления эти на С++ выполняются в 5-10 раз быстрее. Что цепляет ? Просто Just For Fun, в пику сложившемуся неадекватному мнению что вычисления на C# медленее на какие-то проценты. Это не так.

Пусть не так.

S>>Лично мне больше чем C# нравятся Nemerle и F#. Но боюсь, что команда их не потянет и продуктивность будут ниже чем на C++, т.к. потребуется командный парадигм шифт, который невозможно спланировать (это к тому, что я не фанатик C#-а, если вдруг такое тебе показалось).


IID>Во! Грамотная мысль! "Не потянет". Именно так. C# замечательно подходит для мало- и средне- квалифицированных разработчиков. И позволяет получить от них приемлемый результат в приемлемые сроки. Осталось только развенчать миф, что этот результат по скорости _ИСПОЛНЕНИЯ_ будет близок к аналогичному на С++.

Вот бы еще развенчать миф о том что C# подходит только для мало и средне квалифицированных разработчиков.
А скорость работы результата далеко не всегда упирается в скорость исполнения кода, например 100Мб снимок с сервера С++-ом быстрее не достанешь, т.к. упрется все в сеть, и SqlServer быстрее не выполнит запрос, если обратишься к нему из C++-а.

IID>>>Впрочем, LuaJIT практически не отстаёт по скорости от C# Mono, а по аппетитам к памяти неплохо так его уделывает. Так что за первенствно им можно ещё поспорить


S>>Заглянул сюда. По памяти — да, уделывает. Но сказать что практически не отстает по скорости от C# Mono — это ты немного приврал.


IID>Да, все тесты я не удосужился посмотреть. По твоей ссылке у Lua не очень хорошо дела идут. Зато в этих тестах вполне себе:


IID>http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&amp;lang=all&amp;box=1

IID>1.3 Lua #5 5.01 1,728
IID>1.8 C# Mono #3 6.78 5,528
IID>1.8 Lua LuaJIT 6.80 1,676

IID>http://shootout.alioth.debian.org/u32q/benchmark.php?test=knucleotide&amp;lang=all&amp;sort=fullcpu

IID>4.9 Lua LuaJIT #2 93.11 664,512
IID>5.6 C# Mono 105.95 452,684

S>> Здесь так практически раз в 20 навскидку отстает.


IID>Эээээ... какие 20 раз ? 5 раз максимум. Заметь, при почти в 5-ро меньшем потреблении памяти.

IID>1.3 C# Mono #2 15.73 4,544
IID>6.3 Lua LuaJIT #3 74.47 1,364
ЭЭЭЭЭ. Я смотрел на колонку Elapsed! Пользователю как правил важнее Elapsed, чем CPU Time.
Ну и про 5-ро меньшее потребление памяти ты опять приварл! Максимум — 3.33

S>>Впрочем, к чему ты помянул LuaJIT, это аргумент в пользу C++, против C#, или чтобы вставить что-то про скриптинг?


IID>Только чтобы вставить что-то про скриптинг. Если производительность не является жизненно важной (читай: С++ применять смысла нет), а необходимо решение "по месту" и с быстрой сменой логики то LUA не самый плохой выбор. К тому же LUA очень компактный язык, замечательно расширяемый и без кучи зависимостей.


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

Тем не менее, Lua /*неправильно писать «LUA» одними только прописными символами.(Ц википедиа)*/, используется и там где производительность важна. Но ее важнее что-то другое. Так вот, это что-то важное может быть не только в Lua.

Так может в некоторых условиях и C# не самый плохой выбор, принимая во внимание возможности платформы (я здесь не про встроенные компиляторы).
Re[9]: Почему математику лучше писать на C++, чем на Java ил
От: IID Россия  
Дата: 22.10.09 09:33
Оценка:
Здравствуйте, samius, Вы писали:

IID>>В твоей задаче прежде всего была куча вычислений. И я продемонстрировал что вычисления эти на С++ выполняются в 5-10 раз быстрее. Что цепляет ? Просто Just For Fun, в пику сложившемуся неадекватному мнению что вычисления на C# медленее на какие-то проценты. Это не так.

S>Пусть не так.
Замечательно.

S>>>Лично мне больше чем C# нравятся Nemerle и F#. Но боюсь, что команда их не потянет и продуктивность будут ниже чем на C++, т.к. потребуется командный парадигм шифт, который невозможно спланировать (это к тому, что я не фанатик C#-а, если вдруг такое тебе показалось).


IID>>Во! Грамотная мысль! "Не потянет". Именно так. C# замечательно подходит для мало- и средне- квалифицированных разработчиков. И позволяет получить от них приемлемый результат в приемлемые сроки. Осталось только развенчать миф, что этот результат по скорости _ИСПОЛНЕНИЯ_ будет близок к аналогичному на С++.

S>Вот бы еще развенчать миф о том что C# подходит только для мало и средне квалифицированных разработчиков.

Я не утверждал что C# подходит только для мало- и средне- квалифицированных разработчиков. Но подходит, в том числе, и для них. И за это многими любим. В отличие от С++, где дятел чуть более чем 100% наломает дров.

S>А скорость работы результата далеко не всегда упирается в скорость исполнения кода, например 100Мб снимок с сервера С++-ом быстрее не достанешь, т.к. упрется все в сеть, и SqlServer быстрее не выполнит запрос, если обратишься к нему из C++-а.


Это очевидно.

S>>>Впрочем, к чему ты помянул LuaJIT, это аргумент в пользу C++, против C#, или чтобы вставить что-то про скриптинг?


IID>>Только чтобы вставить что-то про скриптинг. Если производительность не является жизненно важной (читай: С++ применять смысла нет), а необходимо решение "по месту" и с быстрой сменой логики то LUA не самый плохой выбор. К тому же LUA очень компактный язык, замечательно расширяемый и без кучи зависимостей.


S>Оказывается, производительность не всегда является жизненно важной. Рад слышать это от тебя.

Я никогда не утверждал что производительность это наше всё. Взаимно, рад что тут тоже нашлось взаимопонимание.

S>Так может в некоторых условиях и C# не самый плохой выбор, принимая во внимание возможности платформы (я здесь не про встроенные компиляторы).

Тут тоже соглашусь. Я спорил лишь с тем, что C# не отстаёт от C++ по производительности. Отстаёт, и отстаёт значительно. Понятно, что во многих задачах это не является узким местом.

Кстати, насчёт C#, Lua и встраиваемых платформ: Lua, при прочих своих достоинствах (скорострельность, умеренные аппетиты к памяти, более чем скромный размер) замечательно портируема практически куда угодно, где есть С-компилятор. Ей открыты такие ниши, которые C# в принципе недоступны. Например, скриптинг в ядре ОС. Или в микроконтроллере.
kalsarikännit
Re[10]: Почему математику лучше писать на C++, чем на Java и
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.10.09 09:59
Оценка:
Здравствуйте, IID, Вы писали:

IID>Здравствуйте, samius, Вы писали:


S>>Так может в некоторых условиях и C# не самый плохой выбор, принимая во внимание возможности платформы (я здесь не про встроенные компиляторы).

IID>Тут тоже соглашусь. Я спорил лишь с тем, что C# не отстаёт от C++ по производительности. Отстаёт, и отстаёт значительно. Понятно, что во многих задачах это не является узким местом.
Давай на этом и сойдемся.

IID>Кстати, насчёт C#, Lua и встраиваемых платформ: Lua, при прочих своих достоинствах (скорострельность, умеренные аппетиты к памяти, более чем скромный размер) замечательно портируема практически куда угодно, где есть С-компилятор. Ей открыты такие ниши, которые C# в принципе недоступны. Например, скриптинг в ядре ОС. Или в микроконтроллере.

Да, но вот например, корпоративного приложения я на Lua не представляю. С привлечением Lua — очень может быть.
Re[5]: Почему математику лучше писать на C++, чем на Java ил
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.10.09 17:11
Оценка:
Здравствуйте, Dog, Вы писали:

Dog>Тсссс... пусть этот "Александреску" и дальше пишет на своих плюсах


Он на D давно пишет.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Почему математику лучше писать на C++, чем на Java ил
От: drol  
Дата: 22.10.09 19:24
Оценка:
Здравствуйте, IID, Вы писали:

IID>Плохо смотрел значит.


Всё ровно наоборот — как раз я смотрел очень хорошо и тщательно.

IID>Скоростью выполнения мерялись.


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

D>>Предложенные топовые C/C++ решения никакого отношения к этим языкам как таковым не имеют.


IID>Что за бред ?


Это не ко мне. Это к авторам решений и "турнира", пожалуйста

IID>Решения написаны исключительно и полностью на C/C++.


Да ну ? И где же это Вы видели в C/C++ __sync_val_compare_and_swap ??? Не поделитесь ли ссылкой на страницу/раздел стандарта ???

IID>Что ещё надо, чтобы "иметь отношение" ?


Надо иметь код соответствующий стандарту языка и портабельный в его рамках. И предложенное на "турнире" решение на C#, например, является именно таким — отлично работает как на Mono, так и на кошерной reference-реализации

D>>Там куча платформозависимого кода, включая анализ потрохов процессора


IID>Скорее OS зависимого.


ОС — часть платформы.

IID>И не куча,


Вот список платформозависимых нештяков из топового решения:

__sync_val_compare_and_swap
sched_yield
CPU_ZERO
sched_getaffinity
CPU_ISSET
CPU_SET
pthread_attr_init
pthread_attr_setaffinity_np
pthread_create
pthread_join
pthread_attr_destroy

Если Вы будете продолжать упираться и настаивать, что это не куча, то предлагаю открыть соответствующее голосование

IID> не обманывай.


Извиняться за наезды бум ?

D>>+ хардкодинг устройства кэша данной конкретной железяки;


IID>Лукавишь.


Вы опять нарываетесь

Цитирую код:
#define CL_SIZE 64

Что это по-Вашему такое ?

IID>Программа одинаково хорошо будет работать и не на Quad.


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

D>>да ещё и стадо intrinsic'ов впридачу.


IID>Под "стадом" ты имеешь в виду единственный __sync_val_compare_and_swap ?


Вы хотите сказать, что __sync_val_compare_and_swap совершенно несущественнен для этого решения задачи ??? Ну тогда замените его на что-нибудь неintrinsic'овое, а мы посмотрим на результат

*Кстати, а C++ решение занимающее третье место в списке использует вообще __builtin_expect

IID>Дык это просто Interlocked операция.


Я прекрасно знаю что это такое, уважаемый

IID>В C++, к сожалению, их, встроенных в язык, нет.


Странно, а несколькими абзацами выше Вы недоумевали почему это я считаю, что C++ не имеет отношения к обсуждаемым решениям

IID>Поэтому необходимо пользоваться сервисами, либо OS либо компилятора.


Какой Вы ушлый. А почему именно такая комбинация-то ??? Потому что Вам так захотелось ??? А почему бы Вам не ограничиться только сервисами ОС, например ???

D>>Однако при всей этой пьянке арифметику для вычисления цветов условия задачи почему-то запрещают


IID>Ты о чём ?


Вот об этом:

both creatures will change colour to complement the colour of the chameneos that they met — don't use arithmetic to complement the colour, use if-else or switch/case or pattern-match


D>>С таким развратом я вот вполне могу предложить решение на C#/.NET,


IID>Давай, именно это и нужно.


Да легко

D>>в котором ключевой момент реализован, например, через interop-вызов. Ничем не хуже intrinsic'ов


IID>Не подменяй понятия.


Вы что-то путаете. У меня всё в порядке. А вот у Вас двойные стандарты во всей красе.

Когда чего-то в C/C++ не хватает — Вы сразу разрешаете себе использовать всё что угодно: и intrinsic'и, и сервисы ОС... Однако как только чего-то не хватает в C# — сразу вопли про "подмену понятий"

IID>Ключевые моменты в примере написаны как раз на C/C++.


И снова неправда. __sync_val_compare_and_swap — ключевой момент, однако это intrinsic, и к C/C++ как языкам он не имеет никакого отношения. __builtin_expect — не менее зверский intrinsic.

IID>Interlocked-операции, выделение памяти, первоначальный анализ конфигурации — вот их можешь interop-ить сколько угодно.


Гы! Извините, но Ваши разрешения мне не требуются. Я сам их выдаю

IID>Только врядли тебе это поможет.


И оракул из Вас тоже нулёвый

Прямой порт решения уважаемого remark'а, даже без заточек на архитектуру кэша и без привязки к физическим ядрам, на моей домашней системе (Q6600 + Vista 32-bit) даёт двухкратный рост производительности в сравнении с выполнением опубликованного C# кода. После добавления привязки выигрыш составляет уже более шести раз.
Re[7]: Почему математику лучше писать на C++, чем на Java ил
От: IID Россия  
Дата: 23.10.09 17:12
Оценка:
Здравствуйте, drol, Вы писали:

IID>>Скоростью выполнения мерялись.


D>Если мерялись скоростью, то зачем тогда задаются ограничения на арифметику цветов, кастомные планировщики и т.д.

D>both creatures will change colour to complement the colour of the chameneos that they met — don't use arithmetic to complement the colour, use if-else or switch/case or pattern-match[/q]

А разве непонятно ? Чтобы заставить язык поворочать данными. Рассчёт по готовой аналитической формуле практически не отличается в разных языках, поэтому и мерять им нечего.

IID>>Решения написаны исключительно и полностью на C/C++.


D>Да ну ? И где же это Вы видели в C/C++ __sync_val_compare_and_swap ??? Не поделитесь ли ссылкой на страницу/раздел стандарта ???


В стандарте языка нет примитивов синхронизации. Но это не мешает программам на C/C++ ими пользоваться.

IID>>Что ещё надо, чтобы "иметь отношение" ?


D>Надо иметь код соответствующий стандарту языка и портабельный в его рамках. И предложенное на "турнире" решение на C#, например, является именно таким — отлично работает как на Mono, так и на кошерной reference-реализации


Насколько портабельный ? Вариант для MSVC/GCC устроит ? Это легко достигается условной компиляцией. Например __sync_val_compare_and_swap/InterlockedExchange. Если придираться к портабельности — то Mono далеко не полный аналог "некошерной reference-реализации", и при желании можно наклепать код, который не будет "отлично работать".


D>>>Там куча платформозависимого кода, включая анализ потрохов процессора


IID>>Скорее OS зависимого.


D>ОС — часть платформы.


"Платформозависимый код" и "ОС зависимый код" понятия не эквивалентные. И то, что "ОС — часть платформы" этот факт никак не отменяет.
Например:
Вызов функции "InterlockedIncrement" — ОС зависимый код. Он будет корректно работать в Windows, например, на x86/x64/ARM/Itanium. Но не будет в Linux/FreeBSD/etc.
Ассемблерная команда "lock add" — Платформозависимый код. Будет работать только на процессорах, у которых есть именно эта команда. Зато будет работать и в Linux, и в Windows и в MacOS.

D>Вот список платформозависимых нештяков из топового решения:


D>__sync_val_compare_and_swap

Зависит от ОС. Платформозависимая реализация была бы на ассемблере, для x86, например, в виде инструкций с lock префиксом.

D>sched_yield

D>CPU_ZERO
D>sched_getaffinity
D>CPU_ISSET
D>CPU_SET
D>pthread_attr_init
D>pthread_attr_setaffinity_np
D>pthread_create
D>pthread_join
D>pthread_attr_destroy
Тоже самое, зависит от ОС.

Собственно все эти вызовы имеют аналоги в Win. Поэтому код портируется тривиально.

D>>>С таким развратом я вот вполне могу предложить решение на C#/.NET,


IID>>Давай, именно это и нужно.


D>Да легко


И где это решение ?

D>Когда чего-то в C/C++ не хватает — Вы сразу разрешаете себе использовать всё что угодно: и intrinsic'и, и сервисы ОС... Однако как только чего-то не хватает в C# — сразу вопли про "подмену понятий"


А чего не хватает в C# ? Всей реализации хамелеонов целиком ? Тогда, простите, что останется от C#, если мы будем сравнивать С++ и С++.

D>Прямой порт решения уважаемого remark'а, даже без заточек на архитектуру кэша и без привязки к физическим ядрам, на моей домашней системе (Q6600 + Vista 32-bit) даёт двухкратный рост производительности в сравнении с выполнением опубликованного C# кода. После добавления привязки выигрыш составляет уже более шести раз.


Джентльменам верят на слово ? И тут карта как попёрла!
Непонятно, почему до "добавления привязки" (кстати, что за привязка ?) выигрыш был всего двукратным ? Напоминаю, перенос опубликованной C# реализации с моно на компилятор C# от MS дал сразу 4-х кратный прирост производительности. И всё равно, разрыв между GCC C++ версией и референсным .NET-ом составила 13.67 раз.

Хочу увидеть C# реализацию, где разрыв уменьшился хотя бы до 5 раз. Тогда будет иметь смысл и портабельность сделать. И взять Intel С++ Compiler.
kalsarikännit
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.