Здравствуйте, alexeiz, Вы писали:
A>Length все равно инлайнится.
Length — это псевдо-свойство. Реально у одномерного массива оно не существует. Вместо него вызывается специальная инструкция получения размера.
A>Проверено на практике, что вынос его за приделы массива ничего не дает.
Проверено, на практике замена Length на переменную дает некоторый выигрыш в скорости.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FractalizeR, Вы писали:
FR>>Сама среда .NET Runtime написана на C++, в критических по быстродействию местах на asm. Если не ошибаюсь, именно так утверждает Рихтер.
VD>Есть Моно на 99% написанный на Шарпе. В нем только базовые части рантайма написаны на С. Ассемблера нет вообще.
Не понял? Мне казалось, C# — язык исключительно для платформы .NET. И на нем нельзя написать саму платформу .NET. Или уже появились компиляторы с C# в Native код процессора сразу?
Здравствуйте, FractalizeR, Вы писали:
FR>Не понял? Мне казалось, C# — язык исключительно для платформы .NET.
Казалость.
FR> И на нем нельзя написать саму платформу .NET. Или уже появились компиляторы с C# в Native код процессора сразу?
Появились, но тут к делу это не относится. Вообще о .NET говорить не очень корректно, так как это торговая марка одной из реализаций CLI. Моно является другой реализацией CLI. Так вот, CLI имеет только одну проблему при старте нужно иметь кусок машинного кода который смог бы загрузить и скомпилировать менеджед код. Вот этот код и написан в Моно на С (около 200 С-файлов). Все остальное менеджед (около 10 000 файлов).
В общем-то такой стартап-код можно компилировать и на самом шарпе, так как нет ограничений на то, что Шарп обязан порождать только менеджед код. Да и можно использовать кросплатформный преджит. Вопрос в том, что такие решения это уже самоцель. Проще написать стартап-код на С.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FractalizeR, Вы писали:
FR>И еще кстати
FR>Все ведь зависит от того, как Microsoft Реализовала JIT. Ведь, например, компилятор может решить, что на данном процессоре данную IL команду можно транслировать в код, использующий MMX, SSE и т.д. Обычный же компилятор без указания этого делать не будет, поскольку полученный код может не работать на всех процессорах.
И будет и может самый обычный компилятор. Тот же Intel C уже умеет генерировать одновременнно код для разных процессоров и выбирать какой выполнять при запуске приложения.
Хм... Ссылок не дадите на компилятор C# в native код? Что-то с трудом верится... Вообще-то я не вижу смысла в реализации C# в не-managed среде.... Сборщик мусора нужно писать собственный, библиотеку классов какую-никакую, поскольку C# целиком и полностью полагается на .NET.
Все же, Microsoft .NET пока является единаственной полноценной средой, мне кажется... В Mono не реализовано много сборок, которые есть в Microsoft .NET. Хотя, Windows.Forms больше Microsoft'овское расширение наверное, но оно так и не реализовано. System.Drawing.Design тоже не реализовано.... Полноценной крос-платформенности пока нет....
дравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FractalizeR, Вы писали:
FR>>Не понял? Мне казалось, C# — язык исключительно для платформы .NET.
VD>Казалость.
FR>> И на нем нельзя написать саму платформу .NET. Или уже появились компиляторы с C# в Native код процессора сразу?
VD>Появились, но тут к делу это не относится. Вообще о .NET говорить не очень корректно, так как это торговая марка одной из реализаций CLI. Моно является другой реализацией CLI. Так вот, CLI имеет только одну проблему при старте нужно иметь кусок машинного кода который смог бы загрузить и скомпилировать менеджед код. Вот этот код и написан в Моно на С (около 200 С-файлов). Все остальное менеджед (около 10 000 файлов).
VD>В общем-то такой стартап-код можно компилировать и на самом шарпе, так как нет ограничений на то, что Шарп обязан порождать только менеджед код. Да и можно использовать кросплатформный преджит. Вопрос в том, что такие решения это уже самоцель. Проще написать стартап-код на С.
Здравствуйте, FractalizeR, Вы писали:
FR>Хм... Ссылок не дадите на компилятор C# в native код? Что-то с трудом верится... Вообще-то я не вижу смысла в реализации C# в не-managed среде.... Сборщик мусора нужно писать собственный, библиотеку классов какую-никакую, поскольку C# целиком и полностью полагается на .NET.
Кажется.
FR>В Mono не реализовано много сборок, которые есть в Microsoft .NET. Хотя, Windows.Forms больше Microsoft'овское расширение наверное, но оно так и не реализовано. System.Drawing.Design тоже не реализовано.... Полноценной крос-платформенности пока нет....
Windows.Forms не CLS-совместимо и использует море Виндовых контролов. По этому с его переносом и проблемы. А вот ASP.NET во всю работе.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FractalizeR, Вы писали:
FR>>Я бы сказал, что сильно снижает производительность упаковка и распаковка типов. Этот процесс хорошо описан в книге Джефри Рихтера. Думаю, прежде, чем писать критические алгоритмы на .NET языках, стоит ее прочесть.
VD>Разумеется, для того чтобы писать эффктивный код нужно знать платформу для которой он создается.
FR>>Кстати, зачем массив передавать как объект?
VD>Чтобы небыло граблей. В ансэйфе ты волен создавать массивы в стэке, но отвечать за проблемы будшь сам.
Не понимаю, о каких граблях идет речь? Разве запрещено передавать массив в качестве параметра методу?
FR>> Я недавно занимаюсь .NET, но оптимизирующий компилятор может представить массив int как базовый тип, а не как класс.
VD>Понятия "базовый тип" не существует в природе. Объект — это нечто размещаемое в стэке и имеющие 8 байт объектного оврехэда. В остальном же массив это такая же неприрывная область памяти. Никаких серьезных накладных расскходов не несущая.
Понятие Базовых типов (basic CLI types) определено в спецификации CLI Partition III на странице 1. Под накладными расходами я подразумевал упаковку и распаковку.
FR>> Кто-нибудь, кстати, сравнивал IL код этих двух кусков?
VD>Каких?
Тех кусков кода, о которых шла речь в ветке выше и по поводу производительности которых шла дискуссия.
FR>>ForEach тут и правда не подходит.
VD>Почему?
Потому, что медленно.
FR>> В цикле for сравнение с величиной можент происходить на кажой итерации (это ведь не Дельфи).
VD>Какой величиной? Зачем сравнивать?
В цикле for при каждой итерации может происходить сравнение с величиной конечного значения цикла. Если эта величина — простая переменная, такое сравнение будет выполняться быстрее, чем сравнение со значением, возвращаемым любой функцией, пусть она даже и inline компилирована.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, FractalizeR, Вы писали:
FR>>И еще кстати
FR>>Все ведь зависит от того, как Microsoft Реализовала JIT. Ведь, например, компилятор может решить, что на данном процессоре данную IL команду можно транслировать в код, использующий MMX, SSE и т.д. Обычный же компилятор без указания этого делать не будет, поскольку полученный код может не работать на всех процессорах.
FR>И будет и может самый обычный компилятор. Тот же Intel C уже умеет генерировать одновременнно код для разных процессоров и выбирать какой выполнять при запуске приложения.
Хм... Подскажите, пожалуйста, требуемое сочетание опций компилятора и его версию. Думаю, программа, скопилированная таким образом, занимала бы очень приличный объем....
AVK>>>Главный виновник — GC. Из-за него на этих платформах реализуемы только системы, время гарантированного отклика которых измеряется десяками секунд.
G>Можно написать и такой, который за все время работы программы ни разу не вызовется по неизветсным причинам. В том то и фишка, что ты практически не управляешь ресурсами. Память освобождается не тогда, когда тебе это надо, а тогда, когда это посчитает нужным сделать машина — т.е. гарантии никакой.
Здравствуйте, FractalizeR, Вы писали:
FR>>>Кстати, зачем массив передавать как объект?
VD>>Чтобы небыло граблей. В ансэйфе ты волен создавать массивы в стэке, но отвечать за проблемы будшь сам.
FR>Не понимаю, о каких граблях идет речь? Разве запрещено передавать массив в качестве параметра методу?
Которые размещены в стэке? Естественно. Ты можешь оперировать только указателями со всеми вытекающеми. Для того массивы и сделали объектом, чтобы их можно было лего передавать куда угодно, возвращать откуда угодно и сохранять где угодно не создавая потенциально ошибочного кода.
FR>Понятие Базовых типов (basic CLI types) определено в спецификации CLI Partition III на странице 1.
И все же это общее название. Рельно есть два основных класса (вэлью-типы и ссылочные типы) и только они оказывают влияние на размешение.
FR> Под накладными расходами я подразумевал упаковку и распаковку.
Ну, и причем тут базовые типы? Строка по-твоему какой тип? Но она ссылочный тип. А любая структура не базовый, но боксится.
Тут вообще нужно вести речь о неразумности полиморфной работы с влэлью-типами. А базовые они или нет дело десятое.
FR>>> Кто-нибудь, кстати, сравнивал IL код этих двух кусков?
VD>>Каких?
FR>Тех кусков кода, о которых шла речь в ветке выше и по поводу производительности которых шла дискуссия.
А смысл в них что-то высматривать? То что код довольно бредовый и так ясно. Хотя он то как раз довольно шстурый. Дело в том, что анбоксинг не такая уж и ресурсоемкая операция. Вот боксинг — это другое дело.
FR>>>ForEach тут и правда не подходит.
VD>>Почему?
FR>Потому, что медленно.
Ты ошибашся. Для массивов foreach всегда раскрывается в for аналогичный приведенным выше. Дла и для коллекций он не так уж не оптимален. Нужно иметь очень специфичный код, чтобы почувствовать эту неоптимальность.
FR>>> В цикле for сравнение с величиной можент происходить на кажой итерации (это ведь не Дельфи).
VD>>Какой величиной? Зачем сравнивать?
FR>В цикле for при каждой итерации может происходить сравнение с величиной конечного значения цикла. Если эта величина — простая переменная, такое сравнение будет выполняться быстрее, чем сравнение со значением, возвращаемым любой функцией, пусть она даже и inline компилирована.
Опять фигня. Если функция заинлайнилась, то разницы практически не будет. Сделай поиск по нашим форумам мы тут с Серджинио как-то обсуждали подобное. Я меу на примере доказал, что инлайнинг свойств по скорости ничем не отличим от прямого доступа к полям.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
FR>Хм... Подскажите, пожалуйста, требуемое сочетание опций компилятора и его версию. Думаю, программа, скопилированная таким образом, занимала бы очень приличный объем....
Runtime Support for Generations of Intel® Processors: Processor Dispatch (IA-32 processors only): Optionally build applications for a specific generation of Intel processor using processor dispatch. Dispatch now allows for multiple specific targets. Perform application development for the latest Intel processor — the Pentium 4 processor — while simultaneously maintaining the ability for the executable to run on previous IA-32 processors.
FR>>Все ведь зависит от того, как Microsoft Реализовала JIT. Ведь, например, компилятор может решить, что на данном процессоре данную IL команду можно транслировать в код, использующий MMX, SSE и т.д. Обычный же компилятор без указания этого делать не будет, поскольку полученный код может не работать на всех процессорах.
Эта фраза звучит от человека ни разу не видевшего ММХ и SSE, и не понимающего специализированность этих расширений команд. Они слишком спецефичны для использования и потому не могут использоваться компиляторами без напоминания
Пример:
Есть массив
BYTE a[0x4000];
BYTE b[0x4000];
BYTE c[0x4000];
и функция суммирует элементы массивов a и b и записывает результат в c. если переполнение, то записывается максимально возможное число(т.е 255)
Реализация без MMX
void nommx()
{
int i;
unsigned short t;
for (i = 0; i < 0x4000; i++)
{
t = a[i] + b[i]; //if (t > 255) //Ðåàëèçàöèÿ îïåðàöèè ñ íàñûùåíèåì
t = 255; //
c[i] = t;
}
}
Реализация с использованием MMX
void withmmx()
{
BYTE *pa, *pb, *pc;
int i;
pa = &a[0];
pb = &b[0];
pc = &c[0];
for (i = 0; i < 0x800; i++)
{
_asm{
movq mm0, [pa];
paddusb mm0, [pb];
movq [pc], mm0;
};
pa+=8;
pb+=8;
pc+=8;
}
_asm
{
emms;
}
}
для забивания гвоздя надо выбирать правильный микроскоп.
Здравствуйте, Слоноежик, Вы писали:
С>и функция суммирует элементы массивов a и b и записывает результат в c. если переполнение, то записывается максимально возможное число(т.е 255)...
Какова, кстати, разница в скорости на P4 и AMD64 по сравнению с неоптимизированным кодом?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
