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

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

Раньше в MSDN Magazine была колонка "Bugslayer" или что-то вроде того. В ней часто пубилковали разные баги.

Сейчас все еще проще. Заходим на http://lab.msdn.microsoft.com/productfeedback/ выделяем продукт "Visual C++" делаем поиск по слову "optimization" и получаем список багов.

Единственное, что возможно потребуется зарегистрироваться.

NC> и... может
NC>перенести это сообщение (и следующую за ним ветку) в форум о C++?

А смысл? Думашь там никто не знает?
99% комиляторов вообще не соблюдают стандарт на 100%. И я их понимаю.

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

NC>да, я видел сравнения, на RSDN тоже ситал статью — там сравниваются
NC>быстрые сортировки разными алгоритмами, на C# и для примера приведен еще
NC>и C++. Но раньше я не встречал ситуации, чтобы шарп оказался быстрее...
NC>сравнений между .NET и .NET2 честно скажу — даже не искал... просто
NC>инетресно было, вот и попробовал.

Гы. Я их и писал. Потому и делюсь своими ошибками.

А быстрее... медленее... Порядок приблизительно одинаков. А там уже как карта ляжет. В общем, на разницу до 20% можно смело забить.

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

NC>именно поэтому я и дал сначала эти элементарные алгоритмы проверить 2м
NC>другим программистам.

А куда проще было сделать коротенький тест.
Программисты тоже люди. Хотя это тоже полезно конечно.

>> Между тем написание теста обычно и минуты не занимает.
NC>я не умею так быстро набивать текст на клаве

Это дело наживное.

Да и для сортировки можно сделать очень простой тест. Что-то вроде:

static int _controlSum; // рассчитывается на несортированном массиве

void Test(int[] array)
{
  for (int i = 1, controlSum = array[0]; i < array.Lenth; i++)
    {
      Trace.Assert(array[i - 1] <= array[i]);
        controlSum += array[i];
    }
    
    Trace.Assert(controlSum == _controlSum);
}

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

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

NC>MS VS 7.1

Странно. VC-ятина как раз обычно в релизе шустрее компилирует, так как кор разной фигни не создает.

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

T>Простой пример: надо обменять два байта в слове, что в исходнике закодировано операцией $. Если выражать это на IL, то получится примерно так:

T>

T>
1. Сделать копию операнда
   T>
2. Копию сдвинуть влево, оригинал — вправо (оба с заполнением нулями)
   T>
3. OR на операнд и копию
   T>

T>А на x86 это делается одной командой SWAP.

T>Теперь разница есть?

Пока не заметно. А ты уверен, что SWAP будет быстрее, чем вышеприведеный набор команд эквивалентный SWAP-у? Не факт. А тебе знакомы концепции CISC и RISC? Так шта...

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

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

T>>Тогда прежде чем открывать свой рот по поводу моей компетентности, ты будешь у меня вежливо спрашивать, можно ли это делать. Вообще, довольно хамская привычка оценивать людей через пару фраз, м? Я пока ОТ ТЕБЯ ЛИЧНО не услышал ничего умного, посему не понимаю возмущений. Ближе к теме, меньше понтов, ага?

VD>Хотел забавнить но столь искрометного хамсва, и распухшего до небес самомнения еще не видел. Так что хочется поглядеть на продолжение.

VD>Излогайте дальше сэр! Ваши понты начинают не по детски прикалывать.

Ага, прикольно. Скорее всего, подросток забавляется с ассемблером просто потому, что это "ну очень круто". И соответственно считает себя приверженцем некой высшей касты. Я лабал на асме в 93-ем — вирусы для DOS писал.

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

K>> Представьте, что вы разрабатываете утилиту на с++ в течение года...

T>Ну если "год", то не такая уж это и "утилита"

T>Вы, видимо, несколько переоцениваете "ускоряющие" возможности C#. Скажу больше: ни ООП, ни ФП, ни прочие мозгозавихрения НЕ УСКОРЯЮТ разработки. Парадигма — это всего лишь ВЗГЛЯД на архитектуру программы. Если программа создаётся, она должна делать что-то НОВОЕ. И это новое НАДО ПИСАТЬ — хоть на чём, неважно.
T>Т.е. у программы всегда есть некий объективный минимум, быстрее которого просто НЕВОЗМОЖНО написать код. А в случае C# и C++ — вообще смех сравнивать, это почти одно и то же.

Между ними огромная разница. Разница не в языках — а в мощнейшей библиотеке классов C#

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

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

NC>>этот тест не предполагал какого-то полного, строгого тестирования двух
NC>>языков большим количеством народа, просто надо было быстренько сравнить
NC>>два языка (изначально C# и C#2) и писать придумывать для этого свой
NC>>алгоритм генерации случайных чисел, думаю, было бы нерационально

VD>На этот счет есть очень протсые решения которые можно найти за 5 минут на нашем же сайте.
VD>Например, Mab не наз приводил вот такое решение:
VD>

VD>class MyRandom
VD>{
VD>    int seed;

VD>    public int Next()
VD>    {
VD>        seed = (int) (seed * 214013L + 2531011L);
VD>        return (seed >> 16) & 0x7fff;
VD>    }
VD>}
VD>

VD>Проще не придумашь, а для целей тестирования более чем подходит.

Да в принципе, алгоритм псевдослучайной последовательности прост как три копейки. Я не думаю, что стандартные средства чем-то отличаются. Можно использовать и их. Эти же алгоритмы применяются для генерации белого шума и для алгоритмов симметричного шифрования — начальное значение seed — есть ключ.

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

___>Да в принципе, алгоритм псевдослучайной последовательности прост как три копейки. Я не думаю, что стандартные средства чем-то отличаются. Можно использовать и их. Эти же алгоритмы применяются для генерации белого шума и для алгоритмов симметричного шифрования — начальное значение seed — есть ключ.

Смысл эттго куска кода в другом. То, что линейный конгруэнтый метод генерации псевдослучайной последовательности прост -- это правда. Проблема в тестах была в том, что rand из C RTL (кстати, она ведь у каждого компилятора своя) и Random из FW имеют разные параметры генератора. А хотелось получить абсолютно идентичные тесты. Поэтому пришлось использовать самописный генератор во всех испытаниях. Константы из этого фрагмента я, кажется, из исходника RTL VC 8.0 выдернул.

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

VD>К тому же фанатам оптимизации нужно знать, что примитивные инструкции вроде movs на практике сегодня выигрыша не дают. Процесоры ведь давно разбивают их на примитивы.

Более того, на современных процах эти команды работают медленнее пары mov ax, [si]; mov [di], ax! Причина проста — movs не суперскалярен.

Вот ссылки любителям: здесь искать слово movs, отсюда цитата

For example, MOVSD uses both pipes, so no instruction can be executed in parallel with MOVSD.

The use of both pipes does make MOVSD nearly twice as fast on the Pentium as on the 486, but it's nonetheless slower than using equivalent simpler instructions that allow for superscalar execution.

Movs блокирует суперскалярность и выполняется "в эксклюзиве". За время его выполнения может выполниться большее число примитивных, но суперскалярных инструкций. Так что movs must die!

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

А>находится в регистре FLAGS
А>CF — флаг переноса. устанавливается если арифметич. операция вызвала перенос или заем из старшего бита результата

И какой командой на C++ можно проанализировать этот самый "флаг переноса"?

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

NC>на работе C++
Какой С++? Они бывают разные.

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

___>Ага, прикольно. Скорее всего, подросток забавляется с ассемблером просто потому, что это "ну очень круто". И соответственно считает себя приверженцем некой высшей касты. Я лабал на асме в 93-ем — вирусы для DOS писал.

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

Что до подростка, то это не наше дело. Бывают и 40-а и более летние дядки упертые по самые не хочу.
Что действительно подозрительно, в очередной раз это бывший Дельфист

Автор: Thornik
Дата: 21.04.06

. Ничего не хочу сазать против Дельфи или Дельфистов, но блин, уж больно часто среди Дельфистов и ВБшников появляются вот такие воинствующие личности позорящие не только себя, но и Дельфи/VB. Боюсь, что C# ждет тоже самое. Простота входа приводит к тому, что люди переоценивают себя и свои знания и считают, что заниматься серьезным самообучением не нужно. Зато прослеживается каке-то невероятное желание судить обовсем насвете не пытаясь разобраться в обсуждаемом предмете глубже.

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


VD>Думаю, что речь идет о фроцессоном флаге переполнения. Видимо товарищь считает, что он является неотемлемой частью С++.

Именно это и я хотел у него услышать и понять, как в С++ с ним можно работать
Просто хочется конкретных примеров, а то слова "native компилятор имеет код поэтому у него преимущества, а еще есть CF" не более чем треп Но человек упертый, только лозунги, никаких доказательств.

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

В>Именно это и я хотел у него услышать и понять, как в С++ с ним можно работать
В>Просто хочется конкретных примеров, а то слова "native компилятор имеет код поэтому у него преимущества, а еще есть CF" не более чем треп Но человек упертый, только лозунги, никаких доказательств.

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

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

VD>К тому же фанатам оптимизации нужно знать, что примитивные инструкции вроде movs на практике сегодня выигрыша не дают. Процесоры ведь давно разбивают их на примитивы.

Чушь полнейшая. Нечего они не разбивают.

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

А>Чушь полнейшая. Нечего они не разбивают.

Смелый мальчик. Умешь сказать нет из под анонимайзера.
Если это Thornik, то знай, ты разумно поступил, что залез из под анонимайзера. Так как выступления из бани караются баней по IP.

Здравствуйте, Andrbig, Вы писали:
A>И какой командой на C++ можно проанализировать этот самый "флаг переноса"?

естественно никакой. т.к. это платформенно-зависимый код. (под С++ подразумевается стандарт)

Тоже заинтересовался, взял из проекта небольшой парсер, переписал его на native-C++ с MFC (тиха тиха, сейчас объясню почему). Данные для парсера брал из одного и тогоже фалйла, и вот что получили:

.NET 2.0 — 3421 мс / ~86 Мб
C++ — 10224 мс / ~82 Мб

200 экземпляров парсеров в array, а что бы оптимизатор нечаянно не выринул расчеты, я у всех из массива вызывал функцию(она же и проверяла, что тектс на самом деле распарсен).
Созданиме массива и вызов функции — вне теста, в C++ — массив поинтеров, т.е. объекты не копируем, данные из файла так же читаются до теста. Никаких скоростных функций из FW не трогал. Созданные объекты не удалял. С++ — полная оптимизация на скорость. Теперь почему MFC — дело в том что меня интересует не пиковая скорость, которую можно выжать из С++, а реальная скорость, то есть код был написан в том стиле, как обычно пишется на C++ (в типичном проекте, без безумной оптимизации).
А, время замерялось в C++ timeGetTime(), в .NET через DateTime.Now (вот мож это и неправильно)

вотъ

> возможная кроссплатформенность

Не делайте мне смешно! Мелкомягкие заинтересованы ТОЛЬКО в Винде. Как максимум — использование своих утилит в Линуксе. В идеале — умерщвление Линукса.

ИМХО — не-а.
Почему то мне кажется что MS очень даж не против появлений .NET под Linux/Mac OS/разное, попой чую, хотят они этого, и уже не мало бабла вложили в технологию, и даже какие то свои продукты выпускают под Linux вроде, или мак, не помню, и с этоми продуктами идет кастрация от .NET, но что им мешает наваять взрослый фреймворк (когда он вырастит), туда? А потом продавать свои великолепные (Office, VS, прочее) ПО на вселенском рынке... А тем более тут даже запариваться не надо, линуесоиды за MS фреймворк перепишут, бесплатно..

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

T>Так вот... Я утверждаю, что первый транслятор сделает более оптимальный код, чем JIT-компилятор из Дотнета. Причина: JIT оперирует ГОТОВЫМИ КОМАНДАМИ, можно сказать даже почти ассемблером (см. пример по ссылке). Компилятор же в native команды имеет куда больше информации, чем JIT — он имеет ИСХОДНЫЙ КОД.

Вы правда думаете, что MSIL содержит меньше информации, чем исходные коды? А Reflector в таком случае получает исходный код по MSIL с помощью божественного откровения?
Понятно, что восстановленый код отличается от первоначального, но это из-за синтаксического сахарка. А сахарок он и есть сахарок. В чем принципиальная разница-то?
Вот и получается, что информации у JIT даже больше: полная информация о коде + информация об окружении. Можно оптимизировать под конкретный процессор, делать межсборочный инлайн etc.
По моему, об этом знают уже даже самые маленькие любители спорта.