Re[6]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 04.06.09 07:48
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это вообще во всех компаниях. Отсуствие ручного управления памятью в разы увеличивает скорость разработки.

Использование например STL контейнеров это ручное управление памятью?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 04.06.09 11:43
Оценка: 1 (1) +2
Здравствуйте, gandjustas, Вы писали:

G>Это вообще во всех компаниях. Отсуствие ручного управления памятью в разы увеличивает скорость разработки.

На С++ можно вполне избежать ручного управления памятью. Вот то, что в C# нельзя управлять вручную, это вполне может оказаться серьёзным недостатком .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[5]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 18:22
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


M>>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок.

S>>>Очень спорное утверждение.
G>>Не придуривайся, это уже давно факт.
CC>Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.
Теже индусы на C++ создавали бы код с гораздо большим количеством ошибок.

G>>И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?

G>>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
CC>Пример с CreateThread в который передается метод в качестве функции потока тебя устроит?
Не устроит, нужен именно способ, а не пример функции, на которой это как-то работает.
Re[7]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 18:27
Оценка: -1
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Это вообще во всех компаниях. Отсуствие ручного управления памятью в разы увеличивает скорость разработки.

DC>На С++ можно вполне избежать ручного управления памятью.
Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

DC>Вот то, что в C# нельзя управлять вручную, это вполне может оказаться серьёзным недостатком .

Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.
Re[8]: С# vs C++, голые цифры
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.06.09 18:35
Оценка:
Здравствуйте, gandjustas, Вы писали:

DC>>Вот то, что в C# нельзя управлять вручную, это вполне может оказаться серьёзным недостатком .

G>Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.
Я могу. Поднапрячь LOH слегка. Есть такие реальные сценарии, где LOH капитально подводит. Очень не хватает ручного управления.
Re[9]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 18:48
Оценка:
Здравствуйте, samius, Вы писали:

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


DC>>>Вот то, что в C# нельзя управлять вручную, это вполне может оказаться серьёзным недостатком .

G>>Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.
S>Я могу. Поднапрячь LOH слегка. Есть такие реальные сценарии, где LOH капитально подводит. Очень не хватает ручного управления.
И прямо совсем нельзя оптимизировать?
Re[10]: С# vs C++, голые цифры
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.06.09 19:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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


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

S>>Я могу. Поднапрячь LOH слегка. Есть такие реальные сценарии, где LOH капитально подводит. Очень не хватает ручного управления.
G>И прямо совсем нельзя оптимизировать?
Речь идет об численной обработке больших снимков (автоматизированная медицинская диагностика). Один снимок порядка полусотни мегабайт. С ним надо сделать N-ое количество манипуляций. Память фрагментируется — шуба заворачивается. Начали с того, что приложение за пол часа работы уходит в жесткий и глубокий свап при реальных потребностях всего в 400Мб памяти в пике.
Оптимизировать? Можно, но это слишком трудозатратно. Предложения выделять память под снимки строками или переводить математику на unsafe всерьез не рассматриваются. Можно обрабатывать снимки кусками, но там и так довольно много нетривиальных вычислений, усугублять их не хотелось бы.
Выкручиваемся с помощью пулинга. Жизнь приложения продлили. Но стопудовых гарантий что не упадет нет.

З.Ы. Неконтроллируемых висячих ссылок нет.
Re[11]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 19:20
Оценка:
Здравствуйте, samius, Вы писали:

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


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


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


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

S>>>Я могу. Поднапрячь LOH слегка. Есть такие реальные сценарии, где LOH капитально подводит. Очень не хватает ручного управления.
G>>И прямо совсем нельзя оптимизировать?
S>Речь идет об численной обработке больших снимков (автоматизированная медицинская диагностика). Один снимок порядка полусотни мегабайт. С ним надо сделать N-ое количество манипуляций. Память фрагментируется — шуба заворачивается. Начали с того, что приложение за пол часа работы уходит в жесткий и глубокий свап при реальных потребностях всего в 400Мб памяти в пике.
Откуда фрагментация памяти? как раз тот случай когда выделять память и не надо, максимум создать пул буферов под картинки и работать с ними.

S>Оптимизировать? Можно, но это слишком трудозатратно. Предложения выделять память под снимки строками или переводить математику на unsafe всерьез не рассматриваются. Можно обрабатывать снимки кусками, но там и так довольно много нетривиальных вычислений, усугублять их не хотелось бы.

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

S>Выкручиваемся с помощью пулинга. Жизнь приложения продлили. Но стопудовых гарантий что не упадет нет.

Ну это собственно единственный способ работы с такими объемами, причем независимо от языка и платформы.
Еще вариант — выделять буферы как можно раньше.
Re[12]: С# vs C++, голые цифры
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.06.09 19:53
Оценка: 3 (1)
Здравствуйте, gandjustas, Вы писали:

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


S>>Речь идет об численной обработке больших снимков (автоматизированная медицинская диагностика). Один снимок порядка полусотни мегабайт. С ним надо сделать N-ое количество манипуляций. Память фрагментируется — шуба заворачивается. Начали с того, что приложение за пол часа работы уходит в жесткий и глубокий свап при реальных потребностях всего в 400Мб памяти в пике.

G>Откуда фрагментация памяти? как раз тот случай когда выделять память и не надо, максимум создать пул буферов под картинки и работать с ними.
Все не так просто. Там большой конвейер, на каждом этапе используются массивы разных типов. Зарезервировать память под все не получится — тупо не хватит. Что-то пулить можно, что-то нельзя. Закладываться на максимальный размер снимков тоже не можем, да и числорубок может быть несколько (по числу процессоров).

S>>Оптимизировать? Можно, но это слишком трудозатратно. Предложения выделять память под снимки строками или переводить математику на unsafe всерьез не рассматриваются. Можно обрабатывать снимки кусками, но там и так довольно много нетривиальных вычислений, усугублять их не хотелось бы.

G>Выделить один раз столько сколько нужно и все.
Ответил выше.
G>LOH устати также работат как среднестатистическая куча в C++, и надо соотвествующие методы применять.
Среднего пошиба куча из C++ нас бы устроила больше, т.к. она как раз поддается ручному контролю распределения памяти. В дотнете тоже можно, но нельзя работать с выделенной памятью как с массивом аки byte[]. А если сделал new byte[], то через минуту нельзя его использовать как массив ushort[].

S>>Выкручиваемся с помощью пулинга. Жизнь приложения продлили. Но стопудовых гарантий что не упадет нет.

G>Ну это собственно единственный способ работы с такими объемами, причем независимо от языка и платформы.
Согласен, но в управляемых платформах нет возможности строить планы по распределению памяти, ориентированные на задачу.
G>Еще вариант — выделять буферы как можно раньше.
Хороший вариант, но не совсем наш. Используем такие трюки как принудительная дефрагментация со сбросом актуальных данных на диск (с приостановкой счета), собственноручное прогнозирование выделения памяти, немного другое чем MemoryFailPoint и т.п.
Впрочем, пока бороться получается, перетаскивать кухню на C++ желающих нет, да и необходимости такой нет.
Re[6]: С# vs C++, голые цифры
От: shrecher  
Дата: 04.06.09 21:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

CC>>Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.

G>Теже индусы на C++ создавали бы код с гораздо большим количеством ошибок.

Если индивидум не умеет программировать, то тут уже ничего не поделать. Главное это не зависит от национальности и языка программирования.
Re[6]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 05.06.09 07:18
Оценка:
Здравствуйте, gandjustas, Вы писали:

CC>>Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.

G>Теже индусы на C++ создавали бы код с гораздо большим количеством ошибок.
Их продукт на С++ бы вообще не вышел, чем сильно облегчил бы нам жизнь.

G>>>И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?

G>>>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
CC>>Пример с CreateThread в который передается метод в качестве функции потока тебя устроит?
G>Не устроит, нужен именно способ, а не пример функции, на которой это как-то работает.
Способ простой:

template <class CLASS, DWORD(CLASS::*__thunkPtr)()> 
DWORD WINAPI CallbackThunk (void* __ptr)
{
    return (((CLASS*)__ptr)->*__thunkPtr)();
}

class MyClass
{
...
  DWORD MyFunc ();
...
};

MyClass classInstance;
CreateThread(0, 0, CallbackThunk<MyClass, &MyClass::myFunc>, &classInstance, 0, 0);
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 08:23
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


CC>>>Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.

G>>Теже индусы на C++ создавали бы код с гораздо большим количеством ошибок.
CC>Их продукт на С++ бы вообще не вышел, чем сильно облегчил бы нам жизнь.
Эт о зависит от маркетологов. Вот corel draw написан индусами на С++ и ниче.
Хотя глючный аж жуть.


G>>>>И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?

G>>>>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
CC>>>Пример с CreateThread в который передается метод в качестве функции потока тебя устроит?
G>>Не устроит, нужен именно способ, а не пример функции, на которой это как-то работает.
CC>Способ простой:

CC>
CC>template <class CLASS, DWORD(CLASS::*__thunkPtr)()> 
CC>DWORD WINAPI CallbackThunk (void* __ptr)
CC>{
CC>    return (((CLASS*)__ptr)->*__thunkPtr)();
CC>}

CC>class MyClass
CC>{
CC>...
CC>  DWORD MyFunc ();
CC>...
CC>};

CC>MyClass classInstance;
CC>CreateThread(0, 0, CallbackThunk<MyClass, &MyClass::myFunc>, &classInstance, 0, 0);
CC>


А теперь для SetWindowsHookEx.
Re[8]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 05.06.09 08:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А теперь для SetWindowsHookEx.

Ну а сюда уже тока статические методы by design самого механизма хуков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: С# vs C++, голые цифры
От: Antikrot  
Дата: 05.06.09 08:50
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>А теперь для SetWindowsHookEx.

а что, на C# можно? (я просто не в курсе)
Re[9]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 09:06
Оценка: -1 :)
Здравствуйте, Antikrot, Вы писали:

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


G>>А теперь для SetWindowsHookEx.

A>а что, на C# можно? (я просто не в курсе)
Конкретно хук — вряд ли, грузить рантайм в чужой процесс наверное не получится.
А внутри одного процесса передать метод объекта коллбеком — вполне.

Пример:
using System.Runtime.InteropServices;

public delegate bool CallBackPtr(int hwnd, int lParam);

public class EnumReport
{
    int token;

    public EnumReport()
    {
        token = (new Random()).Next();
    }

    [DllImport("user32.dll")]
    public static extern int EnumWindows(CallBackPtr callPtr, int lPar);

    public bool Report(int hwnd, int lParam)
    {
        Console.WriteLine("{0}:Window handle is {1}", token, hwnd);
        return true;
    }
}

class Program
{

    static void Main()
    {
        EnumReport.EnumWindows((new EnumReport()).Report, 0);
        Console.ReadLine();
        EnumReport.EnumWindows((new EnumReport()).Report, 0);
        Console.ReadLine();
    }
}


Интероп с нэйтив кодом в C# дается весьма просто. Вот наоборот — возникают проблемы.
Хотя если использовать out-proc COM сервер, то и проблем нету.
Re[9]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 09:15
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


G>>А теперь для SetWindowsHookEx.

CC>Ну а сюда уже тока статические методы by design самого механизма хуков.
Ну а попроще, типа EnumWindows
Re[10]: С# vs C++, голые цифры
От: IID Россия  
Дата: 05.06.09 09:27
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну а попроще, типа EnumWindows


Ну дык там lParam есть, в котором передаём this, и уже по нему вызываем обработчик класса. Если надо в свой обработчик ещё и свой контекст передавать — тоже элементарно. В оригинальый EnumWindows в lParam передаеём указатель на прокси с двумя полями: this и контекст.
kalsarikännit
Re[11]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 09:42
Оценка:
Здравствуйте, IID, Вы писали:

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


G>>Ну а попроще, типа EnumWindows


IID>Ну дык там lParam есть, в котором передаём this, и уже по нему вызываем обработчик класса. Если надо в свой обработчик ещё и свой контекст передавать — тоже элементарно. В оригинальый EnumWindows в lParam передаеём указатель на прокси с двумя полями: this и контекст.

Еще раз: хаки не нтересуют, интересует общий способ, как в моем примере на шарпе.
Re[8]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 05.06.09 11:39
Оценка: 1 (1) +1
Здравствуйте, gandjustas, Вы писали:

G>Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

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

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

Да я и искать то не буду, GC дотнетовский хорош, но он заточен на вполне определённый круг сценариев работы (ну нельзя впихнуть невпихуемое), как только мы натыкаемся на такой сценарий, начинается борьба с GC, её можно облегчить сделав GC расширяемым, но про такое я ещё не слышал. А в плюсах всё просто — не нравится автобус, взял написал горный велосипед и поехал по горным тропам .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[12]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 05.06.09 11:42
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Еще раз: хаки не нтересуют, интересует общий способ, как в моем примере на шарпе.

Да, тебя, кажется, вообще C++ не интересует, как и то что его помощью сделать можно.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.