.Net - Seite 2 - DAX: Программирование

Diman · 11.02.2011, 23:53

Zitat:

Zitat von otkudao

не дочитал еще, но уже начали глодать смутные сомнения:

1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?

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

Zitat:

Zitat von otkudao

2. Везде в тексте указания, что нужно активно плыть в сторону оптимизации, сам компилятор мышей не ловит. Вплоть до того, что рекомендуется строить леса перегруженных методов

В сторону оптимизации нужно плыть всегда, компилятор только сможет скомпилировать IL под конкретный процессор, собственно и вся оптимизация, здеcь компиляторы, которые генерят native код в общем случае проигрывают JIT компиляции.
Про леса методов наверно лучше почитать книжку "банды четырех".

Zitat:

Zitat von otkudao

В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?

Вопрос не в плане аксапты, а в плане чистого .Net.

Хотя и в плане аксапты можно прокомментить.

В аксапте нет оптимизации P-кода как в .Net, здесь IL выигрывает всегда. По поводу скорости разработки - представьте, что вам необходимо сделать приложение, под несколько платформ. Пришлось бы под каждую платформу писать спицифические для нее куски кода. Приходилось иметь дело с кодом на С++, где надо было писать ассемблерные вставки под конкретные процессоры и OS. Соответственно весь этот зоопарк придется поддерживать. А генерация промежуточного IL в общем случае избавляет от этих забот.
Выше упоминался GC, так вот в неправильно спроектированной софтине эта самая недетерминированность как раз и становится узким местом. Когда надо пройтись по графу ссылок и освободить память из поколения 2 например, а объект в это время лежит в файле на диске. Поэтому даже при наличии GC следить за памятью и ее очисткой все-таки придется. Да и еще, при освобождении памяти GC производит дефрагментацию памяти. В большинстве случаев это также ускоряет выделение памяти под новые объекты. Еще есть плюс в том, что алгоритм GC умеет определяеть размер памяти выделяемый под поколения в момент исполнения, что тоже увеличивает производительность.

ИМХО начинать изучать .Net с Рихтера тяжеловато.

12.02.2011, 00:40

2 belugin
Не уверен, что смогу подробнее раскрыть , подобрав другие слова, но попробую: Рихтер указывает, что многие методы базовых объектов (System.Object) реализованы не самым эффективным с точки зрения скорости выполнения образом и их нужно заменять. Также приводит в пример , кажется, System.Decimal и System.String (у стринга это методы Concat), в которых "правильно" реализованы линейки перегруженных методов с тем, чтобы не использовать стандартный массив параметров ( params ). Создавая конструкторы, нужно тщательно продумывать, будут ли создаваться объекты по значению, в какой момент сработают конструкторы типов. Для методов: будут ли генерироваться параметры как динамические объекты в куче, минимизировать их число, вынося генерацию объектов из методов. если можно обойтись одним объектом; советует перегружать методы только из-за того, чтобы они возвращали различные типы значений (и не было операции конвертации, уж больно дюже она неэффективна) , что-то еще , что сейчас вечером уже не в силах вспомнить.

Да прочтите, там 650 страниц этого жевания. Я только до 224 дошел, а советов по оптимизации кода - вагон и маленькая тележка. Книга ими просто пронизана. Неспроста это, недовольны разработчики скоростью.

----------------------------------------------------------
Про "недетерминированный" я совсем ничего не понял. Особенно того, кто же там бегает по связям и почему в другим языках этого делать не надо.

belugin · 12.02.2011, 00:52

Допустим есть код

X++:

void f()
{
Ascii io = new AsciiIo(@'c:\myFile.txt','r');
io.read();
}

Аксапта обязуется уничтожить io как только пропадет последняя ссылка на него. Для этого там счетчик ссылок. И счетчик циклов, на случай если есть циклические ссылки.

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

В .NET такого обязательсятва нет - мустор собирается только время от времени или если память кончается. Но при этом дорогие ресурсы (типа открытых файлов) приходится освобождать явно

X++:

Ascii io=new AsciiIO...
try
{
    io.read();
}
finally
{
   io.Dispose();
}

для этого в C# введен даже синтаксичесикй сахар:

X++:

using(AsciiIO io= new AsciiiIO(...))
{
    io.read();
}

_scorp_ · 12.02.2011, 20:44

Zitat:

Zitat von otkudao

2 belugin
Не уверен, что смогу подробнее раскрыть , подобрав другие слова, но попробую: Рихтер указывает, что многие методы базовых объектов (System.Object) реализованы не самым эффективным с точки зрения скорости выполнения образом и их нужно заменять. Также приводит в пример , кажется, System.Decimal и System.String (у стринга это методы Concat), в которых "правильно" реализованы линейки перегруженных методов с тем, чтобы не использовать стандартный массив параметров ( params ). Создавая конструкторы, нужно тщательно продумывать, будут ли создаваться объекты по значению, в какой момент сработают конструкторы типов. Для методов: будут ли генерироваться параметры как динамические объекты в куче, минимизировать их число, вынося генерацию объектов из методов. если можно обойтись одним объектом; советует перегружать методы только из-за того, чтобы они возвращали различные типы значений (и не было операции конвертации, уж больно дюже она неэффективна) , что-то еще , что сейчас вечером уже не в силах вспомнить.

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

На самом деле, я считаю, что .NET в аксапте не нужен. В таких приложениях большую часть времени занимают операции ввода-вывода, и зачастую, временем, за которое выполняется код можно вообще пренебречь - настолько мизерную часть от общего времени он составляет. Поэтому, мне кажется, не стоит ждать того, что после перехода с x++ на c# аксапта "залетает".

А еще я думаю, что читать код на c# будет сложнее, т.к. нужно будет следить за всякими нюансами .NET, а не только за бизнес логикой. Вот примерчик, для демонстрации того, о чем я говорю:

X++:

class Program
    {
        static void Main(string[] args)
        {
            Shape shape1 = new Shape(1, 2, 3, 4, "descr1", 5);
            Console.WriteLine(shape1.ToString());
            Shape shape2 = shape1;
            shape2.description = "descr2";
            shape2.intValue = 6;
            shape2.p1.x = 7;
            shape2.p1.y = 8;
            Console.WriteLine(shape1.ToString());
            Console.WriteLine(shape2.ToString());
            Console.ReadLine();
        }

        public class Point
        {
            public int x;
            public int y;

            public Point(int x, int y)
            {
                this.x = x;
                this.y = y;
            }
        }

        public struct Shape
        {
            public Point p1;
            public Point p2;
            public string description;
            public int intValue;

            public Shape(int x1, int y1, int x2, int y2, string descr, int i)
            {
                p1 = new Point(x1, y1);
                p2 = new Point(x2, y2);
                description = descr;
                intValue = i;
            }
            public override string ToString()
            {
                return String.Format("p1 = {0}:{1}, p2 = {2}:{3} descr: {4} int: {5}", p1.x, p1.y, p2.x, p2.y, description, intValue);
            }
        }        
    }

Вот результат выполнения:

Zitat:

p1 = 1:2, p2 = 3:4 descr: descr1 int: 5
p1 = 7:8, p2 = 3:4 descr: descr1 int: 5
p1 = 7:8, p2 = 3:4 descr: descr2 int: 6

Diman · 13.02.2011, 02:33

Zitat:

Zitat von _scorp_

В C++, например, у разработчика вообще нет контроля над тем куда разместить объект в стек потока или в кучу.

В С++ как раз есть куча способов, куда разместить объект. Смотрите malloca() + placement new, а еще есть регистровые переменные, а еще можно делать ассемблерные вставки....

Zitat:

Zitat von _scorp_

На самом деле, я считаю, что .NET в аксапте не нужен. В таких приложениях большую часть времени занимают операции ввода-вывода, и зачастую, временем, за которое выполняется код можно вообще пренебречь - настолько мизерную часть от общего времени он составляет. Поэтому, мне кажется, не стоит ждать того, что после перехода с x++ на c# аксапта "залетает".

Ну в некоторых местах залетает, только, к сожалению, мало таких мест.

_scorp_ · 13.02.2011, 10:51

Zitat:

Zitat von Diman

В С++ как раз есть куча способов, куда разместить объект. Смотрите malloca() + placement new

В C++ я не силен. Основывался на том что писал Рихтер

Zitat:

Многим разработчикам (в частности тем, кто пишет неуп
равляемый код на C/C++) деление на ссылочные и значимые типы по
началу будет казаться странным. В неуправляемом коде C/C++ вы объяв
ляете тип, и уже код решает, куда поместить экземпляр типа: в стек по
тока или в кучу приложения. В управляемом коде иначе: разработчик, опи
сывающий тип, указывает, где разместятся экземпляры данного типа, а
разработчик, использующий тип в своем коде, управлять этим не может.

Получается он наврал?

Сам чуть-чуть покопал по ключевым словам. Вроде бы _alloc() действительно может выделить память для переменной в стеке. Но так же пишется, что в стек ограничен где-то 1 МБ, и если активно им пользоваться, то можно поймать переполнение. В .NET про такое ограничение не слышал.

Zitat:

Zitat von Diman

а еще есть регистровые переменные

Почитал... Как я понял, много туда не сохранишь.

Zitat:

Zitat von Diman

а еще можно делать ассемблерные вставки....

Ну так много не напрограммируешь

belugin · 13.02.2011, 21:05

я бы вопросы по .NET задавал на http://rsdn.ru или http://gotdotnet.ru

Diman · 13.02.2011, 23:52

Zitat:

Zitat von _scorp_

В C++ я не силен. Основывался на том что писал Рихтер

Получается он наврал?

Нет, не наврал. Под неуправляемым поведением, здесь имеелось ввиду, что по умолчанию оптимизатор С++ пытается положить в стек, если не получается, то в кучу.

Zitat:

Zitat von _scorp_

Сам чуть-чуть покопал по ключевым словам. Вроде бы _alloc() действительно может выделить память для переменной в стеке. Но так же пишется, что в стек ограничен где-то 1 МБ, и если активно им пользоваться, то можно поймать переполнение. В .NET про такое ограничение не слышал.

Это по умолчанию 1Мб, если правильно помню.

Надо глянуть, что на счет стека в .Net говорит стандарт, или на соотв. форумах поискать.
Можно поймать переполнение, но если программист уж связался со стеком, значит сделал это сознательно и должен, как порядочный человек, ухаживать за ним до конца.

Zitat:

Zitat von _scorp_

Почитал... Как я понял, много туда не сохранишь.

Зависит от задачи, иногда хватает.

Zitat:

Zitat von _scorp_

Ну так много не напрограммируешь

Много не надо, надо в меру

KindDog · 14.02.2011, 14:22

Нашел тут примерчики работы с Net-ом. Может кому интересно будет.

http://www.codeproject.com/KB/cs/IntegrateAxapta.aspx
http://www.codeproject.com/KB/cs/Int...xaptPart2.aspx