Почему математику лучше писать на C++, чем на Java или C# ?
От: erslgoeirjh Россия http://russianfellow.livejournal.com
Дата: 07.10.09 10:12
Оценка: :))) :))
Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?


13.10.09 05:10: Перенесено модератором из 'Средства разработки' — Кодт
Пу и Ме сидели на трубе...
Re: Почему математику лучше писать на C++, чем на Java или C
От: Nonmanual Worker  
Дата: 07.10.09 11:24
Оценка: +2 -1
Здравствуйте, erslgoeirjh, Вы писали:

E>Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?

Потомучто написанное на С++ будет быстрее работать, что весьма критично для многих "математикоемких" задач. Да и сторонних мат. библиотек для С++ навалом. А по удобству математику особо без разницы на каком языке\среде писать.
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: . Великобритания  
Дата: 07.10.09 11:47
Оценка: 1 (1) +1 :)
Nonmanual Worker wrote:

> Потомучто написанное на С++ будет быстрее работать, что весьма критично

> для многих "математикоемких" задач. Да и сторонних мат. библиотек для
> С++ навалом. А по удобству математику особо без разницы на каком
> языке\среде писать.
А ещё в C++ можно операторы перегружать. И выражение будет выглядеть как "a + b * c", а не "a.plus(b.multiply(c))". Так что удобство вполне различается.
Но математикам думаю haskell может понравиться...
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: nikov США http://www.linkedin.com/in/nikov
Дата: 07.10.09 11:51
Оценка:
Здравствуйте, ., Вы писали:

.>А ещё в C++ можно операторы перегружать. И выражение будет выглядеть как "a + b * c", а не "a.plus(b.multiply(c))". Так что удобство вполне различается.


Кстати, в C# тоже можно.
Re: Почему математику лучше писать на C++, чем на Java или C
От: IID Россия  
Дата: 07.10.09 14:43
Оценка:
Здравствуйте, erslgoeirjh, Вы писали:

E>Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?


Например вот поэтому
Автор: IID
Дата: 20.05.09
. Тут С++ порвал С# в пять(!) раз. Именно на математике, причём пример был предложен C#истом.
kalsarikännit
Re: Почему математику лучше писать на C++, чем на Java или C
От: Lloyd Россия  
Дата: 07.10.09 16:57
Оценка: +3 :))) :)
Здравствуйте, erslgoeirjh, Вы писали:

E>Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?


Потому что для C++ есть интеловский компилятор.
Re: Почему математику лучше писать на C++, чем на Java или C
От: LaptevVV Россия  
Дата: 08.10.09 07:36
Оценка:
Здравствуйте, erslgoeirjh, Вы писали:

E>Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?

Потому что лучше писать вообще на фортране...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Почему математику лучше писать на C++, чем на Java ил
От: Dog  
Дата: 08.10.09 07:37
Оценка:
.>>А ещё в C++ можно операторы перегружать. И выражение будет выглядеть как "a + b * c", а не "a.plus(b.multiply(c))". Так что удобство вполне различается.
N>Кстати, в C# тоже можно.
Тсссс... пусть этот "Александреску" и дальше пишет на своих плюсах
http://rsdn.org/File/27746/bel.gif
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: CreatorCray  
Дата: 09.10.09 09:18
Оценка:
Здравствуйте, LaptevVV, Вы писали:

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

Но вот только для этого надо учить фортран

Кстати интел фортран тоже есть
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Почему математику лучше писать на C++, чем на Java или C
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 09.10.09 13:41
Оценка:
Здравствуйте, erslgoeirjh, Вы писали:

E>Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?


В C# есть decimal. Если математика сводится к тому, что уже реализовано в библиотеках, типа линейной алгебры, то может быть лучше писать на более удобном языке — C#, а лучше F# или Немерле.
Ce n'est que pour vous dire ce que je vous dis.
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: Mr.Cat  
Дата: 09.10.09 15:23
Оценка: +1
Здравствуйте, Don Reba, Вы писали:
DR>В C# есть decimal.
Gmp?

DR>типа линейной алгебры

Lapack?
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: Mr.Cat  
Дата: 09.10.09 15:24
Оценка: 11 (2) +3 -1
Здравствуйте, Don Reba, Вы писали:
DR>писать на более удобном языке — C#, а лучше F# или Немерле.
Тогда уж лучше матлаб
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: Vzhyk  
Дата: 09.10.09 15:25
Оценка: +1 -1
Mr.Cat пишет:
>
> Тогда уж лучше матлаб
Ну хоть один человек что-то разумное написал.
Posted via RSDN NNTP Server 2.1 beta
http://rsdn.org/File/27746/bel.gif
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 09.10.09 16:16
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

DR>>писать на более удобном языке — C#, а лучше F# или Немерле.

MC>Тогда уж лучше матлаб

Это, как бы, движение в противоположном направлении. Если в коде нет сложной логики, то и матлаб сойдёт, да.
Ce n'est que pour vous dire ce que je vous dis.
Re[5]: Почему математику лучше писать на C++, чем на Java ил
От: kubic2009  
Дата: 09.10.09 22:26
Оценка:
Здравствуйте, Dog, Вы писали:

.>>>А ещё в C++ можно операторы перегружать. И выражение будет выглядеть как "a + b * c", а не "a.plus(b.multiply(c))". Так что удобство вполне различается.

N>>Кстати, в C# тоже можно.
Dog>Тсссс... пусть этот "Александреску" и дальше пишет на своих плюсах
Твой C# написан на C++
Re[4]: Почему математику лучше писать на C++, чем на Java ил
От: kubic2009  
Дата: 09.10.09 22:29
Оценка:
Здравствуйте, Vzhyk, Вы писали:

V>Mr.Cat пишет:

>>
>> Тогда уж лучше матлаб
V>Ну хоть один человек что-то разумное написал.
...За малым исключением того что матлаб опять же написан С++
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: Privalov  
Дата: 11.10.09 18:23
Оценка: 1 (1)
Здравствуйте, LaptevVV, Вы писали:

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


Для человека, знакомого с Фортраном — безусловно. А необстрелянная молодежь обязательно нарвется на грабли.
Я в любом случае использовал бы фортрановские библиотеки.
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: trophim Россия  
Дата: 12.10.09 18:27
Оценка:
Я уже не застал эпохи фортрана. Расскажите вкратце: он действительно даст более быстрый код (если не прибегать к ручной супер-пупер оптимизации на уровне ассмблера)? (ну, скажем, на примере Intel Fortran vs Intel C++)
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Let it be! — Давайте есть пчелу!
Re[4]: Почему математику лучше писать на C++, чем на Java ил
От: LaptevVV Россия  
Дата: 12.10.09 18:58
Оценка:
Здравствуйте, trophim, Вы писали:

T>Я уже не застал эпохи фортрана. Расскажите вкратце: он действительно даст более быстрый код (если не прибегать к ручной супер-пупер оптимизации на уровне ассмблера)? (ну, скажем, на примере Intel Fortran vs Intel C++)

Просто трансляторы фортрана были "вылизаны" еще в 60-е годы. А уж библиотек для численных расчетов для фортрана было написано море! И тоже были максимально оптимизированы
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Почему математику лучше писать на C++, чем на Java ил
От: Vzhyk  
Дата: 12.10.09 19:23
Оценка: 1 (1) +1
LaptevVV пишет:
>
> Просто трансляторы фортрана были "вылизаны" еще в 60-е годы. А уж
> библиотек для численных расчетов для фортрана было написано море! И тоже
> были максимально оптимизированы
Только вот процессоры были другие, под которые фортран вылизывался.
Posted via RSDN NNTP Server 2.1 beta
http://rsdn.org/File/27746/bel.gif
Re[5]: Почему математику лучше писать на C++, чем на Java ил
От: Privalov  
Дата: 12.10.09 19:31
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Просто трансляторы фортрана были "вылизаны" еще в 60-е годы. А уж библиотек для численных расчетов для фортрана было написано море! И тоже были максимально оптимизированы


Остается добавить, что программы на Фортране отлично переносятся с платформы на платформу. Во всяком случае мне как-то пришлось переносить проект, начавшийся, наверное, до моего рождения где-то в ДОС ЕС и продолжавшийся в ОС ЕС, на PC. Не трогал практически нигде ничего. Один раз нарвался на сегментную модель памяти в реальном режиме MS DOS (пришлось добавить атрибут HUGE некоторым массивам), да кодировку сменить на ASCII. Позже мы так же легко перенесли ее в OS/2 16 бит, OS/2 32 бита, Win 95. В UNIX ее перенесли без меня, говорят, без проблем. По слухам, та числодробилка работает и сейчас. В конце 90-х я работал с PC-версией Графора. В качестве документации пользовался этой, написанной, ЕМНИП, в 1972 году, книгой.
Re[6]: Почему математику лучше писать на C++, чем на Java ил
От: LaptevVV Россия  
Дата: 12.10.09 19:51
Оценка:
Здравствуйте, Privalov, Вы писали:

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


LVV>>Просто трансляторы фортрана были "вылизаны" еще в 60-е годы. А уж библиотек для численных расчетов для фортрана было написано море! И тоже были максимально оптимизированы


P>Остается добавить, что программы на Фортране отлично переносятся с платформы на платформу. Во всяком случае мне как-то пришлось переносить проект, начавшийся, наверное, до моего рождения где-то в ДОС ЕС и продолжавшийся в ОС ЕС, на PC. Не трогал практически нигде ничего. Один раз нарвался на сегментную модель памяти в реальном режиме MS DOS (пришлось добавить атрибут HUGE некоторым массивам), да кодировку сменить на ASCII. Позже мы так же легко перенесли ее в OS/2 16 бит, OS/2 32 бита, Win 95. В UNIX ее перенесли без меня, говорят, без проблем. По слухам, та числодробилка работает и сейчас. В конце 90-х я работал с PC-версией Графора. В качестве документации пользовался этой, написанной, ЕМНИП, в 1972 году, книгой.

Вот!!!!
А книжка эта — диссер Юрия Матвеича Баяковского. Кандидатский! Вот диссеры были — весь СССР пользовался!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Почему математику лучше писать на C++, чем на Java ил
От: MasterZiv СССР  
Дата: 13.10.09 03:34
Оценка:
CreatorCray wrote:

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

> Но вот только для этого надо учить фортран

Что там учить-то ? он простой, как 2 копейки, если не
изучать устаревшие конструкции и не изучать read/write/format,
который почти наверняка в смешанном коде и так не будет использоваться.
Posted via RSDN NNTP Server 2.1 beta
Re: Почему математику лучше писать на C++, чем на Java или C
От: MasterZiv СССР  
Дата: 13.10.09 03:36
Оценка: 1 (1) -5
erslgoeirjh wrote:

> вычисления лучше всего писать на C++, а не на Java или C#? Потому что в

> C++ есть тип long double (наряду с double и float), а в Java -- только
> double и float?

Я бы сказал, потому что на Java вообще лучше ничего не писать.
Posted via RSDN NNTP Server 2.1 beta
Re: Почему математику лучше писать на C++, чем на Java или C
От: barn_czn  
Дата: 13.10.09 03:38
Оценка: 1 (1) +1
Здравствуйте, erslgoeirjh, Вы писали:

E>Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?



Пиши на том где быстрее и удобнее дописать проект до конца. Я вот пишу математику на том же C#, и плевать мне на то что C# код действительно работает медленнее С++. После того как я напишу и отлажу алгоритм (а именно на это уходит большая часть времени) я профайлером легко определю все узкие места. А затем эти узкие места просто переписываю на С++.. И все работает!
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: samius Россия http://sams-tricks.blogspot.com
Дата: 13.10.09 04:47
Оценка:
Здравствуйте, IID, Вы писали:

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


Именно на математике — соглашусь, порвал. А комплексного решения предложенной именно мной задачи на C++ так никто и не увидел. А до тех пор, пока решение на C++ не появится, попрошу не упоминать о том что C++ порвал C# в задаче моей постановки.
Re[4]: Почему математику лучше писать на C++, чем на Java ил
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 13.10.09 05:47
Оценка: 2 (1)
Здравствуйте, trophim, Вы писали:

T>Я уже не застал эпохи фортрана. Расскажите вкратце: он действительно даст более быстрый код (если не прибегать к ручной супер-пупер оптимизации на уровне ассмблера)? (ну, скажем, на примере Intel Fortran vs Intel C++)


Я уже писал про причины преимуществ Фортрана для расчётов
Автор: netch80
Дата: 04.01.09
. Можно то же самое свести к нескольким словам для понимающих: DSL для численных расчётов всегда будет лучше, чем язык общего назначения, ограниченный расчётными действиями.

А с Java вообще тяжёлый случай — если не используется JIT, причём очень грамотный JIT: слишком много левых затрат на "объектную модель"... Там, где эти затраты компенсируются чем-то другим — она может показать результаты и лучше, но её основное преимущество не в скорости, а в переносимости.
Re[6]: Почему математику лучше писать на C++, чем на Java ил
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 13.10.09 05:49
Оценка: :)
Здравствуйте, kubic2009, Вы писали:
K>Твой C# написан на C++
Это ненадолго Процесс переписывания уже идёт.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[7]: Почему математику лучше писать на C++, чем на Java ил
От: Privalov  
Дата: 13.10.09 06:11
Оценка:
Здравствуйте, LaptevVV, Вы писали:

P>> В конце 90-х я работал с PC-версией Графора. В качестве документации пользовался этой, написанной, ЕМНИП, в 1972 году, книгой.

LVV>Вот!!!!
LVV>А книжка эта — диссер Юрия Матвеича Баяковского. Кандидатский! Вот диссеры были — весь СССР пользовался!

Ну дак если качественный продукт сделан, совершенно неважно, диссер это или что-то другое. Аксакалы, помню, отзывались о Графоре с большой симпатией. Я и решил его на PC попробовать. Позже я для него переходников понаписал, чтобы из C его звать можно было. Исключительно приятная библиотека. И другие были не хуже.

P.S. СССР к тому времени давно уже не было. А Графор, судя по Гуглу, до сих пор применяется.
Re[5]: Почему математику лучше писать на C++, чем на Java ил
От: Privalov  
Дата: 13.10.09 06:14
Оценка:
Здравствуйте, netch80, Вы писали:

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


Фортран-программы переносятся не хуже. Со всем остальным согласен.
Re[7]: Почему математику лучше писать на C++, чем на Java ил
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 13.10.09 06:19
Оценка: 1 (1)
Здравствуйте, LaptevVV, Вы писали:

P>>В качестве документации пользовался этой, написанной, ЕМНИП, в 1972 году, книгой.

LVV>Вот!!!!

Это был возглас восхваления отсутствия развития — когда ничего не меняется?

LVV>А книжка эта — диссер Юрия Матвеича Баяковского. Кандидатский! Вот диссеры были — весь СССР пользовался!


Ага, кстати Баяковский не был аспирантом и защищался "в обход" аспирантуры. Мне тоже предлагал так сделать.
Re[8]: Почему математику лучше писать на C++, чем на Java ил
От: LaptevVV Россия  
Дата: 13.10.09 07:58
Оценка:
Здравствуйте, D. Mon, Вы писали:

P>>>В качестве документации пользовался этой, написанной, ЕМНИП, в 1972 году, книгой.

LVV>>Вот!!!!
DM>Это был возглас восхваления отсутствия развития — когда ничего не меняется?
не... Графор — это островок стабильности в нашем непостоянном ИТ-мире...
LVV>>А книжка эта — диссер Юрия Матвеича Баяковского. Кандидатский! Вот диссеры были — весь СССР пользовался!
DM>Ага, кстати Баяковский не был аспирантом и защищался "в обход" аспирантуры. Мне тоже предлагал так сделать.
Я с ним разговаривал в году 75-76-м примерно. Тоже про аспирантуру. Он мне тоже тогда сказал, что в Москве своих аспирантов — пруд пруди. Поэтому в аспирантуру в Москву — сложно.
Вообще, очень приятный дядька.
http://www.keldysh.ru/departments/dpt_20/Bayak.html
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Почему математику лучше писать на C++, чем на Java или C
От: iZEN СССР  
Дата: 13.10.09 08:32
Оценка:
Здравствуйте, erslgoeirjh, Вы писали:

E>Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?


Другие сравнения: http://balancer.ru/tech/forum/2008/02/t60021--CHto,gospoda-surovye-S-plus-plus-program.html
(может не открыться за давностью лет или сервер недоступен — искать в веб-архиве)

(Задачка с ферзями на C и Java — в последней версии java делает си — 103 против 110 секунд.)
java рвёт C/C++
Re[6]: Почему математику лучше писать на C++, чем на Java ил
От: thesz Россия http://thesz.livejournal.com
Дата: 13.10.09 13:13
Оценка: 1 (1)
Здравствуйте, Vzhyk, Вы писали:

V>LaptevVV пишет:

>>
>> Просто трансляторы фортрана были "вылизаны" еще в 60-е годы. А уж
>> библиотек для численных расчетов для фортрана было написано море! И тоже
>> были максимально оптимизированы
V>Только вот процессоры были другие, под которые фортран вылизывался.

Отсутствие перекрытия переменных (aliasing) в нём осталось до сих пор.

Что даёт очень большой объём оптимизаций.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Почему математику лучше писать на C++, чем на Java или C
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 13.10.09 16:30
Оценка:
Здравствуйте, erslgoeirjh, Вы писали:

E>Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?


Главным образом это предпочтения людей, которые в состоянии понять суть проблемы и написать соответствующие математические вычисления. Также их знания и опыт.
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 13.10.09 16:48
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Другие сравнения: http://balancer.ru/tech/forum/2008/02/t60021--CHto,gospoda-surovye-S-plus-plus-program.html

ZEN>(может не открыться за давностью лет или сервер недоступен — искать в веб-архиве)

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


Что-то какое-то сравнение необъективное... Сама тема вечный флейм, резюме никакого нету, исходники тоже надо искать.
Re[7]: Почему математику лучше писать на C++, чем на Java ил
От: yumi  
Дата: 14.10.09 09:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

K>>Твой C# написан на C++

S>Это ненадолго Процесс переписывания уже идёт.

Да уже давно написано, см. Mono.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: yumi  
Дата: 14.10.09 10:23
Оценка:
Здравствуйте, barn_czn, Вы писали:

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


Потом какому-то бедняге надо будет поддерживать этот безумный микс из С#'a & C++'а. Опять же, заморочки при отладке и дальнейшей модификации. Хотя, конечно все зависит от конкретной ситуации.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re: Почему математику лучше писать на C++, чем на Java или C
От: mkizub Литва http://symade.tigris.org
Дата: 14.10.09 13:39
Оценка:
Здравствуйте, erslgoeirjh, Вы писали:

E>Я разрабатываю проект, в котором часть программ пишется на Java, а часть -- на C++. При этом наиболее математическо ёмкая часть проекта будет писаться на C++. Я хотел бы узнать, почему считается, что математические вычисления лучше всего писать на C++, а не на Java или C#? Потому что в C++ есть тип long double (наряду с double и float), а в Java -- только double и float?


Потому, что С++ часть потом можно будет переписать на ассемблере (SSE и пр). А явовскую часть — нет.
Кроме того, есть ещё и доступ к массивам, который в яве, увы, однозначно медленее и менее удобный для оптимизации.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[2]: Почему математику лучше писать на C++, чем на Java ил
От: iZEN СССР  
Дата: 14.10.09 16:36
Оценка: :)
Здравствуйте, mkizub, Вы писали:

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


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

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


Уверен?
С++ sucks
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
Re[8]: Почему математику лучше писать на C++, чем на Java ил
От: drol  
Дата: 23.10.09 22:28
Оценка: 4 (1) +1 -1
Здравствуйте, IID, Вы писали:

IID>А разве непонятно ?


Непонятно. Вы же на скорости настаиваете. Зачем тогда ограничивать участников в возможностях оптимизации ???

IID>Чтобы заставить язык поворочать данными.


Не смешите мои тапки. Поворочать данными — это запроцессить медиаконтейнер в 30Гб, а не елозить по жалкой сотне байт.

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


Как интересно. Вроде же ещё недавно Вы кричали что C/C++ быстрее ?

IID>В стандарте языка нет примитивов синхронизации.


Про что и базар. Так ещё раз спрашиваю — причём тут C++ тогда ???

IID>Насколько портабельный ?


У Вас проблемы с чтением ??? Вроде нормальным русским языком написано — "портабельный в рамках стандарта языка". Какие слова Вам непонятны ???

IID>Вариант для MSVC/GCC устроит ? Это легко достигается условной компиляцией.


Устроит код портабельный в пределах стандарта языка Чтобы везде где есть компилятор более-менее соответствующий стандарту работало без каких-либо модификаций. Хоть на DSP всяких, хоть на ARM, хоть на китайских чудо-юдах x86 over MIPS. Только в этом случае можно говорить о программе на языке C/C++.

IID>Если придираться к портабельности — то Mono далеко не полный аналог "некошерной reference-реализации", и при желании можно наклепать код, который не будет "отлично работать".


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

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


IID>"Платформозависимый код" и "ОС зависимый код" понятия не эквивалентные.


Да, Капитан Очевидность.

IID>И то, что "ОС — часть платформы" этот факт никак не отменяет.


Не отменяет. Это всего лишь определяет "ОС зависимость" как подмножество "платформозависимости".

D>>__sync_val_compare_and_swap


IID>Зависит от ОС.


Неправда. Это зависимость от конкретного компилятора, бо intrinsic. В MSVC++, например, такого intrinsic'а нет. Но есть другой — свой собственной с аналогичной функциональностью.

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

IID>Тоже самое, зависит от ОС.


Эти — да, ОС.

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


Тривиально портируется код на C#. Портирование же предложенного C/C++ кода требует перековыривания ручками почти всего. Если Вы опять желаете поупираться, пожалуйста — портируйте на MSVC++ и покажите diff

D>>Да легко


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


Вы так жаждите его посмотреть ? Пожалуйста:
using System;
using System.Threading;
using System.Text;
using System.Diagnostics;

using size_t = System.Int32;

public class chameneosredux
{
    public enum color_t
    {
        blue,
        red,
        yellow
    }

    private static color_t doCompliment(color_t c1, color_t c2)
    {
        switch (c1)
        {
            case color_t.blue:
                switch (c2)
                {
                    case color_t.blue: return color_t.blue;
                    case color_t.red: return color_t.yellow;
                    case color_t.yellow: return color_t.red;
                    default: break;
                }
                break;
            case color_t.red:
                switch (c2)
                {
                    case color_t.blue: return color_t.yellow;
                    case color_t.red: return color_t.red;
                    case color_t.yellow: return color_t.blue;
                    default: break;
                }
                break;
            case color_t.yellow:
                switch (c2)
                {
                    case color_t.blue: return color_t.red;
                    case color_t.red: return color_t.blue;
                    case color_t.yellow: return color_t.yellow;
                    default: break;
                }
                break;
            default: break;
        }
        throw new Exception();
    }

    private static void printColours()
    {
        printColours(color_t.blue, color_t.blue);
        printColours(color_t.blue, color_t.red);
        printColours(color_t.blue, color_t.yellow);
        printColours(color_t.red, color_t.blue);
        printColours(color_t.red, color_t.red);
        printColours(color_t.red, color_t.yellow);
        printColours(color_t.yellow, color_t.blue);
        printColours(color_t.yellow, color_t.red);
        printColours(color_t.yellow, color_t.yellow);
    }

    private static void printColours(color_t c1, color_t c2)
    {
        Console.WriteLine(c1 + " + " + c2 + " -> " + doCompliment(c1, c2));
    }

    private static String[] NUMBERS = {
      "zero", "one", "two", "three", "four", "five",
      "six", "seven", "eight", "nine"
   };

    private static String getNumber(int n)
    {
        StringBuilder sb = new StringBuilder();
        String nStr = n.ToString();
        for (int i = 0; i < nStr.Length; i++)
        {
            sb.Append(" ");
            sb.Append(NUMBERS[(int)Char.GetNumericValue(nStr[i])]);
        }

        return sb.ToString();
    }

    class meeting_place_t
    {
        public volatile Int32 state;
    }

    class chameneos_t
    {
        public color_t color;
        public size_t meet_count;
        public size_t meet_same_count;
        public volatile bool meeting_completed;
        public meeting_place_t place;
        public chameneos_t[] chameneosAll;
        public int id;
        public bool is_smp;

        public IntPtr affinity;

        const int CHAMENEOS_IDX_MASK = 0xFF;

        [System.Runtime.InteropServices.DllImport("kernel32")]
        static extern int GetCurrentThreadId();

        public void run()
        {
            //struct chameneos_t*         chameneos;
            //struct chameneos_t**        chameneoses;
            //struct chameneos_t*         peer;
            //size_t                      my_id;
            //size_t                      is_same;
            //size_t                      spin_count;
            //uintptr_t volatile*         state_p;
            //uintptr_t                   state;
            //uintptr_t                   peer_idx;
            //uintptr_t                   xchg;
            //uintptr_t                   prev;
            //enum color_t                new_color;
            //int                         is_smp;


            if (IntPtr.Zero != affinity)
            {
                var tid = GetCurrentThreadId();
                foreach (ProcessThread p in Process.GetCurrentProcess().Threads)
                {
                    if (p.Id != tid) { continue; }
                    
                    p.ProcessorAffinity = affinity;
                    break;
                }
            }

            var chameneos = this;
            var chameneoses = chameneos.chameneosAll;

            //state_p = &chameneos->place->state;

            var my_id = chameneos.id;
            var is_smp = chameneos.is_smp;

            var state = chameneos.place.state;
            for (; ; )
            {
                int xchg;
                var peer_idx = state & CHAMENEOS_IDX_MASK;
                if (0 != peer_idx)
                    xchg = state - peer_idx - (1 << MEET_COUNT_SHIFT);
                else if (0 != state)
                    xchg = state | my_id;
                else
                    break;

                var prev = Interlocked.CompareExchange(ref chameneos.place.state, xchg, state);

                //prev = __sync_val_compare_and_swap(state_p, state, xchg);
                if (prev == state)
                {
                    if (0 != peer_idx)
                    {
                        var is_same = (peer_idx == my_id) ? 1 : 0;
                        var peer = chameneoses[peer_idx - 1];
                        var new_color = doCompliment(chameneos.color, peer.color);
                        peer.color = new_color;
                        peer.meet_count += 1;
                        peer.meet_same_count += is_same;
                        peer.meeting_completed = true;
                        chameneos.color = new_color;
                        chameneos.meet_count += 1;
                        chameneos.meet_same_count += is_same;
                    }
                    else
                    {
                        //if (is_smp)
                        //{
                            var spin_count = 20000;
                            while (!chameneos.meeting_completed)
                            {
                                if (0 != spin_count)
                                    spin_count--;
                                else
                                    //sched_yield();
                                    Thread.Sleep(0);
                            }
                        //}
                        //else
                        //{
                        //    while (!chameneos.meeting_completed)
                        //    {
                        //        //sched_yield();
                        //        Thread.Sleep(0);
                        //    }
                        //}
                        chameneos.meeting_completed = false;
                        state = chameneos.place.state;
                    }
                }
                else
                {
                    state = prev;
                }
            }
        }
    }

    class ResultInit
    {
        public chameneos_t[] Creatures { get; set; }
        public Thread[] Threads { get; set; }
    }

    const int MEET_COUNT_SHIFT = 8;
    static ResultInit init_and_start(Int32 meet_count, IntPtr affinity, params color_t[] colours)
    {
        meeting_place_t place = new meeting_place_t();
        place.state = meet_count << MEET_COUNT_SHIFT;
        chameneos_t[] creatures = new chameneos_t[colours.Length];
        for (int i = 0; i < colours.Length; i++)
        {
            Console.Write(" " + colours[i]);
            creatures[i] = new chameneos_t();
            creatures[i].place = place;
            creatures[i].color = colours[i];
            creatures[i].id = i + 1;
            creatures[i].is_smp = false;
            creatures[i].meet_count = 0;
            creatures[i].meet_same_count = 0;
            creatures[i].meeting_completed = false;
            creatures[i].chameneosAll = creatures;
            creatures[i].affinity = affinity;
        }
        Console.WriteLine();

        Thread[] ts = new Thread[creatures.Length];
        for (int i = 0; i < creatures.Length; i++)
        {
            ts[i] = new Thread(creatures[i].run);
            ts[i].Start();
        }

        //if (is_smp)
        //    pthread_attr_setaffinity_np(&chameneos[0][i]->thread_attr,
        //        sizeof(cpu_set_t), affinity);



        return new ResultInit() { Creatures = creatures, Threads = ts };
    }

    static void join_and_output(chameneos_t[] creatures, Thread[] threads)
    {
        foreach (var thread in threads)
        {
            thread.Join();
        }

        int total_meet_count = 0;
        foreach (var cham in creatures)
        {
            total_meet_count += cham.meet_count;
            Console.WriteLine("{0}{1}", cham.meet_count, getNumber(cham.meet_same_count));
        }
        Console.WriteLine(getNumber(total_meet_count));
        Console.WriteLine();
    }

    class ResultHardwareInfo
    {
        public bool IsSMP { get; set; }
    }

    static ResultHardwareInfo GetHardwareInfo()
    {
        var smp = System.Environment.ProcessorCount > 1;
        if (smp)
        {
            //
        }

        return new ResultHardwareInfo() { IsSMP = smp };
    }

    [MTAThread]
    public static void Main(String[] args)
    {
        var sw = new Stopwatch();
        sw.Start();

        Int32 n = 6000000;
        if (args.Length > 0)
            n = Int32.Parse(args[0]);

        printColours();
        Console.WriteLine();

        //    get_affinity(&is_smp, &affinity1, &affinity2);

        bool is_smp = false;

        //if (is_smp)
        //{

        var r1 = init_and_start(n, (IntPtr)(1 + 2), color_t.blue, color_t.red, color_t.yellow);
        var r2 = init_and_start(n, (IntPtr)(4 + 8), color_t.blue, color_t.red, color_t.yellow, color_t.red, color_t.yellow,
          color_t.blue, color_t.red, color_t.yellow, color_t.red, color_t.blue);

        join_and_output(r1.Creatures, r1.Threads);
        join_and_output(r2.Creatures, r2.Threads);

        //}
        //else
        //{

        //var r1 = init_and_start(n, IntPtr.Zero, color_t.blue, color_t.red, color_t.yellow);
        //join_and_output(r1.Creatures, r1.Threads);

        //var r2 = init_and_start(n, IntPtr.Zero, color_t.blue, color_t.red, color_t.yellow, color_t.red, color_t.yellow,
        //  color_t.blue, color_t.red, color_t.yellow, color_t.red, color_t.blue);
        //join_and_output(r2.Creatures, r2.Threads);

        //}

        sw.Stop();
        Console.WriteLine();
        Console.WriteLine("Stopwatch.IsHighResolution = {0}", System.Diagnostics.Stopwatch.IsHighResolution);
        Console.WriteLine("Elapsed {0} milliseconds", sw.ElapsedMilliseconds);
    }
}
Код грубый, со всяким хардкодингом, за корректность зуб не дам и т.д. Желающие могут доточить

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


IID>А чего не хватает в C# ?


"Не хватает" относительно C# я не совсем верно употребил. Это у C++ не хватает А у нас — отсутствует за ненадобностью

IID>Всей реализации хамелеонов целиком ?


Типа того. Когда управляемому коду действительно требуются какие-то специфичные платформозависимые тараканы — берётся interop или C++/CLI. И все счастливы.

IID>Тогда, простите, что останется от C#, если мы будем сравнивать С++ и С++.


То же самое, что остаётся от C++, когда Вы начинаете херачить налево и направо intrinsic'и, да вызовы ОС

IID>Джентльменам верят на слово ?


Конечно Я вот вполне верю цифири опубликованной на сайте "турнира", например. Именно по этой самой причине.

IID>Непонятно, почему до "добавления привязки" (кстати, что за привязка ?)


Установка оптимальной processor affinity mask для нативных потоков исполняющих соответствующие управляемые потоки.

*Так стало яснее ?

IID>выигрыш был всего двукратным ? Напоминаю, перенос опубликованной


У Вас точно затруднения с русским языком В моём постинге написано — "даёт двухкратный рост производительности в сравнении с выполнением опубликованного C# кода". По-моему вполне понятно, что прирост не относительно цифири с сайта, а относительно результатов исполнения кода с сайта у меня.

IID>C# реализации с моно на компилятор C# от MS дал сразу 4-х кратный прирост производительности.


На моей системе прирост получился меньшим чем на Вашей => ~18 секунд исполнялось. Правда у меня куча барахла в background'е постоянно вертится + коммит превышает физическую память в полтора раза

IID>Хочу увидеть C# реализацию, где разрыв уменьшился хотя бы до 5 раз.


Вот мой порт такой и есть, и даже лучше => ~2.7 секунды.

IID>Тогда будет иметь смысл и портабельность сделать.


Условная компиляция — это другая портабельность.

IID>И взять Intel С++ Compiler.


Да не будет в этом никакого смысла. Результат уже давно на лице. Чтобы превзойти чемпионскую программу на Haskell'е, сообществу C/C++ потребовался такой мегагуру нативных concurrency и параллелизма как (много)уважаемый remark. Все же остальные представители "расово верного языка" слили по-полной.

Всё это показывает очевидную закономерность — для C/C++ производительность кода определяется не языком, а прежде всего личностью того, кто этот код пишет. И типичный представитель лагеря C/C++ ничего действительно производительного наваять не может, бо малограмотен и неквалифицирован
Re[7]: Почему математику лучше писать на C++, чем на Java ил
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.10.09 23:33
Оценка:
Здравствуйте, drol, Вы писали:

В дальнейшем, пожалуйста, воздержись от личных наездов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1249 on Windows 7 6.1.7600.0>>
AVK Blog
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.