Здравствуйте, iZEN, Вы писали:
M>>Потому, что С++ часть потом можно будет переписать на ассемблере (SSE и пр). ZEN>Ну-ну, удачи в делах.
Тут лучше так: "Потому, что С++ часть потом можно будет скомпилировать так, чтобы использовался SSE любых версий". И попробуй тут поспорить.
M>>Кроме того, есть ещё и доступ к массивам, который в яве, увы, однозначно медленнее и менее удобный для оптимизации. ZEN>Уверен?
Я уверен. Легко можно написать обработку массива, при которой цикл в ассемблере будет развёрнут, а индексы исчезнут.
Re[4]: Почему математику лучше писать на C++, чем на Java ил
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, iZEN, Вы писали:
M>>>Потому, что С++ часть потом можно будет переписать на ассемблере (SSE и пр). ZEN>>Ну-ну, удачи в делах.
N>Тут лучше так: "Потому, что С++ часть потом можно будет скомпилировать так, чтобы использовался SSE любых версий". И попробуй тут поспорить.
M>>>Кроме того, есть ещё и доступ к массивам, который в яве, увы, однозначно медленнее и менее удобный для оптимизации. ZEN>>Уверен?
N>Я уверен. Легко можно написать обработку массива, при которой цикл в ассемблере будет развёрнут, а индексы исчезнут.
. Тут С++ порвал С# в пять(!) раз. Именно на математике, причём пример был предложен C#истом.
S>Именно на математике — соглашусь, порвал. А комплексного решения предложенной именно мной задачи на C++ так никто и не увидел. А до тех пор, пока решение на C++ не появится, попрошу не упоминать о том что C++ порвал C# в задаче моей постановки.
А тебе нужны шашечки или ехать ? Кстати, о производительности. Я открыл второй раунд
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, samius, Вы писали:
S>>Именно на математике — соглашусь, порвал. А комплексного решения предложенной именно мной задачи на C++ так никто и не увидел. А до тех пор, пока решение на C++ не появится, попрошу не упоминать о том что C++ порвал C# в задаче моей постановки.
IID>А тебе нужны шашечки или ехать ? Кстати, о производительности. Я открыл второй раунд
Здравствуйте, iZEN, Вы писали:
M>>Кроме того, есть ещё и доступ к массивам, который в яве, увы, однозначно медленее и менее удобный для оптимизации.
ZEN>Уверен?
Хорошо, допустим у меня есть массив индексов в другом массиве. В С++ я могу просто написать "мамой клянусь, индексы валидны". И никаких дополнительных проверок выполнено не будет. Обращение A[indexes[i]] будет закодировано 1-2 инструкциями. А что в случае Java?
Re[2]: Почему математику лучше писать на C++, чем на Java ил
Здравствуйте, iZEN, Вы писали:
ZEN>(Задачка с ферзями на C и Java — в последней версии java делает си — 103 против 110 секунд.)
Гыгы, тормозная жаба якобы уделывает плюсы Дотнет сливает в 5-10 раз, а жаба уделывает LOL! Давай исходники на том и на другом. Будем компилить и выводить жабистов на чистую воду.
kalsarikännit
Re[2]: Почему математику лучше писать на C++, чем на Java ил
Здравствуйте, minorlogic, Вы писали:
LVV>>Потому что лучше писать вообще на фортране... M>Не так просто. Сейчас С++ интеловский компилятор +IPP +MKL могут быть производительнее фортрановского компилятора.
Дело в том, что у интела есть еще и Intel Fortran компилер
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Почему математику лучше писать на C++, чем на Java ил
Посмотрел я на этот "раунд". Так и не понял — чем мерялись-то И что измеряли
Предложенные топовые C/C++ решения никакого отношения к этим языкам как таковым не имеют. Там куча платформозависимого кода, включая анализ потрохов процессора + хардкодинг устройства кэша данной конкретной железяки; да ещё и стадо intrinsic'ов впридачу. Однако при всей этой пьянке арифметику для вычисления цветов условия задачи почему-то запрещают
С таким развратом я вот вполне могу предложить решение на C#/.NET, в котором ключевой момент реализован, например, через interop-вызов. Ничем не хуже intrinsic'ов
Re[5]: Почему математику лучше писать на C++, чем на Java ил
. 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 ил
Здравствуйте, samius, Вы писали:
S>Да, решения задачи в своей постановке я так и не увидел, но зато развлекся
Твоя постановка задачи — Runtime Scripting. Я готов согласиться, что как встраиваемый скрипт-язык C# вполне себе хорош. Впрочем, LuaJIT практически не отстаёт по скорости от C# Mono, а по аппетитам к памяти неплохо так его уделывает. Так что за первенствно им можно ещё поспорить
kalsarikännit
Re[6]: Почему математику лучше писать на C++, чем на Java ил
Здравствуйте, 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 ил
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, barn_czn, Вы писали:
_>>Пиши на том где быстрее и удобнее дописать проект до конца. Я вот пишу математику на том же C#, и плевать мне на то что C# код действительно работает медленнее С++. После того как я напишу и отлажу алгоритм (а именно на это уходит большая часть времени) я профайлером легко определю все узкие места. А затем эти узкие места просто переписываю на С++.. И все работает!
Y>Потом какому-то бедняге надо будет поддерживать этот безумный микс из С#'a & C++'а. Опять же, заморочки при отладке и дальнейшей модификации. Хотя, конечно все зависит от конкретной ситуации.
Ну работают же люди на языках, которые не C/C++, но у которых рантайм на нём написан?;)) От бутерброда никуда не деться. Грамотное разделение функций между слоями и чёткое API нижних слоёв — и заморочек не будет.
Re[7]: Почему математику лучше писать на C++, чем на Java ил
Здравствуйте, 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 не очень хорошо дела идут. Зато в этих тестах вполне себе:
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 ил
Здравствуйте, 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&lang=all&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&lang=all&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 ил
Здравствуйте, 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 и
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, samius, Вы писали:
S>>Так может в некоторых условиях и C# не самый плохой выбор, принимая во внимание возможности платформы (я здесь не про встроенные компиляторы). IID>Тут тоже соглашусь. Я спорил лишь с тем, что C# не отстаёт от C++ по производительности. Отстаёт, и отстаёт значительно. Понятно, что во многих задачах это не является узким местом.
Давай на этом и сойдемся.
IID>Кстати, насчёт C#, Lua и встраиваемых платформ: Lua, при прочих своих достоинствах (скорострельность, умеренные аппетиты к памяти, более чем скромный размер) замечательно портируема практически куда угодно, где есть С-компилятор. Ей открыты такие ниши, которые C# в принципе недоступны. Например, скриптинг в ядре ОС. Или в микроконтроллере.
Да, но вот например, корпоративного приложения я на Lua не представляю. С привлечением Lua — очень может быть.
Re[5]: Почему математику лучше писать на C++, чем на Java ил
Здравствуйте, 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>И не куча,
Вот список платформозависимых нештяков из топового решения:
Если Вы будете продолжать упираться и настаивать, что это не куча, то предлагаю открыть соответствующее голосование
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 ил
Здравствуйте, 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.
Дотнет сливает в 5-10 раз, а жаба уделывает LOL! Давай исходники на том и на другом. Будем компилить и выводить жабистов на чистую воду.
И что измеряли 
Как встраиваемый скрипт язык он как раз не сильно то и хорош (требует либо COM либо .NET обвязки).
Фанатики они неадекватные в принципе.
