Delphi 8 - Первые впечатления , Шаг вперёд - два шага назад?

Цитата Andr,2.09.04, 17:26

2 mike
1. Есть оптимизация методов под конкрентный процессор, и скорость повышается.

Вот тут я возможно действительно не догоняю, а хотел бы разобраться: так каким образом работает компилятор .NET: действительно как компилятор (т.е. создает машинный код) или как транслятор (т.е. вызывает код только отдельных методов)?

2 mike

Цитата

Цитата

Есть оптимизация методов под конкрентный процессор, и скорость повышается.

Вот тут я возможно действительно не догоняю, а хотел бы разобраться: так каким образом работает компилятор .NET: действительно как компилятор (т.е. создает машинный код) или как транслятор (т.е. вызывает код только отдельных методов)?

Все просто:
1. Мы пишем программу в среде разработки (например, VS .NET 2003 или Delphi 8 .NET).
2. Собираем (в Delphi 8 это: Project|Build) нашу программу. Компилятор, поставляемый со средой разработки, компилирует весь исходный код в IL-код общеязыковой среды.
3. Запускаем нашу программу:
3.1. перед первым вызовом каждого из вызываемых в программе методов метод компилируется в машинный код (оптимальный для процессора, который установлен в компе) и и остается о ОЗУ до завершения программы.
3.2. если какой-либо метод ни разу не вызывается в программе, то он и не компилируется в машинный код во время выполнения.

2 Song

Цитата

code=cpp

Что это? Я не в курсе.

Andr,
Вот это что такое по твоему?



Для кого оно по-твоему пишется вверху в красной рамке!?
Когда глаза последний раз мыл?

M

Флуд пошёл! Предупреждения начать раздавать или сами прекратите?

Извиняюсь, конечно может и не по теме, но меня очень интересует вопрос, на что мне отдать своё предпочтение? ПС, можно поставить D8 к уже стоящей D7 чтоб ничё не закосячить?

Извиняюсь, такой вопрос уже был, сорь...

Слушай, Andr, хватит мозги пудрить. Сначала у тебя там счетчики объекты, потом это всё как-то запихивается в регистр cx, используется "очень быстрая" loop. Приплёл уже туда какие-то недостатки циклов С.

Вот, опять, специально для тебя:

 
#include <iostream>
#include <time.h>
#include <conio.h>
 
static void test_func()
{
    clock_t begin = clock();
    __asm {
        mov ecx, 100000000;
m1:
        loop m1;
    }
    std::cout << "Test 1: " << (clock() - begin) << std::endl;
}
 
static void test_func3() {
    clock_t begin = clock();
    __asm {
        mov eax, 100000000;
m1:
        dec eax;
        cmp eax, 0;
        jne m1
    }
    std::cout << "Test 2: " << (clock() - begin) << std::endl;
}
 
 
void main() {
    test_func();
    test_func3();
    std::cout.flush();
    getch();
}

На моём компе первая функция: 911, вторая: 460.
Да к твоему сведению, аналог приведённого тобой кода на С++, скомпилированный на любом приличном компиляторе (например VC++), будет выполняться 0, просто потому, что компиллер выкинет нафиг этот цикл.
Проверь лучше, что твой пример на D8 действительно компилируется с использованием .Net.

И ещё: если поменять во второй функции так, чтоб счетчик возрастал, ничего не изменится.

Сообщение отредактировано: Sanek - 13.09.04, 21:50

Sanek,

мой

Цитата

пример на D8 действительно компилируется с использованием .Net

по той простой причине, что D8 способна компилировать исполняемые файлы только под .NET Framework 1.1.

Я не знаю конкретно, почему в твоем примере вариант цикла с loop выполняется дольше. Это предмет исследования.
Но я знаю, что в системе команд x86 команда loop предусмотрена для создания более быстрых счетчиком цикла (ну, и, попутно, для более простого написания кода этого цикла).

И еще. Я не спорю, что на данный момент .NET/C#-проги выполняются медленнее. Версия 1.1 - это пробный шар. Когда выйдет .NET 2.0 - это и будет момент истины: станет ли технология .NET массовой (и быстрой).

Считаю, что у .NET есть очевидные (и неочевидные тоже, но очень важные) приемущества над всеми остальными технологиями и предпосылки для успеха.

Сообщение отредактировано: Andr .NET - 14.09.04, 11:11

Цитата

по той простой причине, что D8 способна компилировать исполняемые файлы только под .NET Framework 1.1.

Так то оно так, но на форуме тут писали:

Цитата

Столкнулся с интересной штукой:

Создаю новый проект /File/New/VCL Forms Application
Получаю проект с пустой формой.
Сохраняю его.
Собираю /Project/Build Project1
После сборки заглядываю в папку проекта и вижу:

Project1.exe 1,348,096

Добавляю на форму кнопку (TButton).
Сохраняю, собираю, заглядываю в папку проекта и вижу:

Project1.exe 8,192

Кто-нибудь знает, почему размер файла резко сократился ?
И какого лешего он вообще изначально 1,3 мега "весил" ?

Кстати, может обяснишь, из-за чего такое было?

По поводу команды loop у меня есть догадки, но я не спец в этом деле, это надо в раздел по asm к системщикам .

Так я о том и говорю, что по крайней мере в ближайшее время .Net использовать не собираюсь точно. Как выйдет 2.0, так и посмотрим. Хотя сомневаюсь, что что-то изменится очень сильно.
Считаю, что рассмотреть переход на .Net можно программирующим на VB и Java. А остальным пока не дёргаться.

Уважаемый Andr! Ваш пример не впечатляет, поскольку используется пустой цикл. Оптимизатор кода может быть достаточно умен, чтобы поместить счетчик в регистр процессора и тогда сравнение двух програм сводится к сравнению скорости работы функций вывода на консоль, а это не совсем то, что интересует (вывод результатов выполняется один раз по окончании работы и разница в милисекунды здесь крайне не существенна). Попробуйте, пожалуйста, вставить в цикл какие-либо математические действия, вычисления факториала, например.
Для меня вопрос производительности крайне актуален. Я занимаюсь моделированием и оптимизацией технологических процессов: составление и решение систем 15-20 тысяч уравнений, перебор большого числа вариантов. Соответственно есть циклы в циклах, рекурсии и активная работа с динамической памятью (поскольку в разных вариантах разный объем данных).
Понятно, что чудес не бывает. Больше универсальности/навороченности достигается за счет объема/производительности. Но одно дело, если производительность ухудшается на проценты - да, тогда предпочтем более современный и навороченный интерфейс (в свое время Delphi был принят на ура благодаря возможности сократить до минимума время создания пользовательского интерфейса и сконцентрировать усилия на решении технологических задач). Но если идет замедление в разы, то тогда лучше остаться на морально устаревшем и архитектурно никудышнем WinAPI. Или, дабы не быть задавленным толпой бегущих в .NET программистов ( ), отскочить в сторону юниксов.

Цитата Sanek @ 14.09.04, 17:19

Считаю, что рассмотреть переход на .Net можно программирующим на VB и Java. А остальным пока не дёргаться.

Насчет VB согласен, а вот насчет Java имхо переход на .Net может и даст ряд положительных моментов, но при этом пропадет многоплатформенность а с ней и большой кусок рынка ПО. Лично я плохо себе представляю разработку ПО под Sun Solaris, которое будет написано для платформы .Net, а клиенту будет предлагаться погеммороиться с Open Source Memo.

Sanek,

Цитата

Так то оно так, но на форуме тут писали:

Цитата

Столкнулся с интересной штукой:

Создаю новый проект /File/New/VCL Forms Application
Получаю проект с пустой формой.
Сохраняю его.
Собираю /Project/Build Project1
После сборки заглядываю в папку проекта и вижу:

Project1.exe 1,348,096

Добавляю на форму кнопку (TButton).
Сохраняю, собираю, заглядываю в папку проекта и вижу:

Project1.exe 8,192

Кто-нибудь знает, почему размер файла резко сократился ?
И какого лешего он вообще изначально 1,3 мега "весил" ?

Кстати, может обяснишь, из-за чего такое было?

По этому поводу могу дать исчерпывающий ответ:

1. В D8 можно создавать VCL .NET-приложения. Эта технология позволяет создавать .NET-приложения, но использующие внешний неуправляемый код: компоненты VCL .NET построены на вызовах функций WinAPI.
В состав технологии VCL .NET входят пространства имен Borland.Vcl.* (например, Borland.Vcl.Windows, Borland.Vcl.SysUtils).

2. Создадим пустой проект VCL .NET и скомпилируем его. Посмотрим на диалоговое окно, появляющееся при нажатии Project|Information for <Project Name>. Тут мы увидим, что размер файла 1,3M, но списке динамических библиотек, необходимых для выполнения нашего проекта, отсутствуют Borland.Vcl.*.

3. Положим Button на форму нашего проекта. Опять скомпилируем. Жмем Project|Information for <Project Name>. Размер файла стал 8K, но при этом в списке необходимых библиотек появились несколько Borland.Vcl.*!

4. Из пп. 2 и 3 следует, что компилятор сам решает, поместить ли используемый код из библиотек Borland.Vcl.* в исполняемый файл проекта, или подключать эти библиотеки во время выполнения.
Если D <= 7 можно было управлять этим самостоятельно, то D8 этим вопросом заведует исключительно компилятор.
Понячалу меня это раздражало, но потом я прочитал в справке, что VCL .NET не рекомендуется использовать для создания новых проектов, а рекомендуется только для поддержки старых.

В приведенном примере для оценки производительности счетчика я не подключал ни одного пространства имен Borland.Vcl.*.
Однако если бы я использовал VCL .NET, то код, написанный мной собственноручно, все равно был-бы .NET-овским.

Цитата

Да к твоему сведению, аналог приведённого тобой кода на С++, скомпилированный на любом приличном компиляторе (например VC++), будет выполняться 0, просто потому, что компиллер выкинет нафиг этот цикл.

А если в качестве начального и/или конечного значений счетчика будут не константы, а функции?

Цитата

Считаю, что рассмотреть переход на .Net можно программирующим на VB и Java. А остальным пока не дёргаться.

Мне кажется, что Java-программистам пока можно не дергаться. Java - в чистом виде виртуальная машина, переносимая на любую платформу, а потому с ограниченными возможностями с точки зрения системной работы.

Думаю, что .NET должен быть интересен как раз "традиционным" программистам. О преимуществах .NET я уж много писал ранее.

Единственный камень преткновения - производительность.

Sanek, Guest, подождем выхода .NET 2.0: Microsoft обещает, что производительность C#.NET-кода будет всего на 3-5% ниже, чем производительность чистого C++/Win32-кода.

Сообщение отредактировано: Andr .NET - 15.09.04, 05:33

Цитата

А если в качестве начального и/или конечного значений счетчика будут не константы, а функции?

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

Про Java: я имел в виду про тех кто программит вод Win

позволю себе также несколько замечаний

Цитата

Считаю, что у .NET есть очевидные (и неочевидные тоже, но очень важные) приемущества над всеми остальными технологиями и предпосылки для успеха.

это как бы очевидно, как очевидно и то, что данная мысль легко асоциируется с чем угодно помимо .Net, так как у всех есть преимущества, равно как и недостатки.

Цитата

А если в качестве начального и/или конечного значений счетчика будут не константы, а функции?

и после этого Вы мне будете рассказывать о том, что в .Net все оптимизируется под конкретную конфигурацию и это прекрасно?

Цитата

подождем выхода .NET 2.0: Microsoft обещает, что производительность C#.NET-кода будет всего на 3-5% ниже, чем производительность чистого C++/Win32-кода.

только вот еще надо бы господам из MS добавить на какой конфигурации. Думаю, P4 не меньше

опять же о оптимизации. При запуске все затачивается под мою систему. Оптимизируется код для "конкретного моего" процессора, невызываемые функции вообще в код не включаются (всеми нами используемым борланским компилятором также неиспользуемые ф-ции в код не включаются) и т.д. и производительность всего на 3-5% НИЖЕ. Нормально... У Вас нет чувства, что где-то Вас кидают? Я всю жизнь думал, что оптимизация имеет смысл когда она приводит к ПОВЫШЕНИЮ производительности. Конечно, зачем нам эти одинаковые экзешники на разных компах... Они же не оптимизированы под каждую конкретную машину! Толи дело в Net, на каждой машине приложение оптимизировано, и всего на 5% медленнее. Это даже не смешной довод в пользу Net - это глупый довод.

А если учесть, что с .Net писать программы

Цитата

проще и приятнее

то я могу себе представить как они будт работать. Кривой алгоритм никакой компилятор не оптимизирует.

Дюжину с лишним страниц написали в этой ветке, а в чем суть?

Кто-нибудь уверовал в то, что используя .Net программа будет разработана быстрее, работать будет лучше (если будет лучше, то чем), работать с ней будет легче, еще какие-то преимущества, чем если-бы ее писали в Delphi или BCB или там яве какой-нить?

Цитата

H.Iglesias II: и производительность всего на 3-5% НИЖЕ. Нормально... У Вас нет чувства, что где-то Вас кидают? Я всю жизнь думал, что оптимизация имеет смысл когда она приводит к ПОВЫШЕНИЮ производительности.

Ответ до смешного прост. Если бы не было оптимизации, то производительность была бы еще ниже.
Но потеря 3-5% производительности - ерудна по сравнению с новыми преимуществами. Другое дело, что кто-то может не захотеть их познать, но это его дело...

Никто же не будет отрицать, что программы, написанные на на Delphi или C++Builder медленнее, чем Pure-Win32-проги (скажем, написанные, в Boorland C++ 5.02). Но почему-то основная масса народу пишет именно на Delphi/C++Builder/Visual Studio.

Кстати, разработчики FAR'а в свое время отказались писать на C++Builder из-за тормознутости написанных на нем прог (версия 1.70b3 в качестве эксперитента была написана на C++Builder, в 1.70b4 опять вернулись к Borland C++ 5.02).
Но FAR не относится к классу наиболее распространенных программ - это своего рода исключение.

Сообщение отредактировано: Andr .NET - 15.09.04, 13:32