Re[15]: Школа С++ от UNIGINE
От: AlexGin Беларусь  
Дата: 10.03.17 13:54
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Стандартная библиотека потоков C++ в принципе работает не плохо и покрывает большинство простых сценариев (WaitForSingleObject в них однозначно входит), хотя и не все функции WinAPI имеют там прямое отображение (с WaitForMultipleObjects есть некоторые вопросы).

+100500
Спасибо, буду в курсе!

_>Однако если мы возьмём какую-то из мощные библиотек многопочности мира C++ (все они естественно кроссплатформенные), то увидим инструмент на голову превосходящий и все возможности стандартной библиотеки C++ и все возможности WinAPI.

Можешь посоветовать что-то конкретное?
То, что позволяет удачно совместить удобочитаемость кода с эффективностью.

_>Ну вот, т.е. получается у вас тоже практически кроссплатформенный (в потенциале) продукт


Теоретически да, кроссплатформенный. ...это как в анекдоте — чем отличается теория, от практики...

_>Ну так если у тебя есть внешняя утилита для генерации этих h файлов по tlb, то зачем тогда эта директива?

Утилита genidl, о которой ты пишешь, входит в комплект продукта MinGW.
Если я пользуюсь продуктом MSVC, мне нет необходимоти применять genidl.
Применение директивы препроцессора #import:
https://msdn.microsoft.com/en-us/library/8etzzkb6(VS.71).aspx
рассчитано так, чтобы НЕ пересоздавать заголовочники для COM компонента, который ранее уже был импортирован в проект.

_>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.

В данной ветке я уже привёл результаты сравнения эффективности
Автор: AlexGin
Дата: 10.03.17
, доказывающие (по самым скромным оценкам), что MSVC в полтора/два раза эффективнее, нежели MinGW.

Дальнейшее обсуждение данной темы, уважаемый alex_public, мы вполне можем переносить в КСВ.
Отредактировано 10.03.2017 14:28 AlexGin . Предыдущая версия . Еще …
Отредактировано 10.03.2017 14:04 AlexGin . Предыдущая версия .
Отредактировано 10.03.2017 13:59 AlexGin . Предыдущая версия .
Отредактировано 10.03.2017 13:56 AlexGin . Предыдущая версия .
Re[15]: Школа С++ от UNIGINE
От: Stanislav V. Zudin Россия  
Дата: 10.03.17 18:15
Оценка: 6 (1)
Здравствуйте, AlexGin, Вы писали:

O>>Мне вот тоже интересно, кто же быстрее (и в каких случаях) — MS C/C++ Compiler или MinGW.


AG>Мои тесты производительности, разработанные окло года назад (вычисления по int числам, double числам и тригонометрия) — здесь:

AG>Результаты прогонов теста на моём рабочем компе приведены ниже — очевидно, что чем быстрее, тем лучше

AG>MinGW 5.3.0 (32bit):

AG>Int числа => 5 sec;
AG>Double => 5 sec;
AG>Trigonometry => 6 sec;

AG>MSVC 2015 (32bit):

AG>Int числа => 2 sec;
AG>Double => 2 sec;
AG>Trigonometry => 4 sec;

AG>P.S. Все исходные коды моего тестового приложения — на GitHub-е

AG>https://github.com/AlexGin/Math.git
AG>если есть желание скачиваем и тестируем

Убрал гуёвые вызовы, состряпал консольное приложение.
Собрал тремя студиями — 2008, 2013 и 2017RC.
У меня результаты получились не столь оптимистичные.

N_MULTIPLY пришлось уменьшить на два порядка (=100000).

VS2008, x386
Trigonometry: 82.408348 msec
Double: 31.626005 msec
Int числа: 39.800537 msec

VS2008, x64
Trigonometry: 92.026453 msec
Double: 34.001156 msec
Int числа: 36.169715 msec

VS2013, x386
Trigonometry: 2568.560003 msec
Double: 18.488439 msec
Int числа: 24.076877 msec

VS2013, x64
Trigonometry: 979.826838 msec
Double: 18.001274 msec
Int числа: 23.740496 msec

VS2017RC, x386
Trigonometry: 2536.576880 msec
Double: 17.856891 msec
Int числа: 23.914318 msec

VS2017RC, x64
Trigonometry: 2538.357091 msec
Double: 18.106746 msec
Int числа: 24.057165 msec



AG>P.P.S. Теперь ясно, почему же среда разработки Qt Creator для Windows попадает к нам откомпилированной (авторами из независимой Qt Company), именно на таком "ненавистном" MSVC...





  сорец

#define _USE_MATH_DEFINES

#include <stdio.h>
#include <tchar.h>

#include <Windows.h>
#include <math.h>
#include <time.h>
// ==========================================================================
// Stop watch class.
class CStopWatch
{
public:
    // Constructor.
    CStopWatch()
    {
        // Ticks per second.
        QueryPerformanceFrequency( &liPerfFreq );
    }

    // Start counter.
    void Start()
    {
        liStart.QuadPart = 0;
        QueryPerformanceCounter( &liStart );
    }

    // Stop counter.
    void Stop()
    {
        liEnd.QuadPart = 0;
        QueryPerformanceCounter( &liEnd );
    }

    // Get duration.
    long double GetDuration()
    {
        return ( (liEnd.QuadPart - liStart.QuadPart) / long double(liPerfFreq.QuadPart) ) * 1000;    //return result in milliseconds
    }

private:
    LARGE_INTEGER liStart;
    LARGE_INTEGER liEnd;
    LARGE_INTEGER liPerfFreq;
};

// ==========================================================================
int N_MULTIPLY = 100000;// 00;
const int N_GENERATED = 1000;

int randoms[N_GENERATED];
int outputs[N_GENERATED];

double randDbl[N_GENERATED];
double outpDbl[N_GENERATED];

static void generate_randoms()
{
    CStopWatch watch;
    watch.Start();

    for( int i = 0; i < N_GENERATED; i++ )
        randoms[i] = rand();

    watch.Stop();
    long double dur = watch.GetDuration();
    printf("Generating int randoms took %lf msec\n", dur);
}

static void nativeCompute()
{
    CStopWatch watch;
    watch.Start();

    int result = 0;
    for(int i = 2; i < N_MULTIPLY; i++)
    {
        for( int j = 0; j < N_GENERATED; j++ )
        {
            result = randoms[j] * i;
            result++;
            outputs[j] = result;
        }
    }
    watch.Stop();
    long double dur = watch.GetDuration();
    printf( "Native took %lf msec\n", dur );
}

static void generate_dbl_randoms()
{
    CStopWatch watch;
    watch.Start();

    for (int i = 0; i < N_GENERATED; i++)
        randDbl[i] = double(1.11 * (double)rand());

    watch.Stop();
    long double dur = watch.GetDuration();
    printf( "Generating double randoms took %lf msec\n", dur );
}

static void nativeComputeDbl() // Floating Point
{
    CStopWatch watch;
    watch.Start();

    double resultDbl = 0.0;
    for(int i = 2; i < N_MULTIPLY; i++)
    {
        for( int j = 0; j < N_GENERATED; j++ )
        {
            double dbMult = (double)(i * 1.1);
            resultDbl = randDbl[j] * dbMult;
            resultDbl += 1.555;
            outpDbl[j] = resultDbl;
        }
    }
    watch.Stop();
    long double dur = watch.GetDuration();
    printf( "Double took %lf msec\n", dur );
}

static void nativeComputeTrg() // Trigonometry
{
    CStopWatch watch;

    watch.Start();
    double resultDbl = 0.0;    
    for(int i = 2; i < N_MULTIPLY; i++)
    {
        for( int j = 0; j < N_GENERATED; j++ )
        {
            double dbMult = (double)(i * 2 * M_PI);
            resultDbl = randDbl[j] + sin(dbMult);
            resultDbl += 0.375;
            outpDbl[j] = resultDbl;
        }
    }
    watch.Stop();
    long double dur = watch.GetDuration();
    printf( "Trig took %lf msec\n", dur );
}

// ==========================================================================
int main(int argc, char* argv[])
{
    if (argc > 1)
    {
        N_MULTIPLY = atol(argv[1]);
    }

    time_t tt;
    srand(time(&tt));

    generate_dbl_randoms();
    nativeComputeTrg();
    nativeComputeDbl();

    generate_randoms();
    nativeCompute();

    printf( "Finita\n" );

    return 0;
}
_____________________
С уважением,
Stanislav V. Zudin
Re[16]: Школа С++ от UNIGINE
От: AlexGin Беларусь  
Дата: 10.03.17 19:09
Оценка:
Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Убрал гуёвые вызовы, состряпал консольное приложение.

SVZ>Собрал тремя студиями — 2008, 2013 и 2017RC.
SVZ>У меня результаты получились не столь оптимистичные.
Это ещё зависит от компьютера — здесь (на работе) у меня комп куда более мощный, чем старенький домашний.

SVZ>N_MULTIPLY пришлось уменьшить на два порядка (=100000).

Да, если исользовать вызов QueryPerformanceFrequency то может и логично.

SVZ>VS2008, x386

SVZ>Trigonometry: 82.408348 msec
SVZ>Double: 31.626005 msec
SVZ>Int числа: 39.800537 msec

SVZ>VS2008, x64

SVZ>Trigonometry: 92.026453 msec
SVZ>Double: 34.001156 msec
SVZ>Int числа: 36.169715 msec

SVZ>VS2013, x386

SVZ>Trigonometry: 2568.560003 msec // Очень большие цифры по тригонометрии!!!
SVZ>Double: 18.488439 msec
SVZ>Int числа: 24.076877 msec

SVZ>VS2013, x64

SVZ>Trigonometry: 979.826838 msec
SVZ>Double: 18.001274 msec
SVZ>Int числа: 23.740496 msec

SVZ>VS2017RC, x386

SVZ>Trigonometry: 2536.576880 msec
SVZ>Double: 17.856891 msec
SVZ>Int числа: 23.914318 msec

SVZ>VS2017RC, x64

SVZ>Trigonometry: 2538.357091 msec
SVZ>Double: 18.106746 msec
SVZ>Int числа: 24.057165 msec

За счёт чего так долго считает тригонометрию?
Обычно отличия от данных double для тригонометрии примерно в 2...3 раза.
Может там DEBUG версия?
Re[17]: Школа С++ от UNIGINE
От: Stanislav V. Zudin Россия  
Дата: 10.03.17 20:46
Оценка:
Здравствуйте, AlexGin, Вы писали:

SVZ>>У меня результаты получились не столь оптимистичные.

AG>Это ещё зависит от компьютера — здесь (на работе) у меня комп куда более мощный, чем старенький домашний.

i7-4790K CPU @ 4.00GHz не самый медленный, однако...

SVZ>>N_MULTIPLY пришлось уменьшить на два порядка (=100000).

AG>Да, если исользовать вызов QueryPerformanceFrequency то может и логично.

Просто при исходном значении результата было не дождаться.

SVZ>>VS2013, x386

SVZ>>Trigonometry: 2568.560003 msec // Очень большие цифры по тригонометрии!!!


AG>За счёт чего так долго считает тригонометрию?

AG>Обычно отличия от данных double для тригонометрии примерно в 2...3 раза.
AG>Может там DEBUG версия?

Не, везде релизные версии, но код генерится сильно разный.

Вот фрагменты с вычислением синуса:
VS2008 x386

; 135  :             double dbMult = (double)(i * 2 * M_PI);
; 136  :             resultDbl = randDbl[j] + sin(dbMult);

    fild    DWORD PTR tv243[esp+60]
    fmul    QWORD PTR __real@400921fb54442d18
    call    __CIsin
    fstp    QWORD PTR tv252[esp+60]
    movsd    xmm0, QWORD PTR tv252[esp+60]
    movsd    xmm1, QWORD PTR __real@3fd8000000000000
    xor    eax, eax
$LL3@nativeComp:
    movsd    xmm2, QWORD PTR ?randDbl@@3PANA[eax]
    addsd    xmm2, xmm0

; 137  :             resultDbl += 0.375;

    addsd    xmm2, xmm1

; 138  :             outpDbl[j] = resultDbl;

    movsd    QWORD PTR ?outpDbl@@3PANA[eax], xmm2



VS2013 x386
; 135  :             double dbMult = (double)(i * 2 * M_PI);

    movd    xmm0, edi
    cvtdq2pd xmm0, xmm0
    mulsd    xmm0, QWORD PTR __real@400921fb54442d18

; 136  :             resultDbl = randDbl[j] + sin(dbMult);

    call    __libm_sse2_sin_precise
    addsd    xmm0, QWORD PTR ?randDbl@@3PANA[esi]
    add    edi, 2

; 137  :             resultDbl += 0.375;

    addsd    xmm0, QWORD PTR __real@3fd8000000000000

; 138  :             outpDbl[j] = resultDbl;

    movsd    QWORD PTR ?outpDbl@@3PANA[esi], xmm0



VS2013 x64

    cmp    ebp, 2
    jle    SHORT $LN5@nativeComp
    movsdx    xmm6, QWORD PTR ?randDbl@@3PANA[rdi+r14]
    mov    ebx, 4
    lea    esi, DWORD PTR [rbp-2]
    npad    5
$LL3@nativeComp:

; 141  :         {
; 142  :             double dbMult = (double)(i * 2 * M_PI);

    movd    xmm0, ebx
    cvtdq2pd xmm0, xmm0
    mulsd    xmm0, xmm7

; 143  :             resultDbl = randDbl[j] + sin(dbMult);

    call    sin
    add    ebx, 2
    addsd    xmm0, xmm6

; 144  :             resultDbl += 0.375;

    addsd    xmm0, xmm8
    dec    rsi
    jne    SHORT $LL3@nativeComp
    movsdx    QWORD PTR ?outpDbl@@3PANA[rdi+r14], xmm0


Машина с 2017 Студией сейчас недоступна, не могу показать листинг, но думаю, что там не сильно большие отличия от 2013.
_____________________
С уважением,
Stanislav V. Zudin
Re[18]: Школа С++ от UNIGINE
От: AlexGin Беларусь  
Дата: 11.03.17 00:12
Оценка:
Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>i7-4790K CPU @ 4.00GHz не самый медленный, однако...


SVZ>>>N_MULTIPLY пришлось уменьшить на два порядка (=100000).

AG>>Да, если исользовать вызов QueryPerformanceFrequency то может и логично.

SVZ>Просто при исходном значении результата было не дождаться.


Стоп! Вот тут, надо разобраться!
Те вычисления, что на моём быстром компе (на офисе) выполняются за 2 sec, на домашнем (древнем) компе выполняются за 10...11 sec.
Это всё притом, что и в том, и в другом случае — у меня используется исходное значение:
    const int N_MULTIPLY = 10000000;

В этом контексте что-то странно сочетается:
i7-4790K CPU @ 4.00GHz и:
при исходном значении результата было не дождаться...

Вот мои опции компиляции для проекта (в среде MSVC) под Qt (это определяет Qt VS Addin а также и его настройки):

/GS /analyze- /W3 /wd"4577" /wd"4467" /Zc:wchar_t /I"." /I"C:\Qt\Qt5.8.0\5.8\msvc2015\include" /I"C:\Qt
\Qt5.8.0\5.8\msvc2015\include\QtWidgets" /I"C:\Qt\Qt5.8.0\5.8\msvc2015\include\QtGui" /I"C:\Qt
\Qt5.8.0\5.8\msvc2015\include\QtANGLE" /I"C:\Qt\Qt5.8.0\5.8\msvc2015\include\QtCore" /I"release" /I"C:
\Qt\Qt5.8.0\5.8\msvc2015\mkspecs\win32-msvc2015" /I".\GeneratedFiles" /Gm- /O2 /Fd"Win32\Release
\vc140.pdb" /Zc:inline /fp:precise /D "_WINDOWS" /D "UNICODE" /D "WIN32" /D "QT_NO_DEBUG" /D "QT_WIDGETS_LIB" /D
"QT_GUI_LIB" /D "QT_CORE_LIB" /D "NDEBUG" /errorReport:prompt /WX- /Zc:forScope
/GR /Gd /Oy- /MD /Fa"release\" /EHsc /nologo /Fo"Win32\Release\" /Fp"Win32\Release\Math.pch"


А это — те же опции для простого консольного проекта (без Qt):

/Yu"stdafx.h" /GS /GL /analyze- /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /Fd"Release\vc140.pdb" /Zc:inline
/fp:precise /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt
/WX- /Zc:forScope /Gd /Oy- /Oi /MD /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\Math.pch"

Может — причина в настройках оптимизации?
Отредактировано 11.03.2017 0:47 AlexGin . Предыдущая версия . Еще …
Отредактировано 11.03.2017 0:40 AlexGin . Предыдущая версия .
Re[15]: Школа С++ от UNIGINE
От: alex_public  
Дата: 11.03.17 07:53
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Мои тесты производительности, разработанные окло года назад (вычисления по int числам, double числам и тригонометрия) — здесь:

AG>https://github.com/AlexGin/Math/blob/master/mainwindow.cpp
AG>...
AG>P.S. Все исходные коды моего тестового приложения — на GitHub-е
AG>https://github.com/AlexGin/Math.git
AG>если есть желание скачиваем и тестируем

Мой подробный ответ тут http://rsdn.org/forum/cpp/6722631.1
Автор: alex_public
Дата: 11.03.17
. А если кратко, то предлагаю тебе закомментировать в своём тесте вот эти куски кода (они же не должны влиять на сам тест, не так ли?):
if (!(i % 100000))
{
    int val = ui->progressBar->value();
    ui->progressBar->setValue(++val);
}

и прогнать тест заново — узнаешь много нового.

И да, спасибо за предоставление мне нового аргумента для подобных дискуссий. ) А вам там счастливо пользоваться этим замечательным продуктом...
Re[18]: Школа С++ от UNIGINE
От: alex_public  
Дата: 11.03.17 08:02
Оценка:
Здравствуйте, Stanislav V. Zudin, Вы писали:

Разгадку несовпадения результатов можешь увидеть здесь http://rsdn.org/forum/cpp/6722631.1
Автор: alex_public
Дата: 11.03.17
— тебе тоже похоже не стоило тебе выкидывать уведомление о прогрессе из цикла. Кстати, если у тебя так много разных версий MSVC под рукой, то ты наверное можешь оценить в каких эти чудеса имеют место, а в каких нет (в нормальном компиляторе результат теста не должен меняться от комментирования той строки в моём коде).
Re[16]: Школа С++ от UNIGINE
От: alex_public  
Дата: 11.03.17 08:27
Оценка:
Здравствуйте, AlexGin, Вы писали:

_>>Однако если мы возьмём какую-то из мощные библиотек многопочности мира C++ (все они естественно кроссплатформенные), то увидим инструмент на голову превосходящий и все возможности стандартной библиотеки C++ и все возможности WinAPI.

AG>Можешь посоветовать что-то конкретное?
AG>То, что позволяет удачно совместить удобочитаемость кода с эффективностью.

Если говорить о классической многопоточности, то чуть-чуть более мощными чем стандартная библиотека C++ являются Boost.Thread и QThread (да, да, в используемой вами Qt уже есть не плохая поддержка многопоточности). Но если требуется действительно мощный инструмент, то лучше смотреть на что-то вроде TBB от Intel.

Если же говорить о многопоточности по модели акторов (она удобнее и безопаснее в очень многих случаях), то тут однозначно выбор будет между SObjectizer (кстати разработчики присутствуют на данном форуме) и CAF (более глобальное решение).

_>>Ну вот, т.е. получается у вас тоже практически кроссплатформенный (в потенциале) продукт

AG>
AG>Теоретически да, кроссплатформенный. ...это как в анекдоте — чем отличается теория, от практики...

Ну естественно, что если вам вдруг поставят задачу сделать своё ПО кроссплатформенным и вы пойдёте его компилировать и тестировать на других платформах, то скорее всего вылезет определённое количество ошибок и недоработок. Это нормальная ситуация. Принципиальная разница тут в другом — вам на исправление подобного понадобится какое-то количество дней. А вот если бы ваше приложение было написано на WinAPI (к примеру), то задачу сделать его кроссплатформенным вам бы пришлось решать какое-то количество месяцев или лет. )))

_>>Ну так если у тебя есть внешняя утилита для генерации этих h файлов по tlb, то зачем тогда эта директива?

AG>Утилита genidl, о которой ты пишешь, входит в комплект продукта MinGW.
AG>Если я пользуюсь продуктом MSVC, мне нет необходимоти применять genidl.
AG>Применение директивы препроцессора #import:
AG>https://msdn.microsoft.com/en-us/library/8etzzkb6(VS.71).aspx
AG>рассчитано так, чтобы НЕ пересоздавать заголовочники для COM компонента, который ранее уже был импортирован в проект.

В MSVC (а точнее в WindowsSDK) так же имеются все необходимые инструменты для подобного (там есть и экстрактор idl из tlb и компилятор idl). Так что никакой пользы от данной инструкции нет.

_>>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.

AG>В данной ветке я уже привёл результаты сравнения эффективности
Автор: AlexGin
Дата: 10.03.17
, доказывающие (по самым скромным оценкам), что MSVC в полтора/два раза эффективнее, нежели MinGW.


Я уже ответил на данное сравнение. ))) И кстати могу ещё посоветовать на будущее изучить опции gcc перед его использованием, потому как его дефолтный режим мягко говоря далёк до максимальной производительности.
Re[19]: Школа С++ от UNIGINE
От: Stanislav V. Zudin Россия  
Дата: 11.03.17 19:00
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Разгадку несовпадения результатов можешь увидеть здесь http://rsdn.org/forum/cpp/6722631.1
Автор: alex_public
Дата: 11.03.17
— тебе тоже похоже не стоило тебе выкидывать уведомление о прогрессе из цикла. Кстати, если у тебя так много разных версий MSVC под рукой, то ты наверное можешь оценить в каких эти чудеса имеют место, а в каких нет (в нормальном компиляторе результат теста не должен меняться от комментирования той строки в моём коде).


Алекс, респектище тебе!

"Волшебная" строка внутри цикла
if (i == 0) printf("preved medved\n");


натурально ускоряет код на два порядка. Такого я от компилятора не ожидал.

2008 Студия на эту строку не реагирует — код работает одинаково быстро.
А вот 2013 и 2017 ускоряются.
_____________________
С уважением,
Stanislav V. Zudin
Re[19]: Школа С++ от UNIGINE
От: Stanislav V. Zudin Россия  
Дата: 11.03.17 19:08
Оценка:
Здравствуйте, AlexGin, Вы писали:

SVZ>>Просто при исходном значении результата было не дождаться.


AG>Стоп! Вот тут, надо разобраться!

AG>Те вычисления, что на моём быстром компе (на офисе) выполняются за 2 sec, на домашнем (древнем) компе выполняются за 10...11 sec.

AG>А это — те же опции для простого консольного проекта (без Qt):

AG>

AG>/Yu"stdafx.h" /GS /GL /analyze- /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /Fd"Release\vc140.pdb" /Zc:inline
AG>/fp:precise /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt
AG>/WX- /Zc:forScope /Gd /Oy- /Oi /MD /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\Math.pch"

AG>Может — причина в настройках оптимизации?

Настройки те же, причина оказалась в кодогенерации, alex_public оказался прав (см. параллельное сообщение).

Надо будет попробовать интеловский компилятор. Всё равно MKL используем.
_____________________
С уважением,
Stanislav V. Zudin
Re[12]: Школа С++ от UNIGINE
От: Erop Россия  
Дата: 11.03.17 20:57
Оценка: 8 (1)
Здравствуйте, AlexGin, Вы писали:

AG>Здесь вопрос не столько насчёт той либо иной предметной области, сколько в плане GUI компонентов (с которыми для Linux, IMHO, проблемы).

Оч от предметной области зависит.

IMHO, по хорошему под винду, лялих, макось и мобильные платформы (тут можно смотреть все стразу или две-три смотреть) проектировать GUI надо по разному.
Соответственно если engine может быть сильно переносимый, то в GUI могут быть какие-то разделяемые между платформами компоненты и даже подходы, но реализаций всё равно лучше иметь пять-шесть
Или, например, под основные платформы + какой-то умеренно поганый универсальный, скажем HTML-based.

С другой стороны, если в engine есть какие-то тяжёлые запросы к железу, ну, например, какая-то крутая многопоточность (ну, например, приложение должно грузить десяток потоков) или большая нагрузка на память, на сеть и т. д, то неизбежно лезут адаптации под платформы. Просто потому, что разные ОС и разное железо имеют разные особенности...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Школа С++ от UNIGINE
От: Erop Россия  
Дата: 11.03.17 21:06
Оценка:
Здравствуйте, alex_public, Вы писали:

_>А вот первое — это уже сложнее и получается без дополнительных усилий только в том случае, если в предметной области имеется достаточное количество удобных кроссплатформенных библиотек. И во многих случаях это именно так и происходит (даже просто Boost + Qt перекрывают огромную область использования OS API), но естественно не для всех. Вот какие конкретно Windows API вам приходится использовать напрямую (без удобных библиотек обёрток), получая тем самым не кроссплатформенное приложение? )


Ну, например, работа с памятью: отображение файлов на память, создание память, разделяемой между процессами, свои аллокаторы и т. д...

_>Верно. Но вы эту кроссплатформенность получили автоматом. Теперь следующий вопрос: почему ты думаешь, что в других частях вашего приложения (не GUI) ситуация другая? )

IMHO, для Windows, для Linux, и для андроида надо делать три разных UI. И то, что их можно все скомпилировать под все три платформы не важно.

_>А вот это как раз пример вредного (не входящего в стандарт языка, т.е. нарушающего "кросскомпиляторность") расширения от MS, которое не надо использовать.

Разработка деятельность прагматическая.
Для каких-то целей такое использовать нехорошо, а для стиля "фигак-фигак и в продакшин" очень даже и хорошо
Есть же тонны ПО, которое нужно было ещё вчера, а завтра будет не нужно.

_>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.

Интересно бы посмотреть, что за тесты. Обычно эффективность генерируемого кода очень зависит от задач.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Школа С++ от UNIGINE
От: AlexGin Беларусь  
Дата: 11.03.17 22:04
Оценка: +1
Здравствуйте, Erop, Вы писали:

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


AG>>Здесь вопрос не столько насчёт той либо иной предметной области, сколько в плане GUI компонентов (с которыми для Linux, IMHO, проблемы).

E>От предметной области зависит.
Да, но здесь будет набор решений для той или иной предметной области на базе определённых GUI компонентов.

E>IMHO, по хорошему под винду, лялих, макось и мобильные платформы (тут можно смотреть все стразу или две-три смотреть) проектировать GUI надо по разному.

+100500
Вот поэтому и термин "кроссплатформенность" без тестов и проработок — это скорее из теории, чем из практики.

E>Соответственно если engine может быть сильно переносимый, то в GUI могут быть какие-то разделяемые между платформами компоненты и даже подходы, но реализаций всё равно лучше иметь пять-шесть

E>Или, например, под основные платформы + какой-то умеренно поганый универсальный, скажем HTML-based.
Примерно так.

E>С другой стороны, если в engine есть какие-то тяжёлые запросы к железу, ну, например, какая-то крутая многопоточность (ну, например, приложение должно грузить десяток потоков) или большая нагрузка на память, на сеть и т. д, то неизбежно лезут адаптации под платформы. Просто потому, что разные ОС и разное железо имеют разные особенности...

+100500
Совершенно верно!
И здесь применение универсальных решений (в погоне за следованием стандарту C++ и кросплатформенности) может дать больше вреда, чем пользы!
Re[14]: Школа С++ от UNIGINE
От: alex_public  
Дата: 11.03.17 22:32
Оценка: +1
Здравствуйте, Erop, Вы писали:

_>>А вот первое — это уже сложнее и получается без дополнительных усилий только в том случае, если в предметной области имеется достаточное количество удобных кроссплатформенных библиотек. И во многих случаях это именно так и происходит (даже просто Boost + Qt перекрывают огромную область использования OS API), но естественно не для всех. Вот какие конкретно Windows API вам приходится использовать напрямую (без удобных библиотек обёрток), получая тем самым не кроссплатформенное приложение? )

E>Ну, например, работа с памятью: отображение файлов на память, создание память, разделяемой между процессами, свои аллокаторы и т. д...

По большей части есть в Boost'е. )

_>>Если речь по быстродействие генерируемого кода, то это полная чушь — MinGW генерирует заметно более эффективный код. Я лично делал тесты.

E>Интересно бы посмотреть, что за тесты. Обычно эффективность генерируемого кода очень зависит от задач.

Эффективность генерируемого кода (если мы говорим о разных компиляторах одного и того же языка программирования) в первую очередь зависит от умения оптимизатора использовать особенности работы процессора.
Re[15]: Школа С++ от UNIGINE
От: Erop Россия  
Дата: 11.03.17 23:02
Оценка: -1
Здравствуйте, alex_public, Вы писали:

_>>>Вот какие конкретно Windows API вам приходится использовать напрямую (без удобных библиотек обёрток), получая тем самым не кроссплатформенное приложение? )

E>>Ну, например, работа с памятью: отображение файлов на память, создание память, разделяемой между процессами, свои аллокаторы и т. д...

_>По большей части есть в Boost'е. )

Во-первых, так как буст никем не поддерживается, в коде продуктов, по которым гарантируется поддержка и работоспособность его использовать нельзя.

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


E>>Интересно бы посмотреть, что за тесты. Обычно эффективность генерируемого кода очень зависит от задач.


_>Эффективность генерируемого кода (если мы говорим о разных компиляторах одного и того же языка программирования) в первую очередь зависит от умения оптимизатора использовать особенности работы процессора.


Это тоже, обычно, зависит от задач.
Например, если компилятор хорошо умеет векторизовать циклы, а задача куча рандомных ветвлений, то он проиграет. А вот на линейной алгебре выиграет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: Школа С++ от UNIGINE
От: alex_public  
Дата: 12.03.17 01:29
Оценка: +3
Здравствуйте, Erop, Вы писали:

_>>По большей части есть в Boost'е. )

E>Во-первых, так как буст никем не поддерживается, в коде продуктов, по которым гарантируется поддержка и работоспособность его использовать нельзя.

Ну у меня противоположное мнение: я считаю, что как раз наоборот для большей надёжности ПО лучше заменять все сомнительные велосипеды на код из Boost'a. Но это уже скорее холиварный вопрос, так что лучше его оставить. )

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


Я говорил про перечисленные тобой отображаемые файлы, IPC, нестандартные аллокаторы (таких полно в бусте) и т.п. Про "резервирование адресного пространства" ты ничего не писал. Кстати, а что под этим подразумевается, прямое использование VirtualAlloc/sbrk?
Re[17]: Школа С++ от UNIGINE
От: Erop Россия  
Дата: 12.03.17 17:09
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Ну у меня противоположное мнение: я считаю, что как раз наоборот для большей надёжности ПО лучше заменять все сомнительные велосипеды на код из Boost'a. Но это уже скорее холиварный вопрос, так что лучше его оставить. )

+100500

На саммом деле всё от бизнес-модели зависит. Если в случае чего ты таки должен взять и БЫСТРО починить, то чем проще велики ты используешь, тем лучше...
Ну, то есть ни на АЭС, ни на МКС я бы буст юзатьне стал...
Но это вопрос оценки рисков или холивара

_>Я говорил про перечисленные тобой отображаемые файлы,

Я ответил на вопрос "что используете"...
Кстати, о бусте и файлах и мэппингах.
Я не очень в курсе, как оно работает в бусте, можешь ответить на пару вопросов?
1) Я знаю место, где открывают файл, потом его отображают, а файл закрывают. После чего его можно переименовывать, переносить внутри тома, но нельзя удалять, например. И так он и живёт какое-то время пока пишут модифицированную копию, потом копию тоже мапят, их все переименовывают по кругу и получают repare на ходу. При этом всё время есть доступ к отмапированным данным. Как это сделать поверх буста?
2) Я знаю место, где время от времени делают открытому файлу fseek ЗА конец файла, а потом иногда туда пишут что-нибудь.
На разных ОС отматывание места на диске происходит в разные моменты времени. Когда fssek'аешь за конец, когда пишешь или когда flush'иши. Буст это поведение как-то стандартизирует? Если да, то за как и за счёт чего?
В том месте, которое я знаю, для разных ОС написана разная логика.


_>IPC, нестандартные аллокаторы (таких полно в бусте) и т.п. Про "резервирование адресного пространства" ты ничего не писал. Кстати, а что под этим подразумевается, прямое использование VirtualAlloc/sbrk?

Ну, обычно, нестандартные аллокаторы нужны не потому, что они какие-то нестандартные, а под задачу.
Я имел в виду конкретную конструкцию, например, когда мы через VirtualAlloc резервируем АП, а потом коммитим его по мере нужды, заводя тем самым, фактически, альтернативный стек на волокно/задачу/замыкание.
Чем тут поможет буст?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: Школа С++ от UNIGINE
От: Skorodum Россия  
Дата: 14.03.17 11:22
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>2) Выбор вариантов для Windows, намного шире, чем для Linux.

Не знаю, как это демонстрирует превосходство винды или Qt под виндой, но это зато прекрасно демонстрирует, что компиляторы от МС хуже между собой совместимы и что МС относительно недавно перешла на x64.

AG>Насчёт документации, возможно именно так, но вот насчёт установки пакетов — не всё так однозначно:

AG>Есть *.deb пакеты для Ubuntu/Debian; есть *.rpm пакеты для Red Hat. Нет общего знаменателя!
AG>Проблема у Linux одна:
AG>Отсутствие центрального руководящего аппарата, который бы определял глобальные системные стандарты
Стандарты есть, POSIX называется, есть руководящий аппарат с Торвальдсом во главе. Универсального пакетного менеджера — нет, но его нигде нет.

AG>P.S. Поверьте, что меня самого бесит фраза: "One Microsoft way", однако когда приложение, разработанное под Windows 95,

AG>легко запускается (спустя два десятилетия) на Windows 10, сам начинаешь понимать, ЧТО СТОИТ за этими словами...
Это да.
Re[18]: Школа С++ от UNIGINE
От: alex_public  
Дата: 14.03.17 14:41
Оценка:
Здравствуйте, Erop, Вы писали:

_>>Я говорил про перечисленные тобой отображаемые файлы,

E>Я ответил на вопрос "что используете"...
E>Кстати, о бусте и файлах и мэппингах.
E>Я не очень в курсе, как оно работает в бусте, можешь ответить на пару вопросов?

Очевидно, что подобные кроссплатформенные библиотеки обычно предоставляют API являющиеся пересечением множеств соответствующих нативных API поддерживаемых платформ. И для подавляющего числа задача этого обычно хватает. Однако естественно есть задачи (и я сам сталкивался с такими), в которых этого не хватает. Только вот в таких случаях проблемой становится уже даже не написание кроссплатформенного ПО, а вообще сама возможность реализации данного ПО для некоторых платформ. )))

E>1) Я знаю место, где открывают файл, потом его отображают, а файл закрывают. После чего его можно переименовывать, переносить внутри тома, но нельзя удалять, например. И так он и живёт какое-то время пока пишут модифицированную копию, потом копию тоже мапят, их все переименовывают по кругу и получают repare на ходу. При этом всё время есть доступ к отмапированным данным. Как это сделать поверх буста?


Вряд ли получится — для отображаемых файлов Буст предоставляет относительно простое и высокоуровневое решение. Оно позволяет в одну строчку (реально одну, и я это использовал — очень удобно) получить решение, подходящие для самых распространённых случаев, но при этом скрывает все детали внутри. Так что для всяческих тонких игр оно не поможет.

E>2) Я знаю место, где время от времени делают открытому файлу fseek ЗА конец файла, а потом иногда туда пишут что-нибудь.

E>На разных ОС отматывание места на диске происходит в разные моменты времени. Когда fssek'аешь за конец, когда пишешь или когда flush'иши. Буст это поведение как-то стандартизирует? Если да, то за как и за счёт чего?

А зачем Буст в этом случае? Это же просто работа с функцией стандартной библиотеки C. Эта функция уже есть на всех нужных платформах и её поведение вполне документировано. Вот прямо тут http://en.cppreference.com/w/c/io/fseek можно увидеть описание указанной особенности. Более того, очевидно что тут без проблем код пишется одинаково для всех платформ. А появление каких-то особенностей говорит о желаниях специфических оптимизаций.

E>В том месте, которое я знаю, для разных ОС написана разная логика.


Ну вот видишь, если это в принципе реализуемо на разных ОС (естественно разным кодом — собственно значительная часть Буста внутри так и выглядит), то значит и без проблем могло бы быть добавленным в Буст. Просто на данный момент на нашлось желающих формализовать это в библиотеку. Или же это уж совсем редкий случай, явно больше никому не нужный. Так что это у вас ещё были хорошие случаи — гораздо хуже натолкнуться на реально не переносимую особенность платформы.

_>>IPC, нестандартные аллокаторы (таких полно в бусте) и т.п. Про "резервирование адресного пространства" ты ничего не писал. Кстати, а что под этим подразумевается, прямое использование VirtualAlloc/sbrk?

E>Ну, обычно, нестандартные аллокаторы нужны не потому, что они какие-то нестандартные, а под задачу.
E>Я имел в виду конкретную конструкцию, например, когда мы через VirtualAlloc резервируем АП, а потом коммитим его по мере нужды, заводя тем самым, фактически, альтернативный стек на волокно/задачу/замыкание.
E>Чем тут поможет буст?

Текущий Буст? Ничем. Там вроде нет сейчас абстракции над функциями ОС работы с виртуальной памятью. Но если ты такое напишешь и добавишь, то... )))
Re[19]: Школа С++ от UNIGINE
От: Erop Россия  
Дата: 14.03.17 14:51
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Очевидно, что подобные кроссплатформенные библиотеки обычно предоставляют API являющиеся пересечением множеств соответствующих нативных API поддерживаемых платформ. И для подавляющего числа задача этого обычно хватает. Однако естественно есть задачи (и я сам сталкивался с такими), в которых этого не хватает. Только вот в таких случаях проблемой становится уже даже не написание кроссплатформенного ПО, а вообще сама возможность реализации данного ПО для некоторых платформ. )))


+100500, вернее я бы сказал одинаковой реализации одних и тех же фич на разных платформах.

_>Вряд ли получится — для отображаемых файлов Буст предоставляет относительно простое и высокоуровневое решение. Оно позволяет в одну строчку (реально одну, и я это использовал — очень удобно) получить решение, подходящие для самых распространённых случаев, но при этом скрывает все детали внутри. Так что для всяческих тонких игр оно не поможет.


Ну в моей практике либо мапится весь файл, и тогда это можно вообще как-то без мапингов делать на крайняк, либо какие-то тонкие танцы.
Понятно, спасибо.

_>А зачем Буст в этом случае? Это же просто работа с функцией стандартной библиотеки C. Эта функция уже есть на всех нужных платформах и её поведение вполне документировано. Вот прямо тут http://en.cppreference.com/w/c/io/fseek можно увидеть описание указанной особенности. Более того, очевидно что тут без проблем код пишется одинаково для всех платформ. А появление каких-то особенностей говорит о желаниях специфических оптимизаций.

Так всегда тонкости из-ща оптимизаций и лезут.


E>>В том месте, которое я знаю, для разных ОС написана разная логика.


_>Ну вот видишь, если это в принципе реализуемо на разных ОС (естественно разным кодом — собственно значительная часть Буста внутри так и выглядит), то значит и без проблем могло бы быть добавленным в Буст.

Так я и спрашиваю тебя, как знатока, перенесено это в буст или нет

_>Текущий Буст? Ничем. Там вроде нет сейчас абстракции над функциями ОС работы с виртуальной памятью. Но если ты такое напишешь и добавишь, то... )))

Это никто не будет поддерживать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.