Здравствуйте, Plutonia Experiment, Вы писали:
PE>В 2 раза. На плюсах наши алгоритмы работали и от нескольких дней до двух неделью В два раза это от недели до месяца. Очень хороший подход. PE>Железо реального преимущества не даст. ПО и так дорогое, а с железом его и купить то будет некому. Сколько памяти не ставь — два гигабайта на процесс это мало для дотнета.
Да, кстати... а ты не задумывался на тему, что выбрав неверную фунцию или компилятор (который идеален, но вот одна комбинация, встречающаяся у тебя в узких местах, тормозная) можно проиграть в скорости и больше чем в два раза?
Заметь, старый код был в основном быстрее современного. Но компиляторы то с тех пор стали только быстрее.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Из чего загружается ? Попробуй загрузить 100'000 объектов, которые указывают друг на друга, по пять-десять пропертей, из файла.
Комик, блин. Какая разница откуда грузить? Хотя загрузка ста тысяч объектов из файла по одному — это уже нехилая операция.
Короче, вот результаты теста не 100 тысяч объектов, а для 100 00 000 (ста миллионов):
C:\MyProjects\hreh\GcTest1\GcTest1\bin\Release>GcTest1.exe
Ver 1.1.4322.573
Iteration count 10000000
Start test 1 (simple list)...Finish test 1. Elapsed time is 0.2884803
GC for test 1 ...Finish GC for test 1. Elapsed time is 0.000477435
Start test 2 ...Finish test 2. Elapsed time is 0.5040096
GC for test 2 ...Finish GC for test 2. Elapsed time is 0.02037103
А вот, сам код:
using System;
class A
{
public A ref1;
public A ref2;
public A ref3;
public A ref4;
public A ref5;
}
class Class1
{
const int iterCount = 10000000;
static void Test1()
{
PerfCounter timer = new PerfCounter();
Console.Write("Start test 1 (simple list)...");
timer.Start();
A root;
A curr = root = new A();
for (int i = 0; i < iterCount; i++)
{
curr.ref1 = new A();
curr.ref1 = curr;
}
Console.WriteLine("Finish test 1. Elapsed time is {0}", timer.Finish());
}
static void Test2()
{
PerfCounter timer = new PerfCounter();
Console.Write("Start test 2 ...");
timer.Start();
A root;
A curr = root = new A();
for (int i = 0; i < iterCount; i++)
{
A tmp1 = new A();
curr.ref1 = tmp1;
curr.ref1 = curr;
tmp1 = curr.ref1.ref1;
if (tmp1 != null)
{
tmp1.ref2 = curr;
tmp1 = tmp1.ref1;
if (tmp1 != null)
{
tmp1.ref3 = curr;
tmp1 = tmp1.ref1;
if (tmp1 != null)
{
tmp1.ref4 = curr;
tmp1 = tmp1.ref1;
if (tmp1 != null)
{
tmp1.ref5 = curr;
tmp1 = tmp1.ref1;
}
}
}
}
}
Console.WriteLine("Finish test 2. Elapsed time is {0}", timer.Finish());
}
static void GcTime(int testNum)
{
PerfCounter timer = new PerfCounter();
Console.Write("GC for test {0} ...", testNum);
timer.Start();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine("Finish GC for test {1}. Elapsed time is {0}",
timer.Finish(), testNum);
}
static void Main(string[] args)
{
Console.WriteLine("Ver " + Environment.Version.ToString());
Console.WriteLine("Iteration count {0}", iterCount);
for (int i = 0; i < 10000; i++)
;
Test1();
GcTime(1);
for (int i = 0; i < 10000; i++)
;
Test2();
GcTime(2);
//Console.ReadLine();
}
}
Здравствуйте, Kluev, Вы писали:
K>Загружается всегда молниеносно, Этим никого не озадачишь. Попробуй протестировать постоянно добавляя и удаля узлы из дерева. Самое смешно начнется когда забудешь где нибудь ссылку обнулить. А ведь структуры могут быть очень сложными. ИМХО в задачах где интенсивно используются (перестраиваются) деревья, графы, сети и т.р. сборка мусора является проклятьем.
Ты знаешь? Пробовал... Нельзя сказать, что у дотнета в этих задачах приемущество, но и серьезных недостатков нет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>При чем здесь тесты ? Строковые операции — сравнение, конкатенация, длина и тд очень сильно влияют на производительность прилаги. Так что тут раскручивание цикла имеет смысл. PE>Процессоры нынче не умееют предсказываться ветвления на 100%. Частичный разворот цикла дает неслабый прирост на маленьких строках, коих большинство.
Притом, что речь шла о тестах. И в них расрутка (елси сам цикл сделан для увеличения объемов вычислений) — это нечестныое сравнение. На практике раскрутка может и замедлить скорость алгоритма. Погдяди второго шустрика. Там как раз был gcc с раскруткой и без.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, naje, Вы писали:
N>а чё такое, нет в нете ннтп? N>обыдно, да?
В нете? А в С++ есть?
Речь идет о нашем ННТП-сервере написанном нами же для нас же. Жрет сабака время и память. Ну, да это просто не очень качественная реализация. Тот же Хоум раядом ведет себя очень прилично.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
K>> Сборка мусора всегда будет тянуть НЕТ на дно. VD>А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++?
Когда задача очень большая, то и хип нам не друг. В таких случаях делается пул и хип и ГЦ остаются далеко позади. Никакой ГЦ не сможет работать быстрее чем пул. Особенно в стрессовых условиях: ведь программа может легко работать несколько дней подряд, а в ГЦ я слышал что если обьект пережил пару сборок мусора то он уже не удаляется никогда.
В С++ оператор new перегрузил, перевел обьект из хипа в пул и вот уже перфоманс совсем другой, а что в жаве или в НЕТе делать будем? Наверное на С++ переписывать будем
VD>Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным?
Представь что программа на каждой итерации создает и освобождает ~200К обьектов. Частично или полностью (перестройка сетки). В обьектах от 10 до 30 указателей. Т.е. структура весьма ветвистая. Пул отрабатывает мгновенно. Хип, не спорю будет тормозить. А как ГЦ будет себя вести?
VD>Ну, эти задачи уже давно в акселераторы зашиты. Но все равно потенциально проблем с их рассчетом на менеджед-языках нет.
Далеко не все. Для С++ еще полным-полно работы. Может клиента БД на нем и нет смысла писать, но есть и другие программы. Можешь показать хотя-бы один CAD написаный на яве или на шарпе?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kluev, Вы писали:
K>>Загружается всегда молниеносно, Этим никого не озадачишь. Попробуй протестировать постоянно добавляя и удаля узлы из дерева. Самое смешно начнется когда забудешь где нибудь ссылку обнулить. А ведь структуры могут быть очень сложными. ИМХО в задачах где интенсивно используются (перестраиваются) деревья, графы, сети и т.р. сборка мусора является проклятьем.
VD>Ты знаешь? Пробовал... Нельзя сказать, что у дотнета в этих задачах приемущество, но и серьезных недостатков нет.
Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>Из чего загружается ? Попробуй загрузить 100'000 объектов, которые указывают друг на друга, по пять-десять пропертей, из файла.
VD>Комик, блин. Какая разница откуда грузить? Хотя загрузка ста тысяч объектов из файла по одному — это уже нехилая операция.
VD>Короче, вот результаты теста не 100 тысяч объектов, а для 100 00 000 (ста миллионов):
Я кидал ссылку про O(n**2) поведение мультикастделегата. При десерилизации происходит затык при рассылке OnDeserilizationCallback. 50000 — еще реально ждать. 100000 — уже нет.
Возьми и пощупай сам. А та синтетика, которую ты здесь показал, никакого отношения к сетям не имеет.
VD>
VD>C:\MyProjects\hreh\GcTest1\GcTest1\bin\Release>GcTest1.exe
VD>Ver 1.1.4322.573
VD>Iteration count 10000000
VD>Start test 1 (simple list)...Finish test 1. Elapsed time is 0.2884803
VD>GC for test 1 ...Finish GC for test 1. Elapsed time is 0.000477435
VD>Start test 2 ...Finish test 2. Elapsed time is 0.5040096
VD>GC for test 2 ...Finish GC for test 2. Elapsed time is 0.02037103
VD>
Здравствуйте, VladD2, Вы писали:
VD>Да, кстати... а ты не задумывался на тему, что выбрав неверную фунцию или компилятор (который идеален, но вот одна комбинация, встречающаяся у тебя в узких местах, тормозная) можно проиграть в скорости и больше чем в два раза?
Узкие места целиком и полностью в дотнете и Шарпе.
VD>Заметь, старый код был в основном быстрее современного. Но компиляторы то с тех пор стали только быстрее.
Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...
Здравствуйте, VladD2, Вы писали:
PE>>При чем здесь тесты ? Строковые операции — сравнение, конкатенация, длина и тд очень сильно влияют на производительность прилаги. Так что тут раскручивание цикла имеет смысл. PE>>Процессоры нынче не умееют предсказываться ветвления на 100%. Частичный разворот цикла дает неслабый прирост на маленьких строках, коих большинство.
VD>Притом, что речь шла о тестах. И в них расрутка (елси сам цикл сделан для увеличения объемов вычислений) — это нечестныое сравнение. На практике раскрутка может и замедлить скорость алгоритма. Погдяди второго шустрика. Там как раз был gcc с раскруткой и без.
Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.
Здравствуйте, VladD2, Вы писали:
VD>>>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет.
K>>Будут всегда.
VD>Ошибаещся.
Вот интересно, зачем же тогда половина стринга написана на нативном С++ ? Стрингбилдер туда же. Да и вообще много че написано нативно, хотя можно было менеджед заимплементить.
Ведь можно его на шарпе реализовать полностью. Наверное Били решил таким способом замелить строку ?
K>> Сборка мусора всегда будет тянуть НЕТ на дно.
VD>А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++?
А это ничего, что аппликухе на нативном с++ хватает памяти, а дотнету — нет ?
K>> От этого никуда не деться. VD>Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным?
Он слишком долго отслеживает ссылки, если их слишком много.
K>> Может далеть UI на НЕТ-е и просто, но работать со сложными структурами я бы на нем не стал. VD>Что есть сложные структуры?
Модель сети например. Любая наукоемкая задача использует очень сложные стурктуры.
K>>Алгоритмы уже проблема. Возьми любую нетривиальную задачу — триангуляция поверхности, разбиение обьема и т.п.
VD>Ну, эти задачи уже давно в акселераторы зашиты. Но все равно потенциально проблем с их рассчетом на менеджед-языках нет.
В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ? Реалиизуй алгоритм смены голоса диктора на шарпе (двумя способами — со словарем и без оного) , будем посмотреть.
Здравствуйте, VladD2, Вы писали:
PE>>Из чего загружается ? Попробуй загрузить 100'000 объектов, которые указывают друг на друга, по пять-десять пропертей, из файла.
VD>Комик, блин. Какая разница откуда грузить? Хотя загрузка ста тысяч объектов из файла по одному — это уже нехилая операция.
Нехилая — очень емкное слово. Главное понять, что под этим подразумевается.
Вот ответ на причину тормозов при десерилизации. Это проблемы дотнета, возможно ее пофиксят.
Но есть масса других проблем — стато мелких поросят.
using System;
namespace ConsoleApplication1
{
class TestClass
{
public static int count = 0;
public static DateTime t0;
public delegate void EventHandler(int i);
public event EventHandler OnEvent;
public void OnEventOccured(int i)
{
}
static void Main(string[] args)
{
new TestClass().TestMethode();
}
public void TestMethode()
{
// Try different values; performance hits the ceiling
// for > 15000for(int j=0; j<100000; ++j)
{
OnEvent += new EventHandler(OnEventOccured);
}
t0 = DateTime.Now;
OnEvent(1);
// Total elapsed
Console.WriteLine( "Time : " + (DateTime.Now - t0) );
Console.ReadLine();
}
}
}
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Узкие места целиком и полностью в дотнете и Шарпе.
А мне кажется в основном в руках и головах.
PE>Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...
Вы — возможно. Я — нет. Дженерики это конечно удобно. И кое где они позволят более просто создавать более эффектиные алгоритмы, но и сейчас можно писать очень даже эффективный код.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>Когда задача очень большая, то и хип нам не друг.
И есть документальное подтверждение на которое можно дать ссылку?
K> В таких случаях делается пул и хип и ГЦ остаются далеко позади.
Да качественный ЖЦ и есть по сути пул.
K> Никакой ГЦ не сможет работать быстрее чем пул.
Согласен, но велика ли разница? И так ли часто ты пользуешся пулом и другими тонкими оптимизациями?
K> Особенно в стрессовых условиях: ведь программа может легко работать несколько дней подряд, а в ГЦ я слышал что если обьект пережил пару сборок мусора то он уже не удаляется никогда.
Удаляется... если памяти нехватает и если на объект нет ссылок. А если хватает, то ради чего его удалять? Чтобы процессор занять?
K>В С++ оператор new перегрузил, перевел обьект из хипа в пул и вот уже перфоманс совсем другой, а что в жаве или в НЕТе делать будем?
Код прикладной писать. А производительность ЖЦ проблемы МС и Сана. Если уж очень нужно, то в дотнете можно пользоваться структурами и хранить их в массиве. Считай тот же пул.
K> Наверное на С++ переписывать будем
Ни разу пока не нужно было. Но если я пийду к выводу, что на С++ я смогу ускорить ту или иную часть приложения и это действительно нужно, то я сделаю это не задумываясь. А почему бы и нет? Но ради скорости одного-двух фрагментов кода тратить столько сил и времени... зачем?
VD>>Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным? K>Представь что программа на каждой итерации создает и освобождает ~200К обьектов.
Это очень выгодный для ЖЦ сценарий. Дон Бокс даже демонстрировал приемущества ЖЦ над хипом С++ создавайя в цикле объект и уничтожая его.
K> Частично или полностью (перестройка сетки). В обьектах от 10 до 30 указателей. Т.е. структура весьма ветвистая. Пул отрабатывает мгновенно. Хип, не спорю будет тормозить. А как ГЦ будет себя вести?
В ЖЦ есть специальные оптимизации на такой случай. Все эти объекты попадут в первое поколение и будут очень эффективно освобождены. Причем тогда когда процессор будет свободен, ане во время алгоритма.
Да и все разговоры о пуле — это теория. На практике осннвные массы таких фич не используют. И выходит не быстрее чем с ЖЦ.
K>Далеко не все. Для С++ еще полным-полно работы.
Для ассемблера тоже в принципе есть. Вот только дорого его использовать.
K> Может клиента БД на нем и нет смысла писать, но есть и другие программы. Можешь показать хотя-бы один CAD написаный на яве или на шарпе?
А сколько нужно писать КАД? И сколько контор этим занимется? Дотнет то всего два года как вылупился. Погу показать примеры от D3D 9. Там есть примеры как на Шарпе, так и на анменеджед-С++. Разницы никакой. Так что делать можно. И когда нибудь сделают. Другое дело, что из-за того, что переписывать море кода на С++ на Шарп глупо скорее всго по началу языки вроде Шарпа и Явы появятся в них как средства автоматизации. А потом, когда народ поймет, что нет особой разницы все большешие и большие части будут дописываться/переписываться на дотнетных языках.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Вот интересно, зачем же тогда половина стринга написана на нативном С++?
Хороший вопрос. Особенно елси учесть тот факт, что этот код проигрывает аналогичному написанному на Шарпе.
Дуамаю, тут два аспекта. 1. Универсальные алгоритмы проще было взять в С++ чем переписывать (особенное если они нужны для назных типов). 2. Фрэймвор унаследован от Явы и много кода писалось еще в те времена, когда еще небыло качественного джита. Сейчас такой фигней уже не занимаются.
PE> Стрингбилдер туда же.
Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.
PE> Да и вообще много че написано нативно, хотя можно было менеджед заимплементить.
Возми моно. Там почти все на Шарпе. Тот же компилятор. Причем компилирует очень шустро.
PE>Ведь можно его на шарпе реализовать полностью. Наверное Били решил таким способом замелить строку ?
Да на Шарпе все же по более будет. И самые медленные реализации как раз на С++ сделаны. Правда это не означает, что С++ никуда не годится. Просто на С++ обычно реализуются универсальные вещи, а они в принципе обычно тормозны.
VD>>А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++? PE>А это ничего, что аппликухе на нативном с++ хватает памяти, а дотнету — нет ?
Где? Вот у нас на сервере мс-сиквел и АСП.НЭТ. Так сиквелу памяти нехватает, а АСП вроде не кашляет.
PE>Он слишком долго отслеживает ссылки, если их слишком много.
Слишком много это сколько? Миллион отслеживает почти молниеносно. Да и делается это не постоянно.
PE>Модель сети например. Любая наукоемкая задача использует очень сложные стурктуры.
Т.е. граф? Нда, куда уж сложнее. Нормально он будет с ней работать. Памяти возможно сожрет больше, но если ее хватает, то будет очень даже прилично работать.
PE>В какие акселераторы ?
В видео.
PE> Туда зашивают только то, что хорошо разжевано,
Напомню о чем речь: K>>>Возьми любую нетривиальную задачу — триангуляция поверхности
PE>А с оработкой звука как ?
У меня на одной машие SB Live, а на другой SB Audidgy 2.
PE> Реалиизуй алгоритм смены голоса диктора на шарпе (двумя способами — со словарем и без оного) , будем посмотреть.
Это давно решенные задачи. Если конечно велосипед не изобретать. Ну, и главно ошеломляюще быстрее на С++ их один фиг не решить.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.
Пустой треп.
PE>Серилизация это вообще отдельный случай.
Реализация по умолчанию не быстрая. Но в С++ ее вообще нет, так что сравнивать не с чем. А реализовать ее быстро можно и там, и там.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Я кидал ссылку про O(n**2) поведение мультикастделегата. При десерилизации происходит затык при рассылке OnDeserilizationCallback. 50000 — еще реально ждать. 100000 — уже нет.
Напиши свой алгоритм сериализации. На С++ ты же тоже не будешь иметь готового. Я уже писал об этом. Тот же нетовский дадасет у меня сериализовался со скоростью поросячего визга.
PE>Возьми и пощупай сам. А та синтетика, которую ты здесь показал, никакого отношения к сетям не имеет.
И в чем разница?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Вот ответ на причину тормозов при десерилизации. Это проблемы дотнета, возможно ее пофиксят. PE>Но есть масса других проблем — стато мелких поросят.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.
А уверен, что это не руки? На Хоум тоже говорили память жрет... торомзит... а когда стали разбираться, то выяснили, что основное время и память сжерает Эксес.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PE>>Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...
VD>Вы — возможно. Я — нет. Дженерики это конечно удобно. И кое где они позволят более просто создавать более эффектиные алгоритмы, но и сейчас можно писать очень даже эффективный код.
Сейчас у нас каждый объект порождает пять сущностей:
Класс
2 вида коллекции — копипейст.
Основной интерфейс (для SAX Basic)
Класс/методы для валидации
Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.
