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

2 encobalt

Цитата

Блин... а что с указателями-то делать ?!!
Я в тоске...

Указатели в .NET ЕСТЬ, только это называется "небезопасный код".

2 Sanek
Никто и не говорит, что переход на .NET - это так просто. Но переходить нужно, т.к. концепции, заложенные, например, в тот же COM, теперь закладываются в платформу, а это приводит:
- к более простому написанию программ (ессно, для этого .NET надо изучить);
- к более простой инетеграции программ;
- и главное, к гораздо более высокой стабильности программ.

По поводу полной переделки Delphi language. Причина не в том, что общеязыковая спецификация налагает требования, приводящие к коверкагию языка, а в том, что Delphi language никогда не являлся подлинно объектно-ориентированным языком (каковым является C++). В Delphi lang. не было:
1. Методов и свойств у записей (структур). А такие структуры (статические объекты без наследования) иногда очень полезны. Теперь они есть.
2. "Настоящих" private и protected секций. Теперь они есть: strict private, strict protected.
3. Статических полей у классов. Теперь они есть: объявляются как var.
4. Не было перегрузки операторов. Теперь они есть (class operator).
Первые 2 пункта меня всегда особенно тяготили.

2 Sanek, 2 mike

Цитата

Вот этого я не понимаю. Какая разница, из чего делать исполняемый код.

Риторический вопрос: не задумывались, почему Delphi делает промедуточные файлы dcu? Да так проще и оптимальнее через посредника делать оптимальный машинный код. Это утверждается разработчиками .NET.

2 Sanek

Цитата

Так как компиляция происходит во время выполнения, то на неё должно тратится минимальное количество времени. Вряд ли это будет самый оптимальный код.

Компиляция происходит не во время выполнения (как у виртуаьных машин), а ПЕРЕД ПЕРВЫМ ВЫЗОВОМ МЕТОДА. И компиляция выполняется С ОПТИМИЗАЦИЕЙ ПОД КОНКРЕНТНЫЙ ПРОЦЕССОР. Так утверждают разработчики .NET. Что же здесь не понятного.
Для слишком упертых: для пущего быстродействия можешь в момент старта программы вхолостую вызывать используемые метода, чтобы в момент "реального" вызова не тартить время на компиляцию.

Цитата

В Windows XP/Server 2003 есть функции для работы с такими списками, в остальных - нет.

Понятно, что за счет универсальности и чуть более высокого уровня у .NET программ немного сужается возможность работы на низком уровне. Никто тебе не запрещает вызвать WinAPI-функции из .NET-приложения.

Цитата Andr,2.09.04, 18:21

Это утверждается разработчиками .NET.

Компиляция происходит не во время выполнения (как у виртуаьных машин), а ПЕРЕД ПЕРВЫМ ВЫЗОВОМ МЕТОДА. И компиляция выполняется С ОПТИМИЗАЦИЕЙ ПОД КОНКРЕНТНЫЙ ПРОЦЕССОР.Так утверждают разработчики .NET. Что же здесь не понятного.
Для слишком упертых: для пущего быстродействия можешь в момент старта программы вхолостую вызывать используемые метода, чтобы в момент "реального" вызова не тартить время на компиляцию.

Посточнные ссылки на то что утверждают разработчики .Net (то бишь "теория") а в реальности видим не очень то быстродействующий код. Это замечание №1.
Замечание №2: предложение вызвывать для компиляции нужные методы при загрузке программы мне кажется, это может привести к очень большим недарзумениям в работующей программе. Например, метод "обощенный", делает что-то взависимости от параметра, например пишет в реестр занчение какого-то ключа. Возникает вопрос, с каким параметров вызывать этот метод в начале работы программы. Конкретный ключ - означает запись или перезапись его значения. Можно в методе предусмотреть выход из этого метода когда, в качестве параметра задана, напрмер, пустая строка. И использовать пустую строку в качестве параметра, когда запускаем программу. Но тогда это приводит к УВЕЛИЧЕНИЮ программного кода (в пример как минимум на одно условие), и опять таки все это ради быстродействия?
На КАКИЕ ЕЩЕ ФОКУСЫ придется пойти? А ? Andr?

Сообщение отредактировано: SPrograMMer - 02.09.04, 11:27

Цитата

Цитата

Вот этого я не понимаю. Какая разница, из чего делать исполняемый код.

Риторический вопрос: не задумывались, почему Delphi делает промедуточные файлы dcu? Да так проще и оптимальнее через посредника делать оптимальный машинный код. Это утверждается разработчиками .NET.

Я это и имел ввиду. Повторяю еще раз:

Цитата

IL нужен только для более быстрого создания машинного кода

а также возможности запуска на разных платформах и для того чтобы скрыть исходный код.
Я имел ввиду что такого не може быть:

Цитата

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

Разве есть разница из чего делать ассемблерный код. Разница есть только в необходимом для этого времени.

Где-то я успел прочитать что при компиляции IL кода подразумевалась оптимизация не только под процессор, но и под установленное железо вообще, но в Framework 1.1 такого еще нет, будет в 2.0

С этимии фишками... это моя догадка, может быть я мечтаю, но возможно все идет к тому что драйвера (о которых говорилось что написать их в .net непонятно как) будет писать нетрудно, функция драйверов сведется к тому что они будут просто трнслировать ядру .net список поддерживаемых функций. Поддерживаемых из определенного стандарта, как это например сейчас умеют делать дрова для DirectX и OpenGL. Так вот... продолжение мысли - "тяжкое бремя" спецификации стандарта дров и возможных функций определенного типа железа возмет на себя естественно загребущая лапа майкрософт. Конечно выигрыш от этого будет, но что-то мне как-то неуютно. Или еще лучше, вообще никаких дров, мелкий камушек на железке с готовым списком того что умеет эта железка, и к этому камню .net будет обращаться напрямую перед тем как компилить оптимальный IL..

Я глючу?

SPrograMMer

Цитата

Посточнные ссылки на то что утверждают разработчики .Net (то бишь "теория") а в реальности видим не очень то быстродействующий код.

1. Прежде, чем сформировать свое мнение о чем-то новом, нужно первым делом как следует изучить теорию. Не задумывался, почему все так хают D8? Можно по-разному относиться к .NET, но нужно вначале изучить.
2. .NET-программы работают чуть медленнее, чем Win32 не потому, что разработчики врут об оптимальной компиляции под конкретный процессор, а потому, что все типы данных в .NET - объектные. Поэтому простейший цикл и работает в 1,5 раза дольше, т.к. счетчик - объект.
Если только из-зи этого отказываться от .NET, то давай откажемся и от D7 в пользу C и Pure-Win32-приложений, и будем писать их в любимой проге всех Pure-Win32-программеров Borland C++ 5.02??! А??? SPrograMMer???
На то все-таки и процы сейчас такие. Помнишь, когды Intel выпустила очень резко процы на 700 MHz, везде писали, что такую приозводительность негде использовать?

Цитата

На КАКИЕ ЕЩЕ ФОКУСЫ придется пойти

SPrograMMer, это был НЕ ФОКУС, а утрированный пример для очень УПЁРТЫХ.

Лирическое отступление: когда вышла D5, у нас один преподаватель, говорил, что его проги для баз данных, написанные в D3, после компиляции в D5 начинают работать на 30% медленнее. И потому, типа, D5 - го..но, а D3 - очень крута.
Ну, так давай, SPrograMMer, откажемся от D7 и будем писать проги на D3, т.к. они будут работать быстрее??? А???
Но я знаю, SPrograMMer, что ты не откажешься от D7, т.к. она отвечает вызовам времени, предоставляя соответствующие технологии, а D3 вызовам времени не отвечает.
Но теперь настают времена, что надстройки над WinAPI не отвечают вызовам времени, и скоро наступит золотое время .NET.

P.S. Код, написанный в VS. NET 2005 Beta 1 на чистом C++ (под Win32, без .NET Managed Extensions), всего лишь на 25% производительнее, чем код, написанный на C#. А если учесть, программировать на C# раз в 10 (десять) легче и приятнее (!), чем на C++, то мой выбор в пользу C#.

2 Andr

Цитата Andr,2.09.04, 15:52

Код, написанный в VS. NET 2005 Beta 1 на чистом C++ (под Win32, без .NET Managed Extensions), всего лишь на 25% производительнее, чем код, написанный на C#. А если учесть, программировать на C# раз в 10 (десять) легче и приятнее (!), чем на C++, то мой выбор в пользу C#.

Небольшой вопрос: на каком процессоре это проверялось? Если на P4, то вообще удивительно, если заметна какая-то разница в производительности. И если на P4, то где же оптимизация кода под конкретный процессор? Если ее нет (скорость не повышается), то зачем она нужна?

2 encobalt

Цитата encobalt,2.09.04, 15:12

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

Мне кажется, что со стороны Микрософт это возможно. Но опять же пока этого нет...
Тоже мысли вслух: если это действительно произойдет, то я точно буду думать, что Микрософт все время оставляет некоторые усовершенствования на потом. Разве этого нельзя было сделать в эпоху еще расцвета WinApi?

2 mike

Цитата

И если на P4, то где же оптимизация кода под конкретный процессор? Если ее нет (скорость не повышается), то зачем она нужна?

Ты не догоняешь:
1. Есть оптимизация методов под конкрентный процессор, и скорость повышается.
2. Итоговая скорость ниже, т.к. объектно-ориентированный код всегда медленнее (а без оптимизации под процессор стал бы еще медленнее). Если ты это не знал, то тебе учиться надо, а не рассуждать о производительности .NET

Цитата

Компиляция происходит не во время выполнения (как у виртуаьных машин), а ПЕРЕД ПЕРВЫМ ВЫЗОВОМ МЕТОДА.

А это не run-time? Метод вызывается не в рантайме?

Цитата

2. .NET-программы работают чуть медленнее, чем Win32 не потому, что разработчики врут об оптимальной компиляции под конкретный процессор, а потому, что все типы данных в .NET - объектные. Поэтому простейший цикл и работает в 1,5 раза дольше, т.к. счетчик - объект.

Для самых упёртых. Код на C#:

 
using System;
 
namespace net_test
{
         /// <summary>
    /// Summary description for Class1.
    /// </summary>
    class NetTest
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main(string[] args)
        {
            TestFunc();
        }
 
        static void TestFunc()
        {
            for(long i = 1; i < 50000; ++i)
            {
                bool simple = true;
                for(long j = 2; j < i; ++j)
                {
                    if(i % j == 0)
                        simple = false;
                }
                if(simple)
                                         Console.Write(i + "\n");
            }
        }
    }
}

Код на C++:

 
#include <iostream>
 
class long_integer {
public:
    long_integer(long l):
      _val(l) {}
 
    operator long() { return _val; }
 
    long_integer operator+(const long_integer & l) { return long_integer(_val + l._val); }
    long_integer operator++(int) {
        long_integer i = _val;
        _val++;
        return i;
    }
    long_integer & operator++() { _val++; return *this; }
    bool operator<(const long_integer & i) { return _val < i._val; }
    long_integer operator%(const long_integer & i) { return _val % i._val; }
 
private:
    long _val;
};
 
static void test_func()
{
    for(long i = 1; i < 50000; ++i)
    {
        bool simple = true;
        for(long j = 2; j < i; ++j)
        {
            if(i % j == 0)
                simple = false;
        }
        if(simple)
            std::cout << i << std::endl;
    }
}
 
static void test_func2() {
    for(long_integer i = 1; i < long_integer(50000); ++i)
    {
        bool simple = true;
        for(long_integer j = 2; j < i; ++j)
        {
            if(i % j == 0)
                simple = false;
        }
        if(simple)
            std::cout << i << std::endl;
    }
}
 
 
void main() {
    std::cout << "test 1" << std::endl;
    test_func();
    std::cout << "test 2" << std::endl;
    test_func2();
}

На С++ две функции: одна - аналог кода для C#, вторая - где счетчики - объекты. Время выполнения обеих функций на С++ одинаково!!! Что касается сравнения C++ и С#, то тут даже высокоточного счетсика не надо, всё и так понятно.
Использовалась VS 2003. Первый пример у меня на компе выполняется 2 минуты 10 сек, второй - каждая функция по 1 минуте 10 сек.
Попробуйте у себя.
P.S Не забудьте пробовать на Release версиях.

Цитата

А если учесть, программировать на C# раз в 10 (десять) легче и приятнее (!), чем на C++, то мой выбор в пользу C#.

Субъективное мнение.

Цитата

2. Итоговая скорость ниже, т.к. объектно-ориентированный код всегда медленнее (а без оптимизации под процессор стал бы еще медленнее). Если ты это не знал, то тебе учиться надо, а не рассуждать о производительности .NET

смотри пример

Сообщение отредактировано: Sanek - 02.09.04, 15:22

2 Sanek

Цитата

Цитата

Компиляция происходит не во время выполнения (как у виртуаьных машин), а ПЕРЕД ПЕРВЫМ ВЫЗОВОМ МЕТОДА.

А это не run-time? Метод вызывается не в рантайме?

Я несколько некорректно высказался. Но рантайм рантайму рознь. Одно дело, когда виртуальная машина перемалывает байт-код в машинный каждый раз при вызове, другое, когда IL-код при первом вызове скомпилит код метода оптимально под конкретный процессор при первом вызове метода.

Теперь рассмотрим твои примеры с C# и C++. Тебе известно понятие чистоты эксперимента? (ты где учился ?) Если сравнивается производительность счетчиков, то в теле цикла ничего ни должно быть (что более предпочтительно), либо должен быть одинаковый код.
А у тебя:

Console.Write(i + "\n");

для C#;

std::cout << i << std::endl;

Понятно, что .NET-консоль более сложный объект. Например, ты передаешь ему целое-объект, которое перобразуется в строку-объект и выводится.
А в системную консоль C++ ты пишешь просто целое число (к тому же наверняка коварный оптимизирующий компилятор помещавет его не в ОЗУ, а в какой-нибудь регистров проца). И преобразуется он наверняка перед выводом в простой и быстрый *char.

Так что постарайся быть более убедительным, Sanek.

Цитата

Если сравнивается производительность счетчиков, то в теле цикла ничего ни должно быть (что более предпочтительно), либо должен быть одинаковый код.

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

Цитата

Понятно, что .NET-консоль более сложный объект. Например, ты передаешь ему целое-объект, которое перобразуется в строку-объект и выводится.
А в системную консоль C++ ты пишешь просто целое число

И чем же это .NET-консоль сложнее cout? И что значит "просто пишу число". Как будто оно не преобразуется в строку.

Цитата

к тому же наверняка коварный оптимизирующий компилятор помещавет его не в ОЗУ, а в какой-нибудь регистров проца

Ну так если у .NET плохой оптимизатор, что я могу поделать.

Ну да ладно. Специально для тебя. Можешь закомменитровать эти строки. Изменений не будет. Тут же невооруженным глазом видно, что основная часть времени тратится на цикл, а не на вывод. Можешь преобразовать в std::string в С++, всё равно ничего не изменится.
Факт есть факт. У нас два ООП-кода, один выполняется гораздо медленне. Ничего с этим не поделаешь.

2 Sanek
Пример с соблюдением чистоты эксперимента (для тех, кто гонит на .NET)
Консольное приложение, которое можно скомпилировать как в D7, так и в D8:

program Test;
{$APPTYPE CONSOLE}
{if CompilerVersion >= 16.00}
  {%DelphiDotNetAssemblyCompiler '$(SystemRoot)\microsoft.net\framework\v1.1.4322\system.drawing.dll'}
{endif}
uses SysUtils;
var
  BeginTime: TDateTime;
  I: Integer;
begin
  BeginTime := Now();
  for I := 0 to MaxInt do begin { empty cycle } end;
  Writeln(FormatDateTime('"Test time: "hh:nn:ss:ms" (hour:min:sec:msec)"', Now() - BeginTime));
  Writeln('Press ENTER...');
  Readln;
end.

Время выполнения обоих приложений (скомпилированных в D7 и D8) одинаково: 0 ч, 0 м, 3 с, 123 мс.
Рузультата говорит сам за себя.

Andr, приведи аналог на C#, если сможешь.

2 Sanek
Аналог (Release-сборка) на C# - VS .NET 2003:

using System;
namespace ConsoleApplication1
{
    class Class1
    {
        [STAThread]
        static void Main(string[] args)
        {
            DateTime beginDate = DateTime.Now;
            [B]for (uint i = 0; i <= int.MaxValue; i++) { /* empty cycle */ }[/B]
            TimeSpan testTime = DateTime.Now - beginDate;
            string s = testTime.ToString();
            Console.WriteLine("Test time: " + s);
            Console.WriteLine("Press Enter...");
            Console.ReadLine();
        }
    }
}

Результат: на той же машине (Cel 1300, WinSrv 2003 Ent) выполняется 4 с 983 мс.

Что же, резальтат не так хорош, как в Delphi 7/8.
Я думаю, связано это с различной релизацией цикла for.
Если в Delphi цикл for заменить на цикл while, выполняться цикл будет почти в 2 раза дольше (я проверял).
Это связано с тем, что цикл for можно скомпилировать в очень быструю asm-инструкцию loop, в случае же цикла while компилятор вынужден самостоятельно управлять изменением счетчика.

А в C# цикл for фактически является иначе записанной формой цикла while:

using System;
namespace ConsoleApplication1
{
    class Class1
    {
        [STAThread]
        static void Main(string[] args)
        {
            DateTime beginDate = DateTime.Now;
            [B]uint i = 0;
            while (i <= int.MaxValue) { i++; }[/B]
            TimeSpan testTime = DateTime.Now - beginDate;
            string s = testTime.ToString();
            Console.WriteLine("Test time: " + s);
            Console.WriteLine("Press Enter...");
            Console.ReadLine();
        }
    }
}

Этот код выполняется тоже 4 с 483 мс.

Так что увеличение времени выполннеия в данном случае - не недостаток .NET, в недостаток реализации цикла for в конкретном языке.
Кстати, в C/C++ цикл for тоже является фактически циклом while. Я всегда считал это недостатком .

Сообщение отредактировано: Song - 06.09.04, 11:35

В последнем после у меня опечатка:
вместо 4 с 483 мс надо писать 4 с 983 мс

Andr, code=cpp !