Re[43]: плохой язык C++ :)
От: Left2 Украина  
Дата: 22.03.06 13:24
Оценка:
VD>Siemens M55 вроде как на Symbian OS живет. И телефонная книга у него не на Яве значит.

Неправда Ваша.
Единственный сименс на Symbian OS — это SX1.
Ну и к тому же Symbian и Java — это не антиподы, под Symbian можно замечательно писать на Java.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[37]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 13:24
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Хм... Ничего не понял. А что общего между кодогенерацией и алгоритмами управления памятью?


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

VD>>Пойми. И GC и неуправляемые коучи пишут не идеоты.

V>Не сомневаюсь в этом. Но они и понятия не имеют о МОЕЙ задаче.

Ага. Им и не надо. Они пишут очень быстрый универсальный алгоритм.

VD>>И если у меня скоростная характеристика близка к O(1), то хоть в лепешку разбейся но серьезного выигрыша ты неполучишь.

V>Неужели? А если константа будет час?

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

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


Понимаеш, ли в чем дело. Занимаясь подобными оптимизациями ты выиграшь доли процента в скорости, и проиграешь месяцы времени. Вот в чем вопрос.

V>>>Это был проект сетевого движка для MMORPG. Приходило 8к сообщений (разного размера) в секунду и управление памятью как раз было узким местом.

VD>>Так, все! На этом мы пожалуй закончим. В сумашедший дом я не играю.
V>Ты о чем?

Ну, раз ты не понял, то вот развернутое объяснение:
Re[37]: плохой язык C++ :)
Автор: VladD2
Дата: 22.03.06
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 13:24
Оценка:
Здравствуйте, igna, Вы писали:

I>GC на C++ значит...


Ну, вот мы и выяснили первопричину.
Шучу конечно. Но сам ЖЦ тут не причем.

К тому же девайсы вроде телевонов не выключаются обычно. Они выключаются если у них батарейку вынуть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: плохой язык C++ :)
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.03.06 13:45
Оценка: :))
Здравствуйте, VladD2, Вы писали:

VD>Короче, в реальном мире релят грамотные специалисты, прямые руки и тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты, тесты.


А автокомплит со статической типизацией на пару?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[45]: плохой язык C++ :)
От: igna Россия  
Дата: 22.03.06 13:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>... Но сам ЖЦ тут не причем.



Откуда уверенность?



VD>К тому же девайсы вроде телевонов не выключаются обычно. Они выключаются если у них батарейку вынуть.



Это ново. Но и без того случая с непреднамеренным выключением время от времени возникающая пауза в 10 секунд не радует.
Re[38]: плохой язык C++ :)
От: prVovik Россия  
Дата: 22.03.06 13:54
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Ну ты заливаешь! Ты прежде чем токое нести узнал бы какова средняя пропускная способность у 100 мегабитной сети. Я тебе как краевед скажу, что где-то оголо 10 мег в секунду.


VD>На вашей игрушке можно смело писать звучные лозунги вроде:

VD>

Мы работаем на будущее!!!... Минимальные требования для сетевой игры Gigabit Ethernet!

это СЕРВЕР

VD>А вот для ЖЦ это тем не менее вообще не работа. Вот простенький тест:

и что этот "тест" показал?
лэт ми спик фром май харт
Re[38]: плохой язык C++ :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 22.03.06 13:55
Оценка: 12 (1)
Здравствуйте, VladD2, Вы писали:

VD>А вот для ЖЦ это тем не менее вообще не работа. Вот простенький тест:

...
VD>Вто что получается на маей машине:
VD>
VD>00:00:00.0547748
VD>Количество сборок в поколнии 0: 17
VD>Количество сборок в поколнии 1: 6
VD>Количество сборок в поколнии 2: 0
VD>


Как я понимаю, твой тест отработал за ~55 миллисекунд. На какой машине?

Алаверды (код теста ниже). Машина Pentium M 1.5GHz, 512Mb.

Visual C++ 7.1.
Компиляция:
cl -GX -O2 -MT -ot_vc71.exe t1.cpp

Получаем:

simple alloc_objects
duration: 1.703
price: 0.08515
alloc raw_vectors
duration: 0.937
price: 0.04685


Т.е. в тесте с std::string получаем в два раза худший результат, что не удивительно, т.к. при помещении очередного std::string в список происходит двойное выделение памяти (для временного объекта и для объекта в списке), да еще с принудительной инициализацией всей строки нулями.

Зато второй тест с char[] уже выигрывает у твоего варианта с GC. Хотя можещь заметить, что никаких ухищрений по повышению производительности работы с памятью не делается. Интересно, не правда ли?

А вот другой компилятор:
Digital Mars C++ 8.42n
Компиляция:
dmc -o -ot_digital_mars.exe t1.cpp

Получаем:

simple alloc_objects
duration: 1.796
price: 0.0898
alloc raw_vectors
duration: 0.094
price: 0.0047




#include <iostream>
#include <list>
#include <string>
#include <algorithm>
#include <ctime>

template< class T >
void
run_and_measure(
    T functor )
{
    const unsigned int cycles = 20u;
    std::clock_t start, finish;

    start = std::clock();
    for( unsigned int i = 0; i != cycles; ++i )
        functor();
    finish = std::clock();

    double duration = double( finish - start ) / CLOCKS_PER_SEC;
    double price = duration / cycles;
    std::cout
        << "duration: " << duration << std::endl
        << "price: " << price << std::endl;
}

void
alloc_objects()
{
    typedef std::list< std::string > list_t;

    list_t list;

    for( unsigned int i = 0; i != 8000; ++i )
    {
        list.push_back( std::string( 4 * 1024, 0 ) );

        if( !( i % 100 ) )
            list.clear();
    }
}

void
raw_vector_destroyer( char * p )
{
    delete[] p;
}

void
alloc_raw_vectors()
{
    typedef std::list< char * > list_t;

    list_t list;

    for( unsigned int i = 0; i != 8000; ++i )
    {
        list.push_back( new char[ 4 * 1024 ] );

        if( !( i % 100 ) )
        {
            std::for_each( list.begin(), list.end(), raw_vector_destroyer );
            list.clear();
        }
    }
}

int
main()
{
    std::cout << "simple alloc_objects" << std::endl;
    run_and_measure( alloc_objects );

    std::cout << "alloc raw_vectors" << std::endl;
    run_and_measure( alloc_raw_vectors );

    return 0;
}


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[40]: плохой язык C++ :)
От: prVovik Россия  
Дата: 22.03.06 13:55
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


VD>>>Ага. На 8 000 сообщений.

V>>Что смешного?

VD>"фиксированные небольшой буфер памяти" в количестве 8000, да еще и с размером по 4 К — это 32 метра! И это при том, что сообщения-то идут последовательно.


и?
лэт ми спик фром май харт
Re[38]: плохой язык C++ :)
От: prVovik Россия  
Дата: 22.03.06 13:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Понимаеш, ли в чем дело. Занимаясь подобными оптимизациями ты выиграшь доли процента в скорости

С чего ты это взял?
В моем случае по сравнению со стандартным хипом суммарная производительность программы увеличилась в несколько раз.
лэт ми спик фром май харт
Re[39]: плохой язык C++ :)
От: prVovik Россия  
Дата: 22.03.06 14:01
Оценка:
Здравствуйте, prVovik, Вы писали:

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


VD>>Понимаеш, ли в чем дело. Занимаясь подобными оптимизациями ты выиграшь доли процента в скорости

V>С чего ты это взял?
V>В моем случае по сравнению со стандартным хипом суммарная производительность программы увеличилась в несколько раз.
точнее не программы (сервера) а конкретно его сетевой части.
лэт ми спик фром май харт
Re[46]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 14:20
Оценка:
Здравствуйте, igna, Вы писали:

VD>>... Но сам ЖЦ тут не причем.


I>Откуда уверенность?


Влючи логику. Зачем валить напраслену на алгоритмы, если у отдельных порограммистов кривые руки? К тому же ты не знаешь реальных причин проблем.
В общем, оставь свои домыслы при себе и не делай на их основе каких бы то нибыло выводов.

VD>>К тому же девайсы вроде телевонов не выключаются обычно. Они выключаются если у них батарейку вынуть.


I>Это ново. Но и без того случая с непреднамеренным выключением время от времени возникающая пауза в 10 секунд не радует.


Пиши баг-репорты в создателям Сембиан. Может они тебе предложат патчик.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 14:20
Оценка:
Здравствуйте, Left2, Вы писали:

VD>>Siemens M55 вроде как на Symbian OS живет. И телефонная книга у него не на Яве значит.


L>Неправда Ваша.

L>Единственный сименс на Symbian OS — это SX1.
L>Ну и к тому же Symbian и Java — это не антиподы, под Symbian можно замечательно писать на Java.

Возмнжно. Но то, что там не Symbian, а некий самопал еще не означает, что всь софт телефона написан на Яве. И уж темболее не значит, что глюки из-за ЖЦ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 14:20
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А автокомплит со статической типизацией на пару?


А они помогают грамотным специалистам с прямыми руками решать задачи легко и быстро.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 14:20
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Это да. Но то, что на C# можно писать не создавая мусора, не отменяет того, что библиотека .NET Framework иногда создает его там, где это не является необходимым; например StreamReader.ReadLine при каждом вызове возвращает новый String, и в классе StreamReader нет метода читающего в имеющийся StreamBuilder.

WH> По сравнения с чтением с диска...

Блин, слава богу, что экономисты вроде igna не проектируют библиотек. А то мы так бы ижли с ручным выделеним буферов под каждый чих.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 14:20
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Единственный случай когда я отказался от услуг ГЦ в .NET это был бинарный дифф для того чтобы резать на куски бэкап быза RSDN'а. Но там сценарий работы был таким: В начале работы создать несколько миллионов одинаковых объектов, а в конце работы их все удалить. Для этого я воспользовался массивом value типов.


Я бы не стал говорить "отказался". Это скорее разумное использование возможностей системы. Память то все равно управлялась в итоге ЖЦ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 15:03
Оценка: -1
Здравствуйте, eao197, Вы писали:

E>2VladD2: а минус за что? С чем конкретно ты не согласен?


Челове явно сказл, что выделяет память под 8000 сообщений, что их размеры их равны, и что память под них можно выделять из циклического буфера. Ты же мало того, что начал выискивать тайный смысл в его словах, но и подвигнул его на откроенный год о 8 000 сообщений по 4 Кб каждое. Нехитрый подсчет показывает, что такой объем данных через сеть в секунду можно пропихнуть если только она гигабитная. О тормозах памяти при таком расскладе можно забыть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 15:03
Оценка:
Здравствуйте, igna, Вы писали:

I>

I> . . .

I>My measurements shows a performance ratio of 8:1 in advantage for C#
I>over C++. But no C++ would allocate such small objects on the heap.
I>C#, on the otherhand, have no choice. And if you rewrite to proper C++
I>code you get a ratio of 42:1 -that is C++ is 42 times (!) quicker than
I>C#. So I enlarged the test with a) object specific new/delete op and
I>b) with a object of approx size 32 kb. The meassurements are found
I>below — and they are quiet astonishing: C++ outperforms C# in every
I>aspect, only with one exception: the Don Box demo!!!

I> . . .

I>(http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0208a&amp;L=atl&amp;P=20241)



И? То есть мы сошлись на том, что GC порвет большинство рукопашных оптимизаций динамического выделения памяти?
А с размещением в стэке все яснее ясного.
1. Есть вэлью-типы.
2. Ведутся работы по встраиванию в промышленные ЖЦ автоматического размещения объектов в стэке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 15:03
Оценка: 20 (1)
Здравствуйте, eao197, Вы писали:

E>Как я понимаю, твой тест отработал за ~55 миллисекунд.


Ага. А в этой сказке про белого бычка речь шала о 1 секунде, то есть о 1000 милисек.

E> На какой машине?


На машие с процессорм 2.2 гигагерца и частатой памяти 400 мегагерц.
Банальная апроксимация показывает, что за секунду этот код выполнится практически на любом писюке способном тинять NT.

E>Алаверды (код теста ниже). Машина Pentium M 1.5GHz, 512Mb.

...

E>Visual C++ 7.1.

E>Компиляция:
...

E>
E>cl -GX -O2 -MT -ot_vc71.exe t1.cpp
E>

E>Получаем:
E>

E>simple alloc_objects
E>duration: 1.703
E>price: 0.08515
E>alloc raw_vectors
E>duration: 0.937
E>price: 0.04685


Чтобы не гадать, я исправил твой тест и запустил на той же машине (компилировал в релиз из под VS2005):
simple alloc_objects
duration: 1.562
price: 0.0781
alloc raw_vectors
duration: 0.656
price: 0.0328


А исправил я пустячёк... заменил std::string на std::wstring и char на wchar_t. А то как-то не очень честно, ведь в дотнете char все же равен 2 байтам.

E>Т.е. в тесте с std::string получаем в два раза худший результат, что не удивительно, т.к. при помещении очередного std::string в список происходит двойное выделение памяти (для временного объекта и для объекта в списке), да еще с принудительной инициализацией всей строки нулями.


Ой, а как же про приемущества написания быстрых программ на С++? Получается, по умолчанию мы пишем не очень быстрые программы? А чтобы было побыстрее нужно пихать в код кучу невнятных оптимизаций?

Во как.

E>Зато второй тест с char[] уже выигрывает у твоего варианта с GC.


Как видишь нифига он не выиграл.


E> Хотя можещь заметить, что никаких ухищрений по повышению производительности работы с памятью не делается. Интересно, не правда ли?


А что собственно интересного? Ну, ошибся. Ну, получил не верные результаты.

Собственно этот тест не был призван продемонстрировать производительность ЖЦ, так как он как раз очень неплохо ложиться на паттерны используемые обычными С-кучами. Но его не долго переделать, так чтобы он демонстрировал это приемущество.

Я чуть-чуть поколдовал над тестом (мой и твоей реализацией) и у меня получились следующие результатаы...
Для С++ (твой тест):
simple alloc_objects
duration: 7.077
price: 0.35385
alloc raw_vectors
duration: 3.516
price: 0.1758

Аналогичный тест на C#:
00:00:00.1742056
Количество сборок в поколнии 0: 97
Количество сборок в поколнии 1: 27
Количество сборок в поколнии 2: 0

Теперь о сути изменений. Естественно я исправил твою ошибку и использовал в С++-тесте wchar_t вместо char. Так же я изменил количество повторений с 8 000 до 80 000 и сделал размер объекта динамически изменяемым.

Собственно вот сам код.
C#:
using System;
using System.Collections.Generic;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        Stopwatch timer = Stopwatch.StartNew();
        List<char[]> list = new List<char[]>(100);

        for (int i = 0; i < 80000; i++)
        {
            list.Add(new char[i % 4 * 1024]);

            if (i % 100 == 0)
                list.Clear();
        }

        Console.WriteLine(timer.Elapsed);
        for (int i = 0; i <= GC.MaxGeneration; i++)
            Console.WriteLine("Количество сборок в поколнии {0}: {1}", i, GC.CollectionCount(i));
    }
}

C++:
// Alloc1.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <iostream>
#include <list>
#include <string>
#include <algorithm>
#include <ctime>

typedef wchar_t TYPE;
static const int Count = 80000;

template< class T >
void
run_and_measure(
                T functor )
{
  const unsigned int cycles = 20u;
  std::clock_t start, finish;

  start = std::clock();
  for( unsigned int i = 0; i != cycles; ++i )
    functor();
  finish = std::clock();

  double duration = double( finish - start ) / CLOCKS_PER_SEC;
  double price = duration / cycles;
  std::cout
    << "duration: " << duration << std::endl
    << "price: " << price << std::endl;
}

void
alloc_objects()
{
  typedef std::list< std::wstring > list_t;

  list_t list;

  for( unsigned int i = 0; i != Count; ++i )
  {
    list.push_back( std::wstring(i % 4 * 1024, 0 ) );

    if( !( i % 100 ) )
      list.clear();
  }
}

void
raw_vector_destroyer( TYPE * p )
{
  delete[] p;
}

void
alloc_raw_vectors()
{
  typedef std::list< TYPE * > list_t;

  list_t list;

  for( unsigned int i = 0; i != Count; ++i )
  {
    list.push_back( new TYPE[i % 4 * 1024] );

    if( !( i % 100 ) )
    {
      std::for_each( list.begin(), list.end(), raw_vector_destroyer );
      list.clear();
    }
  }
}

int
main()
{
  std::cout << "simple alloc_objects" << std::endl;
  run_and_measure( alloc_objects );

  std::cout << "alloc raw_vectors" << std::endl;
  run_and_measure( alloc_raw_vectors );

  return 0;
}


Про Марс не скажу, но его результаты не натуральны. Скорее всего что-то соптимизировалось.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.03.06 15:03
Оценка:
Здравствуйте, prVovik, Вы писали:

V>С чего ты это взял?

V>В моем случае по сравнению со стандартным хипом суммарная производительность программы увеличилась в несколько раз.

Извини, но не верю. Особенно после сказок про 8 000 * 4К сообещений принимаемых по сети.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: плохой язык C++ :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 22.03.06 15:07
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И? То есть мы сошлись на том, что GC порвет большинство рукопашных оптимизаций динамического выделения памяти?


Мне кажется, ты пытаешься выдавать желаемое за действительное. Как насчет порвать простой штатный распределитель памяти в C++?
Автор: eao197
Дата: 22.03.06


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.