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

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

IT>>>Т.е. можно говорить только о проблеме потребления ресурсов, но никак не о быстродействии. В конце концов оптимизаторы и для C# и для C++ писались одной и той же конторой
HD>>Не для Ц++, а для Вижуал Ц++...
HD>>есть реализации Ц++, которыые к Ц#и близко не стояли по быстродействию

VD>Глословный треп. Один из самых быстрых компиляторов VC7. Даже он не так далек от шарпа. А современем (когда у MS найдется время на вылизывание оптимизатора для .NET-рантайм и MS добавит в Шарп шаблоны) Шарп вооб может начать создавать самый быстрый код.

Я же не говорил, что все варианты Ц++ медленнее Ц# по результатам ВСЕХ тестов здесь

Автор(ы): Владислав Чистяков

и следующих статьях, мы видим, что bcb проигрывает Ц# в тесте сложения строк в 10 (!!!!!) раз...
я хотел сказать, всего лишь, что не стоит кричать, что Ц# намного медленнее, чем Ц++. на это можно лишь возразить, что все зависит от задачи.
Можно на ассемблере написать реализацию кода, которая будет работать медленнее, чем то же самое, написаное на VB, даже при отсутствии оптимизатора в последнем — вопрос реализации.
А уж Ц# написан весьма неплохо и производительность у него неплохая (да, согласен, грузится медленно, но попробуйте выкинуть все из ЕХЕ в ДЛЛ так, чтобы Ц++ код был того же размера — и поглядим, как долго он будет подниматься и устанавливать все связи (если они не статически линкуются)
так что, это не было наездом на Ц++ — это были слолва в пользу Ц#

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

VD>Здравствуйте Кодт, Вы писали:

К>>Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.

VD>Это не шутка. Первая версия виндов (вернее даже гуевой библиотеки) как раз на паскале и была.

самое забавное, что по умолчанию считается, что надо использовать паскалевский вызов для функций, которые экспортируются из DLL (pascal) правда сейчас его заменили на stdcall, но, блин, мы же все помним, что это — паскальный вызов
и в старых компиляторах заголовки были типа BOOL PASCAL dgflsdh(ssdkfh inin, ufbeub rfer, eife *dfef);
так что действительно не щютка

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

К>>>Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.

VD>>Это не шутка. Первая версия виндов (вернее даже гуевой библиотеки) как раз на паскале и была.

HD>самое забавное, что по умолчанию считается, что надо использовать паскалевский вызов для функций, которые экспортируются из DLL (pascal) правда сейчас его заменили на stdcall, но, блин, мы же все помним, что это — паскальный вызов
HD>и в старых компиляторах заголовки были типа BOOL PASCAL dgflsdh(ssdkfh inin, ufbeub rfer, eife *dfef);
HD>так что действительно не щютка

От "паскалевских" stdcall'ов меньше код раздувается (что когда-то было критично), только и всего. Потому они в системных библиотеках и юзаются.

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

К>>Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.

VD>Это не шутка. Первая версия виндов (вернее даже гуевой библиотеки) как раз на паскале и была.

Во. Еще один человек это утверждает. Откуда дровишки, где-нибудь в сети тому подтверждение осталось?

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

статьях, мы видим, что bcb проигрывает Ц# в тесте сложения строк в 10 (!!!!!) раз...
HD>я хотел сказать, всего лишь, что не стоит кричать, что Ц# намного медленнее, чем Ц++. на это можно лишь возразить, что все зависит от задачи.

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

Вот возьмем например простейший вариант: сортировка массива. Там присутствует большое количество обращение к элементам массива. C++ никак не контролирует программиста, обратился за границу — undefined behavior. Тогда как C# и Java не могут себе это позволить, и поэтому каждое обращение внутри имеет проверку на границы массива(на верхнюю и нижнюю). В результате получается что обращение к элементу массива будет в 3 раза медленнее. Вот тебе и замедление. Сортировка в отличие от поиска простых чисел используется почти везде.

И объясните мне pls как ваш C# собирается догонять C++ в данном случае.

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

S>Во. Еще один человек это утверждает. Откуда дровишки, где-нибудь в сети тому подтверждение осталось?

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

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

HD>так что, это не было наездом на Ц++ — это были слолва в пользу Ц#

Ну, на С++ тоже наезжать не стоит. Ты ведь сам сказал, что все зависит от задачи... Я бы перефразировал: от ее реализации.

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

A>Видишь ли все ваши тесты они неестественные, Java ищет простые числа с такой же скоростью как и C++ ну и что, зато она сильно отстает в алгоритмах которые требуют минимального пробега по памяти, а таких извини большинство.

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

A>Вот возьмем например простейший вариант: сортировка массива. Там присутствует большое количество обращение к элементам массива.

Скорее всего отставание объясняется слишком тупым алгоритмом проверки выхода за пределы массива. Это исправимо (как доказал тот же Шарп). Но в текущей реализации не исправленно.


HD>C++ никак не контролирует программиста, обратился за границу — undefined behavior.

В VC7 проверка границ массива тоже встроена, но опционально. В шапре тоже есть ансэйф-режим в котором нет контроля, но и в нем Шарп отстал от С++. Так что видимо дело в оптимизации.

HD>Тогда как C# и Java не могут себе это позволить

Шарп может.

HD>, и поэтому каждое обращение внутри имеет проверку на границы массива(на верхнюю и нижнюю). В результате получается что обращение к элементу массива будет в 3 раза медленнее. Вот тебе и замедление. Сортировка в отличие от поиска простых чисел используется почти везде.

Заметь результат сортировки Шарпа даже в обычном режиме очень даже ничего. Можешь сравнить их с результатом qsort из CRT. Уверяю тебя что qsort проиграет (по крайней мере в реализации MS из VC6).

A>И объясните мне pls как ваш C# собирается догонять C++ в данном случае.

Элементарно. Оптимизируют оптимизатор. Тот начнет реально выдавать инструкции для новых процесоров и С++ (вернее кодогенерация в стиле обычного С++) будет в анусе.

Основные проблемы Шарпа не в проверках границ массивов, а в отсуствии шаблонов. Это приводит к тому что любой общий алгоритм реализуется на виртуальных методах. А это тормоза (хотя и не критичные). Кстити, в С (который и сейчас является эталоном по скорости программ) полиморфизм достигался тоже за счет (псевдо-) виртуальных вызовов. Та же qsort тому доказательство. Она сильно проигрывает в скорости из-за того, что приходится делать вызов по адресу и передавать в функцию сравнения указатели.

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

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

HD>>так что, это не было наездом на Ц++ — это были слолва в пользу Ц#

VD>Ну, на С++ тоже наезжать не стоит. Ты ведь сам сказал, что все зависит от задачи... Я бы перефразировал: от ее реализации.

Как уже обсуждалось в флейме о Дельфи и от задачи — тоже... когда нужно написать программу, которая выводит на экран надпись "Hallo World!" — лучший выход это VB/Delphi/C#, т.е. компоненто-ориентированые системы с однопроходным (это важно !) компилятором (правда, про Ц# не уверен, но исходя из отсутствия макросов можно предположить ). Когда нужно написать программу под Intel x86, которая будет ОЧЕНЬ быстро искать прямым перебором (ну данные так устроены) данные в массиве int'ов — лучший выход — ассемблер, благо там для этого команда специальная есть. Так что от задачи тоже многое зависит.

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

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


IO>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).

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

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

IO>Ваши мнения?

Чесно говоря я бы хотел иметь такой язык програмирования где пишешь что хочешь (на русском например) и он это выполняет.

(С) Ленивый програмист Петька
ICQ: 70064374

Здравствуйте Аноним, Вы писали:

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

IO>>Ваши мнения?

А>Чесно говоря я бы хотел иметь такой язык програмирования где пишешь что хочешь (на русском например) и он это выполняет.

А я хочу чтобы он при этом еще выполнял то что я хочу, а не то что я написал

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

HD>>Тогда как C# и Java не могут себе это позволить

VD>Шарп может.

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

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

IO>>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).

U>Не обязательно, еще ставится дизель.

А что, двигатель Дизеля теперь стал двигателем внешнего сгорания?

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

A>А я хочу чтобы он при этом еще выполнял то что я хочу, а не то что я написал
... или подумал

А я хочу, чтобы он при этом еще выполнял то, чего хочет заказчик, а не чего хочу я.

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

A>Я в принципе верю что при пробеге по массиву оптимизатор
A>может заметить что индекс и так никогда за массив не вылезит,
A>но в более менее сложном случае он разобраться не сможет

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

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

HD>Когда нужно написать программу под Intel x86, которая будет ОЧЕНЬ быстро искать прямым перебором (ну данные так устроены) данные в массиве int'ов — лучший выход — ассемблер

Бред натуральный. Моежт данные отсорировать и хоть бинарным поиском воспользоваться? А там глядишь и VBScript в 100 раз шустрее асм-а окажетя.

HD>, благо там для этого команда специальная есть. Так что от задачи тоже многое зависит.

Переборы и циклы уже сто раз оптимизировалис компиляторами. Серьезного выигрыша (в разы) получить нельзя. Сегданя даже базовые алгоритмы на асм-е не пишут (бесполезно), а уж кусти прикладной логики на асм-е могут писать только его истенные ценители и в нерабочее время.

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

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

A>>А я хочу чтобы он при этом еще выполнял то что я хочу, а не то что я написал
Z>... или подумал

Z>А я хочу, чтобы он при этом еще выполнял то, чего хочет заказчик, а не чего хочу я.

Нет это в корне не правильный подход! Так ты и без работы остаться можешь

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

A>Нет это в корне неправильный подход! Так ты и без работы остаться можешь

А это будет приватный проект

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

VD>Если что есть ансэйф-код. Там ты можешь хоть по памяти кувалдой. Так что Шарп из любого положения может.

Объясни мне pls подробнее про unsafe код в C# что это вообще такое и как это согласуется с IL. Или линк кинь.