Re[21]: CLI/C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.01.04 13:43
Оценка: -1
Здравствуйте, Lloyd, Вы писали:

VD>>Тем что лажа. Посмотри на описание OpenC++ — сам все поймешь.


L>После такого заявления даже смотреть не буду.


Правильно, лишнее это. Так проще заявлять, что в С++ все есть.

Да нельзя все же обижать религиозные чувства.
... << RSDN@Home 1.1.2 beta 1 >>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: CLI/C++
От: Lloyd Россия  
Дата: 12.01.04 14:03
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Правильно, лишнее это. Так проще заявлять, что в С++ все есть.


VD>Да нельзя все же обижать религиозные чувства.


Это типа наезд что-ли?
Я на C++ не работал, не работаю и работать не буду.
Но не потому что C++ сакс и маздай, а потому что есть более интересные вещи на этом свете.
Но это ни в коей мере не умаляет достоинства языка.

А по-поводу OpenC++. Ты можешь назвать хоть один широко-распространенный продукт, написанный на нем?
... << RSDN@Home 1.1.2 beta 1 >>
Re[10]: CLI/C++
От: lkj www.7-zip.org
Дата: 12.01.04 14:06
Оценка:
Здравствуйте, Lloyd, Вы писали:

lkj>>Итераций много. Накладные расходы не должны влиять.

lkj>>В чем некорректность?
lkj>>Как быстро могут выполняться вызовы виртуальных функций в программе на С++ для .NET?
lkj>>И почему мой пример работает так медленно?

L>Во-первых большой оверхед на загрузке нетовского рантайма.

L>Во-вторых первый вызов подпрограммы в управляемом коде приводит к компиляции.
L>В-третьих не факт, что компилятор в C++ не заменил прямой f1 вызов на прямой (не виртуальный). Он видит, что наследников больше нет и вправе это сделать. Если сделал, то кроме того мог еще и заинлайнить этот вызов, а заодно и вызов g1. Тогда и получаем, что имеем программу типа int s = 0; for (int i = 0; i < 10000000; i++)s += i; В принцыпе этот цикл можно развернуть. А развернув, обнаруживаем, что результат можно свести к int s = <что-то там>; Тут он обнаруживает, что s никто не ипользует и выбрасывает его нафик. Так что в итоге пришли к тому, что оптимизатором тело main-а может быть сведено на нет. Т.о. получаем, что ты сравниваешь время загрузки операционной системой ничего не делающей программы и время работы .net-программы.

Ты меня за дилетанта принимаешь? Тогда посмотри ссылку на website.
Вопрос не на пустом месте возник.
Можно ли сделать программу на C++.NET 7.1 с большим количеством вызовов виртуальных функций, для которой вызов виртуальной функции выполняется быстрее 100 тактов CPU в среднем?
Re[17]: CLI/C++
От: _wqwa США  
Дата: 12.01.04 14:13
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

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


IT>>Причём потеря производительности в этом случае будет напрямую зависить только от диаметра кривизны рук разработчика.


AVK>Обычно инженеры употребляют термин "радиус кривизны"

Когда речь идет о руках, принято говорить "диаметр", т.к. руки -- две, радиусы их кривизны могут быть разными, и самму двух радиусов условно называется диаметром
... << RSDN@Home 1.1.0 stable >>
Кто здесь?!
Re[11]: CLI/C++
От: Lloyd Россия  
Дата: 12.01.04 14:22
Оценка:
Здравствуйте, lkj, Вы писали:

lkj>Ты меня за дилетанта принимаешь? Тогда посмотри ссылку на website.

lkj>Вопрос не на пустом месте возник.
lkj>Можно ли сделать программу на C++.NET 7.1 с большим количеством вызовов виртуальных функций, для которой вызов виртуальной функции выполняется быстрее 100 тактов CPU в среднем?

using System;

namespace VirtualTest
{
    public interface IDo
    {
        void Do();
    }

    public class Do: IDo
    {
        #region IDo Members
        void IDo.Do()
        {
            Console.WriteLine();
        }
        #endregion
    }
    /// <summary>
    /// Summary description for Class1.
    /// </summary>
    class Class1
    {
        [STAThread]
        static void Main(string[] args)
        {
            IDo @do = new Do();
            @do.Do();
        }
    }
}



            @do.Do();
00000023  mov         ecx,edi 
00000025  mov         eax,dword ptr [ecx] 
00000027  mov         eax,dword ptr [eax+0Ch] 
0000002a  mov         eax,dword ptr [eax+00000094h] 
00000030  call        dword ptr [eax]


Где здесь 100 тактов?
... << RSDN@Home 1.1.2 beta 1 >>
Re[18]: CLI/C++
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.01.04 14:34
Оценка: :)
Здравствуйте, _wqwa, Вы писали:

AVK>>Обычно инженеры употребляют термин "радиус кривизны"

_>Когда речь идет о руках, принято говорить "диаметр", т.к. руки -- две, радиусы их кривизны могут быть разными, и самму двух радиусов условно называется диаметром

Не двух радиусов, а удвоенный радиус.

D=2R
... << RSDN@Home 1.1.2 beta 2 >>
AVK Blog
Re[12]: CLI/C++
От: lkj www.7-zip.org
Дата: 12.01.04 14:43
Оценка:
Здравствуйте, Lloyd, Вы писали:

lkj>>Можно ли сделать программу на C++.NET 7.1 с большим количеством вызовов виртуальных функций, для которой вызов виртуальной функции выполняется быстрее 100 тактов CPU в среднем?


L>
L>            @do.Do();
L>00000023  mov         ecx,edi 
L>00000025  mov         eax,dword ptr [ecx] 
L>00000027  mov         eax,dword ptr [eax+0Ch] 
L>0000002a  mov         eax,dword ptr [eax+00000094h] 
L>00000030  call        dword ptr [eax] 
L>


L>Где здесь 100 тактов?


А где здесь C++?
Re[23]: CLI/C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.01.04 14:57
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>А по-поводу OpenC++. Ты можешь назвать хоть один широко-распространенный продукт, написанный на нем?


Гугль спасет отца русской демократии.
... << RSDN@Home 1.1.2 beta 1 >>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: CLI/C++
От: Lloyd Россия  
Дата: 12.01.04 14:58
Оценка:
Здравствуйте, lkj, Вы писали:

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


lkj>>>Можно ли сделать программу на C++.NET 7.1 с большим количеством вызовов виртуальных функций, для которой вызов виртуальной функции выполняется быстрее 100 тактов CPU в среднем?


L>>
L>>            @do.Do();
L>>00000023  mov         ecx,edi 
L>>00000025  mov         eax,dword ptr [ecx] 
L>>00000027  mov         eax,dword ptr [eax+0Ch] 
L>>0000002a  mov         eax,dword ptr [eax+00000094h] 
L>>00000030  call        dword ptr [eax] 
L>>


L>>Где здесь 100 тактов?


lkj>А где здесь C++?


Это C#.
... << RSDN@Home 1.1.2 beta 1 >>
Re[14]: CLI/C++
От: lkj www.7-zip.org
Дата: 12.01.04 16:22
Оценка:
Здравствуйте, Lloyd, Вы писали:

lkj>>>>Можно ли сделать программу на C++.NET 7.1 с большим количеством вызовов виртуальных функций, для которой вызов виртуальной функции выполняется быстрее 100 тактов CPU в среднем?


L>Это C#.


Я не спрашивал про C#.
Я спрашивал про C++ для .NET
Re[15]: CLI/C++
От: Lloyd Россия  
Дата: 12.01.04 17:04
Оценка:
Здравствуйте, lkj, Вы писали:

lkj>Я не спрашивал про C#.

lkj>Я спрашивал про C++ для .NET

Я конечно в C++ не силен, но все же:

// This is the main project file for VC++ application project 
// generated using an Application Wizard.

#include "stdafx.h"

#using <mscorlib.dll>

using namespace System;

public __gc __interface IDo
{
    void Do();
};

public __gc class DoClass: public IDo
{
public:
    void Do()
    {
        Console::WriteLine();
    }
};

int _tmain()
{
    IDo* _do = new DoClass();
    _do->Do();
    return 0;
}


Ты не поверишь:

    _do->Do();
00000020  mov         ecx,edi 
00000022  mov         eax,dword ptr [ecx] 
00000024  mov         eax,dword ptr [eax+0Ch] 
00000027  mov         eax,dword ptr [eax+00000094h] 
0000002d  call        dword ptr [eax]


Где 100 тактов?

... << RSDN@Home 1.1.2 beta 1 >>
Re[16]: CLI/C++
От: lkj www.7-zip.org
Дата: 12.01.04 19:18
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Я конечно в C++ не силен, но все же:


Да. Такой код работает быстро.
Но можно ли заставить обычный C++ код (без этих __gc __interface) работать быстро в варианте для .NET?
Хочу проверить скорость С++ -> IL -> x86 для существующего проекта без какой-либо переделки кода.
Re[17]: CLI/C++
От: alexkro  
Дата: 13.01.04 05:30
Оценка:
Здравствуйте, lkj, Вы писали:

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


L>>Я конечно в C++ не силен, но все же:


lkj>Да. Такой код работает быстро.

lkj>Но можно ли заставить обычный C++ код (без этих __gc __interface) работать быстро в варианте для .NET?
lkj>Хочу проверить скорость С++ -> IL -> x86 для существующего проекта без какой-либо переделки кода.

А почему бы тебе самому не проанализировать свой пример, как это сделал Lloyd для C# & MC++?
Re[18]: CLI/C++
От: mihailik Украина  
Дата: 13.01.04 09:21
Оценка:
IT>Порядок освобождения и блокировки можно так же контролировать атрибутами.

Боюсь, это будет слишком неявно. Другими словами, порядок будет неочевиден при прочтении, что приведёт к ошибкам.

Опять же, есть поля, которые нужно освобождать, а есть ссылки на всяких там Parent.


IT> Обработка исключений — какая проблема? По спецификации Dispose не должен выбрасывать никаких исключений.


Ой, ну это уж точно вряд ли. Ты, наверное с Finalize перепутал.

Как ты думаешь, если я перед завершением using FileStream дискетку из дисковода вытащу. Будет исключение


IT> Да и в клинических случаях никто не запрещает написать Dispose самостоятельно. Но вот 90% спокойно можно имплементировать единообразно.


Для Dispose скорее 40%. И вообще, это будет тот же ужастный стиль C. Чтобы написать просто и кратко нужно будет из мозгов котлету сделать.

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


M>>Ну да, то есть для каждого интерфейса нужно писать расширение. Тогда понятно. Тоже вариант, только такое себе. Как-то не очень вдохновляет


IT>Для интерфейсов, атрибутов и для их комбинаций. Так же как в ATL реализовано что-то подобное для многих интерфейсов COM. Например, можно недельку посидеть и покрыть практически все задачи связанные с маппингом, при этом заметно выиграв в производительности, т.к. сегодня подавляющее число занимающихся этим библиотек реализует это через рефлекшин.


Ты имеешь ввиду маппинг, генерируемый в compile-time? А разве Reflection + Reflection.Emit не решает то же самое проще и надёжнее?
... << RSDN@Home 1.1.0 stable >>
Re[18]: CLI/C++
От: lkj www.7-zip.org
Дата: 13.01.04 14:02
Оценка:
Здравствуйте, alexkro, Вы писали:

lkj>>Да. Такой код работает быстро.

lkj>>Но можно ли заставить обычный C++ код (без этих __gc __interface) работать быстро в варианте для .NET?
lkj>>Хочу проверить скорость С++ -> IL -> x86 для существующего проекта без какой-либо переделки кода.

A>А почему бы тебе самому не проанализировать свой пример, как это сделал Lloyd для C# & MC++?


Не умею. С++.NET раньше не использовал. Поэтому и пишу на форум.
Re[19]: CLI/C++
От: IT Россия linq2db.com
Дата: 13.01.04 15:26
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Боюсь, это будет слишком неявно. Другими словами, порядок будет неочевиден при прочтении, что приведёт к ошибкам.

M>Опять же, есть поля, которые нужно освобождать, а есть ссылки на всяких там Parent.

Я же говорю, в особо клинических случаях никто не запрещает писать реализацию в ручну.

IT>> Обработка исключений — какая проблема? По спецификации Dispose не должен выбрасывать никаких исключений.


M>Ой, ну это уж точно вряд ли. Ты, наверное с Finalize перепутал.


Не перепутал.

namespace System {
    // IDisposable is an attempt at helping to solve problems with deterministic
    // finalization.  The GC of course doesn't leave any way to deterministically
    // know when a finalizer will run.  This forces classes that hold onto OS
    // resources or some sort of important state (such as a FileStream or a 
    // network connection) to provide a Close or Dispose method so users can 
    // run clean up code deterministically.  We have formalized this into an 
    // interface with one method.  Classes may privately implement IDisposable and
    // provide a Close method instead, if that name is by far the expected name
    // for objects in that domain (ie, you don't Dispose of a FileStream, you Close
    // it).
    //
    // This interface could be theoretically used as a marker by a compiler to 
    // ensure a disposable object has been cleaned up along all code paths if it's 
    // been allocated in that method, though in practice any compiler that 
    // draconian may tick off any number of people.  Perhaps an external tool (like
    // like Purify or BoundsChecker) could do this.  Instead, C# has added a using 
    // clause, which will generate a try/finally statement where the resource 
    // passed into the using clause will always have it's Dispose method called.  
    // Syntax is using(FileStream fs = ...) { .. };
    //
    // Dispose should meet the following conditions:
    // 1) Be safely callable multiple times
    // 2) Release any resources associated with the instance
    // 3) Call the base class's Dispose method, if necessary
    // 4) Suppress finalization of this class to help the GC by reducing the
    //    number of objects on the finalization queue.
    // 5) Dispose shouldn't generally throw exceptions, except for very serious 
    //    errors that are particularly unexpected. (ie, OutOfMemoryException)  
    //    Ideally, nothing should go wrong with your object by calling Dispose.
    //
    // If possible, a class should define a finalizer that calls Dispose.
    // However, in many situations, this is impractical.  For instance, take the
    // classic example of a Stream and a StreamWriter (which has an internal 
    // buffer of data to write to the Stream).  If both objects are collected 
    // before Close or Dispose has been called on either, then the GC may run the
    // finalizer for the Stream first, before the StreamWriter.  At that point, any
    // data buffered by the StreamWriter cannot be written to the Stream.  In this
    // case, it doesn't make much sense to provide a finalizer on the StreamWriter
    // since you cannot solve this problem correctly.  
    /// <include file='doc\IDisposable.uex' path='docs/doc[@for="IDisposable"]/*' />
    public interface IDisposable {
        /// <include file='doc\IDisposable.uex' path='docs/doc[@for="IDisposable.Dispose"]/*' />
        void Dispose();
    }
}


M>Как ты думаешь, если я перед завершением using FileStream дискетку из дисковода вытащу. Будет исключение


Попробуй сам и посмотри что будет. В чём проблема.

IT>> Да и в клинических случаях никто не запрещает написать Dispose самостоятельно. Но вот 90% спокойно можно имплементировать единообразно.


M>Для Dispose скорее 40%. И вообще, это будет тот же ужастный стиль C. Чтобы написать просто и кратко нужно будет из мозгов котлету сделать.


Такое ощущение, что ты только Dispose и программируешь. Я что-то не замечал, чтобы эта задача так часто возникала. Бывает иногда, бывает даже, что нужно освобождать несколько объектов. Но если в них самих Dispose написан корректно, то особой проблемы с порядком освобождения не возникает.

IT>>Для интерфейсов, атрибутов и для их комбинаций. Так же как в ATL реализовано что-то подобное для многих интерфейсов COM. Например, можно недельку посидеть и покрыть практически все задачи связанные с маппингом, при этом заметно выиграв в производительности, т.к. сегодня подавляющее число занимающихся этим библиотек реализует это через рефлекшин.


M>Ты имеешь ввиду маппинг, генерируемый в compile-time? А разве Reflection + Reflection.Emit не решает то же самое проще и надёжнее?


Решает, но не проще.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: CLI/C++
От: alexkro  
Дата: 13.01.04 19:20
Оценка:
Здравствуйте, IT, Вы писали:

IT>Обработка исключений — какая проблема? По спецификации Dispose не должен выбрасывать никаких исключений.


Мне интересно посмотреть на эту спецификацию. MSDN говорит, что может выбросить. Собственно, мне тоже хотелось бы, чтобы не выбрасывал, но пока все, что я встречал говорит об обратном.
Re[19]: CLI/C++
От: mikа Stock#
Дата: 13.01.04 19:44
Оценка:
Здравствуйте, lkj, Вы писали:

lkj>Не умею. С++.NET раньше не использовал. Поэтому и пишу на форум.


Ты не в этот форум пишешь. Тебе надо в http://rsdn.ru/forum/?group=dotnet.
Re[20]: CLI/C++
От: is  
Дата: 13.01.04 23:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Он С++ реализовал, а не C with classes, да и то как препроцессор к С.


Он реализовал препроцессор Cpre (в октябре 1979), который использовался в одном реальном и нескольких экспериментальных проектах. В составе этих проектов была "первая библиотека на С++, которая поддерживала многозадачное программирование с применением сопрограмм". "Язык, подаваемый на вход препроцессора, получил название "C with Classes"".

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Re[19]: CLI/C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.01.04 23:50
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Боюсь, это будет слишком неявно. Другими словами, порядок будет неочевиден при прочтении, что приведёт к ошибкам.


M>Опять же, есть поля, которые нужно освобождать, а есть ссылки на всяких там Parent.


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

Кстати, ссылки на парента обычно помечены как не сериализуемые. Можно это дело анализировать.


M>Как ты думаешь, если я перед завершением using FileStream дискетку из дисковода вытащу. Будет исключение


А черт его знает. Реальное закрытие хэндла происходит внутри ЦЛР, но сдается мне что вряд ли. Хотя все может быть.

M>Для Dispose скорее 40%. И вообще, это будет тот же ужастный стиль C. Чтобы написать просто и кратко нужно будет из мозгов котлету сделать.


Не, ну, моньячество со всех сторон. Ну, что может быть ужастного в дереве? Уж разрушение переменных там сделано просто прекрасно.

M>Где можно "имплементировать единообразно", где нужно "написать самостоятельно" — иэвечный вопрос этих бедняг сишников.


Да нет таких вопросов. Есть другой вопрос "Нужно ли делать руками то, что можно не делать?". И тут я целиком согласен с плюсовиками. Чем меньше пишешь руками, тем надежнее.

M>Ты имеешь ввиду маппинг, генерируемый в compile-time? А разве Reflection + Reflection.Emit не решает то же самое проще и надёжнее?


А ты пробовал? Ну, тогда попробуй. Поймешь насколько это "проще". И насколько "надежнее" получается. К тому, же сама генерация отнимает время. А так все в компайл-тайме.
... << RSDN@Home 1.1.2 beta 1 >>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.