Re[35]: «Собаку съел»
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.01.17 12:28
Оценка:
Здравствуйте, vdimas, Вы писали:

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

V>>>Это всё к тому, что твой пример с copy&paste вот этого:
V>>>
V>>>where(x => x > q)
V>>>

V>>>в общем случае является плохой практикой.
V>>>Но язык позволяет только такую.
S>> Чем это плохо?

V>Тем, вестимо, что в каждом конкретном месте можно допустить ошибку.
V>По сей причине и рождается "матрица специализаций", типа этой.
V>По ссылке автогенерённый код. В этом смысле С++ позволяет выполнять такую кодогенерацию прямо в исходниках.
И ты тудаже. Ты мои ссылки вообще игнорируешь? По приведенной ссылке прежде много кода генерится всего из за того, что код не инлайнится.
Я привел тебе ссылки где методы инлайнятся и нет разницы между value и ref типами

S>>В С++ зря штоли ввели Лямбды?

V>Моя рука потихоньку тянется к лицу. ))

V>Давай сделаем паузу и посмотрим на это всё повнимательней. Лямбды хороши исключительно и только для уникальных случаев, в этом и состоит их ЦЕЛЕВАЯ фишка — они же захватывают текущий контекст! Т.е., твоё x => x > q — это ж вовсе не лямбда (вот почему рука дрогнула в направлении лица), это ж у тебя просто некая "маленькая процедура", которая использует возможность локального объявления процедур (лямбд), не используя при этом их основной механизм. Вполне же можно было объявить такой предикат вне контекста использования, верно? Т.е., получилась лишь некая экономия сугубо на "оформлении" такого предиката в виде отдельной ф-ии.

А что же это такое? Лямбда, замыкание, который может захватывать и внутренние переменные например
var f=5;

.Where(x => x > q+f).Select(x => x + f).Sum();


Еще раз посмотри как эти лямбды разворачиваются

Optimising LINQ
roslyn-linq-rewrite

roslyn-linq-rewrite
This tool compiles C# code by first rewriting the syntax trees of LINQ expressions using plain procedural code, minimizing allocations and dynamic dispatch.
Example input code

public int Method1()
{
    var arr = new[] { 1, 2, 3, 4 };
    var q = 2;
    return arr.Where(x => x > q).Select(x => x + 3).Sum();
}

Allocations: input array, array enumerator, closure for q, Where delegate, Select delegate, Where enumerator, Select enumerator.
Decompiled output code

public int Method1()
{
    int[] arr = new[] { 1, 2, 3, 4 };
    int q = 2;
    return this.Method1_ProceduralLinq1(arr, q);
}
private int Method1_ProceduralLinq1(int[] _linqitems, int q)
{
    if (_linqitems == null) throw new ArgumentNullException();

    int num = 0;
    for (int i = 0; i < _linqitems.Length; i++)
    {
        int num2 = _linqitems[i]; 
        if (num2 > q)
            num += num2 + 3;
    }
    return num;
}

V>Т.е., речь о том, что неуникальный случай в C# описать не так-то просто (тем паче с должной эффективностью).


S>>Нет язык позволяет использовать
S>>
S>>public static IEnumerable<TSource> Where<TSource>(
S>>    this IEnumerable<TSource> source,
S>>    Func<TSource, bool> predicate
S>>)
S>>

S>>То есть я могу использовать любой дженерик делегат .

V>Не можешь. В теле дотнетной лямбды происходит автовывод типов, поэтому ты вызываешь методы конкретных типов. А для реализации предиката в виде генерика исходные типы должны поддерживать некие данные ЗАРАНЕЕ ограничения на шаблонах или использовать т.н. "объекты-словари операций", навроде IComparer<T>, который в свою очередь может оперировать лишь типами, над которыми ПРЕДВАРИТЕЛЬНО заданы некие ограничения в виде опять и снова интерфейсов.


И что мне мешает объявить метод?

 bool MyMetod<T>(T x)

S>>Просто лямбды удобнее как для написания так и для чтения, а так же для оптимизации компиляции

V>Конечно удобны. Но я на это тоже уже отвечал заранее:
V>

V>Понятно, что x => x.Y выглядит тривиально, это был лишь пример. В общем случае "оно" может быть не тривиальным, т.к. именно под нетривиальные объемы кода пишут те самые шаблоны "многоразового применения" — в этом их фишка.

 V>С++ позволяет комбинировать технику шаблонов и лямбд, используя каждую из техник по прямому назначению, т.е. заставляя их выполнять исключительно "свою" часть работы.


Это же все можно делать и на C#
и солнце б утром не вставало, когда бы не было меня
Re[41]: benchmark
От: itslave СССР  
Дата: 12.01.17 12:39
Оценка: 1 (1) -2 :))
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Встречается часто, и вносят значительный вклад, но для типичных корпоративных "операционных дней" и "всё в базу упирается" это действительно не критично.
Да если бы оперднями все ограничивалось
Зайди на любой веб сайт — там тоже "все в базу и хттп упирается". Вон, даже на мобильных девайсах жава и замарин отлично себя чувствуют, андроид так тот весь на жаве написан. А если посчитать сколько человекочасов сохраняют управляемые языки, так уж действительно оказывается что С++ нужен в очень ограниченных случаяъ. А если нужен то проще сделать длл-ку дял критического куска и прикрутить ее к управляемому решению, чем городить целый огород на этом убожестве.
Re[41]: benchmark
От: lpd Черногория  
Дата: 12.01.17 18:15
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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

lpd>>Соглашусь, что ее нужно учитывать — в тех случаях, когда доступ последовательный и когда задержки обращения к памяти вносят значительный вклад в общее время. Однако, если говорить о типичных клиент-серверных приложениях на C#/Java, то там подобное встречается не столь часто

EP>Встречается часто, и вносят значительный вклад, но для типичных корпоративных "операционных дней" и "всё в базу упирается" это действительно не критично.

Все-таки думаю, что ты несколько переусложняешь. Я тут перевел на java функцию, вычисляющию DCT(Исходный код java и C++ в конце поста). В данном случае я не старался получить правильный алгоритм — это лишь является тестом вычислений.

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
c++ -O3 -std=c++14 -o dct dct.cpp (clang++ почему-то дал плохой результат)
C++:
1083590667ns
68
Java:
java -version
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)

javac dct.java
java dct
2870287311ns
68


И без всякой индирекции на одних float'ах, int'ах и массивах получил разницу в 3 раза. Могу поверить, что косвенность вносит свой вклад, но решающий не он.

Java:

public class dct {

static float b[],b1[],d[][];
static int _dct (int block[], int coeff[])
{
    int j1, i, j, k;
//    float b[8];
//    float b1[8];
//    float d[8][8];
    float f0 = (float) .7071068;
    float f1 = (float) .4903926;
    float f2 = (float) .4619398;
    float f3 = (float) .4157348;
    float f4 = (float) .3535534;
    float f5 = (float) .2777851;
    float f6 = (float) .1913417;
    float f7 = (float) .0975452;

    for (i = 0, k = 0; i < 8; i++, k += 8)
    {
        for (j = 0; j < 8; j++)
        {
            b[j] = (float) block[k + j];
        }
        /* Horizontal transform */
        for (j = 0; j < 4; j++)
        {
            j1 = 7 - j;
            b1[j] = b[j] + b[j1];
            b1[j1] = b[j] - b[j1];
        }
        b[0] = b1[0] + b1[3];
        b[1] = b1[1] + b1[2];
        b[2] = b1[1] - b1[2];
        b[3] = b1[0] - b1[3];
        b[4] = b1[4];
        b[5] = (b1[6] - b1[5]) * f0;
        b[6] = (b1[6] + b1[5]) * f0;
        b[7] = b1[7];
        d[i][0] = (b[0] + b[1]) * f4;
        d[i][4] = (b[0] - b[1]) * f4;
        d[i][2] = b[2] * f6 + b[3] * f2;
        d[i][6] = b[3] * f6 - b[2] * f2;
        b1[4] = b[4] + b[5];
        b1[7] = b[7] + b[6];
        b1[5] = b[4] - b[5];
        b1[6] = b[7] - b[6];
        d[i][1] = b1[4] * f7 + b1[7] * f1;
        d[i][5] = b1[5] * f3 + b1[6] * f5;
        d[i][7] = b1[7] * f7 - b1[4] * f1;
        d[i][3] = b1[6] * f3 - b1[5] * f5;
    }
    /* Vertical transform */
    for (i = 0; i < 8; i++)
    {
        for (j = 0; j < 4; j++)
        {
            j1 = 7 - j;
            b1[j] = d[j][i] + d[j1][i];
            b1[j1] = d[j][i] - d[j1][i];
        }
        b[0] = b1[0] + b1[3];
        b[1] = b1[1] + b1[2];
        b[2] = b1[1] - b1[2];
        b[3] = b1[0] - b1[3];
        b[4] = b1[4];
        b[5] = (b1[6] - b1[5]) * f0;
        b[6] = (b1[6] + b1[5]) * f0;
        b[7] = b1[7];
        d[0][i] = (b[0] + b[1]) * f4;
        d[4][i] = (b[0] - b[1]) * f4;
        d[2][i] = b[2] * f6 + b[3] * f2;
        d[6][i] = b[3] * f6 - b[2] * f2;
        b1[4] = b[4] + b[5];
        b1[7] = b[7] + b[6];
        b1[5] = b[4] - b[5];
        b1[6] = b[7] - b[6];
        d[1][i] = b1[4] * f7 + b1[7] * f1;
        d[5][i] = b1[5] * f3 + b1[6] * f5;
        d[7][i] = b1[7] * f7 - b1[4] * f1;
        d[3][i] = b1[6] * f3 - b1[5] * f5;
    }
    for (i = 0; i < 8; i++)
    {
        for (j = 0; j < 8; j++)
        {
            coeff[j + i * 8] = (int) (d[i][j]);
        }
    }
    return 0;
}

public static void main(String args[])
{
    b=new float[8];b1=new float[8];d=new float[8][8];
    int data[] = new int[64];
    for (int i=0; i<64; i++)
        data[i]=i;
    int coef[] = new int[64];
    long start1 = System.nanoTime();
    for (int i=0; i<10*1000*1000; i++)
        _dct(data,coef);
    long finish1 = System.nanoTime();
    System.out.println(finish1-start1);
    int r=0;
    for (int i=0; i<64; i++)
        r+= coef[i];
    System.out.println(r);
}
}

C++:
#include <stdlib.h>
#include <math.h>
#include <string.h>

int _dct (int *block, int *coeff);

#define mnint(a)    ((a) < 0 ? (int)(a - 0.5) : (int)(a + 0.5))

int _dct (int *block, int *coeff)
{
    int j1, i, j, k;
    float b[8];
    float b1[8];
    float d[8][8];
    float f0 = (float) .7071068;
    float f1 = (float) .4903926;
    float f2 = (float) .4619398;
    float f3 = (float) .4157348;
    float f4 = (float) .3535534;
    float f5 = (float) .2777851;
    float f6 = (float) .1913417;
    float f7 = (float) .0975452;

    for (i = 0, k = 0; i < 8; i++, k += 8)
    {
        for (j = 0; j < 8; j++)
        {
            b[j] = (float) block[k + j];
        }
        /* Horizontal transform */
        for (j = 0; j < 4; j++)
        {
            j1 = 7 - j;
            b1[j] = b[j] + b[j1];
            b1[j1] = b[j] - b[j1];
        }
        b[0] = b1[0] + b1[3];
        b[1] = b1[1] + b1[2];
        b[2] = b1[1] - b1[2];
        b[3] = b1[0] - b1[3];
        b[4] = b1[4];
        b[5] = (b1[6] - b1[5]) * f0;
        b[6] = (b1[6] + b1[5]) * f0;
        b[7] = b1[7];
        d[i][0] = (b[0] + b[1]) * f4;
        d[i][4] = (b[0] - b[1]) * f4;
        d[i][2] = b[2] * f6 + b[3] * f2;
        d[i][6] = b[3] * f6 - b[2] * f2;
        b1[4] = b[4] + b[5];
        b1[7] = b[7] + b[6];
        b1[5] = b[4] - b[5];
        b1[6] = b[7] - b[6];
        d[i][1] = b1[4] * f7 + b1[7] * f1;
        d[i][5] = b1[5] * f3 + b1[6] * f5;
        d[i][7] = b1[7] * f7 - b1[4] * f1;
        d[i][3] = b1[6] * f3 - b1[5] * f5;
    }
    /* Vertical transform */
    for (i = 0; i < 8; i++)
    {
        for (j = 0; j < 4; j++)
        {
            j1 = 7 - j;
            b1[j] = d[j][i] + d[j1][i];
            b1[j1] = d[j][i] - d[j1][i];
        }
        b[0] = b1[0] + b1[3];
        b[1] = b1[1] + b1[2];
        b[2] = b1[1] - b1[2];
        b[3] = b1[0] - b1[3];
        b[4] = b1[4];
        b[5] = (b1[6] - b1[5]) * f0;
        b[6] = (b1[6] + b1[5]) * f0;
        b[7] = b1[7];
        d[0][i] = (b[0] + b[1]) * f4;
        d[4][i] = (b[0] - b[1]) * f4;
        d[2][i] = b[2] * f6 + b[3] * f2;
        d[6][i] = b[3] * f6 - b[2] * f2;
        b1[4] = b[4] + b[5];
        b1[7] = b[7] + b[6];
        b1[5] = b[4] - b[5];
        b1[6] = b[7] - b[6];
        d[1][i] = b1[4] * f7 + b1[7] * f1;
        d[5][i] = b1[5] * f3 + b1[6] * f5;
        d[7][i] = b1[7] * f7 - b1[4] * f1;
        d[3][i] = b1[6] * f3 - b1[5] * f5;
    }
    for (i = 0; i < 8; i++)
    {
        for (j = 0; j < 8; j++)
        {
            *(coeff + j + i * 8) = (int) (d[i][j]);
        }
    }
    return 0;
}


#include <chrono>
#include <iostream>
using namespace std;
int main()
{
    srand(time(0));
    int data[64];
    int coef[64];
    for (int i=0; i<64; i++)
        data[i] = i;
    auto start1 = std::chrono::high_resolution_clock::now();
    for (int i=0; i<10*1000*1000; i++)
        _dct(data,coef);
    auto finish1 = std::chrono::high_resolution_clock::now();
    cout << std::chrono::duration_cast<std::chrono::nanoseconds>(finish1-start1).count() << "ns\n";
    int r;
    for (int i=0;i<64;i++)
        r += coef[i];
    cout << r << endl;
}
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[28]: Visual C# vs C++. Надо сравнить перспективы.
От: AlexRK  
Дата: 12.01.17 18:44
Оценка:
Здравствуйте, itslave, Вы писали:

I>Хосспади, вы про эту про эту долбаную производительности числодробилок заманали писать в каждом мосте. Не нужна эта производительность в реальной жизне чуть менее чем никогда. Понимаешь — оно не нужно, даже забесплатно.

Во-первых, это ложь.
Во-вторых, а нахрена тогда этот НЕТ Коре вообще нужен? Микрософт облажался и Коре на самом деле не нужно, даже забесплатно? Хм, согласен.
Re[29]: Visual C# vs C++. Надо сравнить перспективы.
От: itslave СССР  
Дата: 12.01.17 18:52
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Во-первых, это ложь.
что именно ложь? Потрудитесь высказывать свои мыли яснее (с)

ARK>Во-вторых, а нахрена тогда этот НЕТ Коре вообще нужен? Микрософт облажался и Коре на самом деле не нужно, даже забесплатно? Хм, согласен.
Проблема кора в том, что он сырой. И ее достаточно оперативно решают. Время покажет, нужен ли он, сейчас об этом говорить мягко говоря преждевременно.
Re[30]: Visual C# vs C++. Надо сравнить перспективы.
От: AlexRK  
Дата: 12.01.17 18:54
Оценка: :)
Здравствуйте, itslave, Вы писали:

ARK>>Во-первых, это ложь.
I>что именно ложь? Потрудитесь высказывать свои мыли яснее (с)

Есть классы приложений, в которых производительность важна. И они отнюдь не маргинальны.

ARK>>Во-вторых, а нахрена тогда этот НЕТ Коре вообще нужен? Микрософт облажался и Коре на самом деле не нужно, даже забесплатно? Хм, согласен.
I>Проблема кора в том, что он сырой. И ее достаточно оперативно решают. Время покажет, нужен ли он, сейчас об этом говорить мягко говоря преждевременно.

Я к тому, что если производительность не нужна, то отсюда сразу вытекает, что и кор не нужен, т.к. кроме производительности смысла в нем никакого нет.
Re[31]: Visual C# vs C++. Надо сравнить перспективы.
От: itslave СССР  
Дата: 12.01.17 19:04
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Есть классы приложений, в которых производительность важна. И они отнюдь не маргинальны.
имя, сестра(тьху, брат), имя...

ARK>Я к тому, что если производительность не нужна, то отсюда сразу вытекает, что и кор не нужен, т.к. кроме производительности смысла в нем никакого нет.
тройной, не пятерной фейспалм. Хинт: кроссплатформенность, есть такое слово...
Re[32]: Visual C# vs C++. Надо сравнить перспективы.
От: AlexRK  
Дата: 12.01.17 19:10
Оценка:
Здравствуйте, itslave, Вы писали:

ARK>>Есть классы приложений, в которых производительность важна. И они отнюдь не маргинальны.
I>имя, сестра(тьху, брат), имя...

Игры, например.

ARK>>Я к тому, что если производительность не нужна, то отсюда сразу вытекает, что и кор не нужен, т.к. кроме производительности смысла в нем никакого нет.
I>тройной, не пятерной фейспалм. Хинт: кроссплатформенность, есть такое слово...

Нда уж. И правда фейспалм. А жаба у нас давно нативная? Чисто для справки осмелюсь сообщить, что кроссплатформенность и нативность — совершенно ортогональные понятия. Хуже того, есть подозрение, что наличие виртуальной машины куда больше способствует кроссплатформенности, нежели ее отсутствие.
Re[33]: Visual C# vs C++. Надо сравнить перспективы.
От: itslave СССР  
Дата: 12.01.17 19:50
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Игры, например.
Согласен, С# не годится для того чтобы просчитывать специализированные алгоритмы на специализированном проце видеокарты. Но там и плюсов почти нет


ARK>Нда уж. И правда фейспалм. А жаба у нас давно нативная?
Она кроссплатформенная. А .NET до core таким не был. Твой КО.

ARK>Чисто для справки осмелюсь сообщить, что кроссплатформенность и нативность — совершенно ортогональные понятия.
О, я то и не знал, то вот тот же самый КО подсказывает что все пофик на нативность

ARK>Хуже того, есть подозрение, что наличие виртуальной машины куда больше способствует кроссплатформенности, нежели ее отсутствие.
Та ты шо? Прикинь, вот даже в тупом мелкософте до этого доперли и.... сделали .net core
Отредактировано 12.01.2017 19:52 itslave . Предыдущая версия .
Re[33]: Visual C# vs C++. Надо сравнить перспективы.
От: Klikujiskaaan КНДР  
Дата: 12.01.17 19:51
Оценка: 1 (1) +1 -1 :)
Здравствуйте, AlexRK, Вы писали:

ARK>Игры, например.

Ну так-то Unity есть, весьма успешный...
Re[34]: Visual C# vs C++. Надо сравнить перспективы.
От: AlexRK  
Дата: 12.01.17 20:03
Оценка:
Здравствуйте, itslave, Вы писали:

ARK>>Игры, например.
I>Согласен, С# не годится для того чтобы просчитывать специализированные алгоритмы на специализированном проце видеокарты. Но там и плюсов почти нет

Но игры на C# даже сейчас таки пишутся, а значит и производительность востребована.

ARK>>Нда уж. И правда фейспалм. А жаба у нас давно нативная?
ARK>>Хуже того, есть подозрение, что наличие виртуальной машины куда больше способствует кроссплатформенности, нежели ее отсутствие.
I>Она кроссплатформенная. А .NET до core таким не был. Твой КО.
I>Та ты шо? Прикинь, вот даже в тупом мелкософте до 4того доперли и.... сделали .net core

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

Так шта, возвращаясь к началу беседы... Ежели

Не нужна эта производительность в реальной жизне чуть менее чем никогда. Понимаешь — оно не нужно, даже забесплатно.

то и Core нафиг не нужен тогда.

ARK>>Чисто для справки осмелюсь сообщить, что кроссплатформенность и нативность — совершенно ортогональные понятия.
I>О ято и не знал, то вот тот же самый КО подскащывает что все пофик на нативность

Че-то я эту фразу не распарсил.
Re[34]: Visual C# vs C++. Надо сравнить перспективы.
От: AlexRK  
Дата: 12.01.17 20:03
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

ARK>>Игры, например.
K>Ну так-то Unity есть, весьма успешный...

Там C# вроде бы только один из языков, хотя на 100% не уверен. Ну и, выходит, нужна таки производительность-то, раз игры пишут.
Re[22]: Visual C# vs C++. Надо сравнить перспективы.
От: Jack128  
Дата: 12.01.17 20:27
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>Он плохо оптимизирует в том числе потому что управляемый код труднее оптимизировать. Например замыкания на C++ порождают обычные вызовы, а на C# косвенные.
Тут дело не в управляемом коде, а в противопоставлении "шаблоны vs раздельная компиляция". в плюсах, если хоцца отдельно скопилировать ФВП от кода её использущего — тут же скатываешся к std::function и той же самой косвенности вызовов.
Re[6]: Visual C# vs C++. Надо сравнить перспективы.
От: novitk США  
Дата: 12.01.17 20:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Распространенное заблуждение. Дотнет не совсем то же самое, что джава, хотя и похож. Он, в отличие от нее, работает в среде ОС со своим рантаймом — CLR. Т.е., к примеру, без каких либо спецмостов управление может перейди из дотнетного кода в нативный и вернутся обратно в дотнетный, главное маршаллинг данных обеспечить.
Не понятно о каких отсутствующих спецмостах идет речь, если 99% "моста" это именно маршаллинг и есть. Я как-то делал эксперимент с наиболее популярным "мостом" — SWIG. JNI был ~30% быстрее. Не уверен в причинах, может явовский байндинг там лучше, может jit, может и то и другое.

AVK>Исключения тоже спокойно могут пролетать через такой смешанный стек,
Почитал здесь.Я правильно понимаю, что в .NET возможно лишь словить сам факт исключения? Понять что именно произошло в нативе возможности нет?
Re[35]: Visual C# vs C++. Надо сравнить перспективы.
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.01.17 21:09
Оценка:
Здравствуйте, AlexRK, Вы писали:


ARK>По-моему, городить огород с полностью новой технологией ради кроссплатформенности — как-то тупо. Особенно если принять во внимание, что уже давно есть моно (который даже в коммерческих проектах используется). Допилить его до полностью юзабельного состояния было бы гораздо проще.
MS сейчас зарабатывают на Azure. А там как раз кроссплатформенность и нужна.
Кроме того .Net Core другая архитектура в том числе под Net Native.
То есть не только кроссплатформенность, но и скорость.
Из моно кстати много взято.
и солнце б утром не вставало, когда бы не было меня
Re[35]: Visual C# vs C++. Надо сравнить перспективы.
От: itslave СССР  
Дата: 12.01.17 21:17
Оценка:
Здравствуйте, AlexRK, Вы писали:

I>>Согласен, С# не годится для того чтобы просчитывать специализированные алгоритмы на специализированном проце видеокарты. Но там и плюсов почти нет

ARK>Но игры на C# даже сейчас таки пишутся, а значит и производительность востребована.

Еще раз перечитай то что я написал. Потом подумай. Повтори пока не дойдет.


ARK>По-моему, городить огород с полностью новой технологией ради кроссплатформенности — как-то тупо.

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

ARK>Особенно если принять во внимание, что уже давно есть моно (который даже в коммерческих проектах используется). Допилить его до полностью юзабельного состояния было бы гораздо проще.
Ну ты хоть немного выучи матчасть, хотя бы базовые вещи, прежде чем рассуждать о танце маленьких лебедей.
ARK>Собственно, это и очевидно, что кор делается в первую очередь ради производительности, а все остальное — сбоку припеку.
Главное что кроме тебя это никому не очевидно
ARK>Так шта, возвращаясь к началу беседы...
Иди читай мануалы, а потом возвращайся.
Re[35]: Visual C# vs C++. Надо сравнить перспективы.
От: itslave СССР  
Дата: 12.01.17 21:19
Оценка: +1 :)
Здравствуйте, AlexRK, Вы писали:
K>>Ну так-то Unity есть, весьма успешный...

ARK>Там C# вроде бы только один из языков, хотя на 100% не уверен. Ну и, выходит, нужна таки производительность-то, раз игры пишут.
Выходит то что производительность то удовлетворяет, раз игры пишут...
Признайся, тебе 20 лет уже исполнилось?
Re[36]: Visual C# vs C++. Надо сравнить перспективы.
От: AlexRK  
Дата: 12.01.17 21:30
Оценка:
Здравствуйте, itslave, Вы писали:

I>>>Согласен, С# не годится для того чтобы просчитывать специализированные алгоритмы на специализированном проце видеокарты. Но там и плюсов почти нет
ARK>>Но игры на C# даже сейчас таки пишутся, а значит и производительность востребована.
I>Еще раз перечитай то что я написал. Потом подумай. Повтори пока не дойдет.

Даже для C# нужна скорость, например для того, чтобы писать игры. Больше скорость — больше возможностей. Это как, доступно для понимания, или не совсем?

ARK>>По-моему, городить огород с полностью новой технологией ради кроссплатформенности — как-то тупо.
I>Та ты просто кэп, даже не, майор, даже не, генерал очевидность. НО вот только у меня для тебя есть небольшое разочарование: никто абсолютно новый огород и не городит: просто портирует то что есть, ничо более.

А новый компилятор — это не новое? Забавно.

ARK>>Особенно если принять во внимание, что уже давно есть моно (который даже в коммерческих проектах используется). Допилить его до полностью юзабельного состояния было бы гораздо проще.
I>Ну ты хоть немного выучи матчасть, хотя бы базовые вещи, прежде чем рассуждать о танце маленьких лебедей.

Хм, ну и что я там должен увидеть?
Вот это?

The main point is to enable "native compilation" (so you don't need .NET framework/VM installed on the target machine.

Ну, это довольно очевидно...

To conclude:
.NET Core at present is not really portable, nor is is really cross-platform (in particular the debug-tools).



ARK>>Так шта, возвращаясь к началу беседы...
I>Иди читай мануалы, а потом возвращайся.

Подредактирую изначальное сообщение и скажу более мягко. Не указывайте людям, что делать, и они не укажут вам направление движения.
Отредактировано 12.01.2017 21:46 AlexRK . Предыдущая версия . Еще …
Отредактировано 12.01.2017 21:42 AlexRK . Предыдущая версия .
Re[36]: Visual C# vs C++. Надо сравнить перспективы.
От: AlexRK  
Дата: 12.01.17 21:35
Оценка: +1
Здравствуйте, itslave, Вы писали:

ARK>>Там C# вроде бы только один из языков, хотя на 100% не уверен. Ну и, выходит, нужна таки производительность-то, раз игры пишут.
I>Выходит то что производительность то удовлетворяет, раз игры пишут...

Мда. А доцент-то тупой (с)

Пишут настолько, насколько язык позволяет. Будет позволять больше — будут писать и такие вещи, которые раньше писались на других языках.

I>Признайся, тебе 20 лет уже исполнилось?

Что, хорошо на корме рвануло, да?
Re[37]: Visual C# vs C++. Надо сравнить перспективы.
От: itslave СССР  
Дата: 12.01.17 22:07
Оценка: -1 :)
Здравствуйте, AlexRK, Вы писали:

ARK>Даже для C# нужна скорость, например для того, чтобы писать игры. Больше скорость — больше возможностей. Это как, доступно для понимания, или не совсем?
Как уже мы выяснили в соседнем треде, скорей всего ты молод, а поэтому воинствующая глупость скорей всего может быть обьяснена недостатком опыта, образования, гормонами.. в общем как и у всех в молодости
Ну дык от, с учетом всего вышесказанного, разжую, как мне разжевывали.
Максимальный перфоманс может быть достигнут только в новых схемотехнических решениях. И за доказательствами ходить далеко не нужно, интегрированные процы на геймерских видеокартах на специфических задачах рвут i7 как тузик грелку. И любой дальнейший отход от схемотенических решений, как то: программирование в двоичных кодах, ассембелер, с, с++, управляемых языках — это сознательная жертва производительности в угоду другим критериям. Таким как: универсальность, скорость разработки, цена мейтененса, тестируемость и так далее. И на каждом этапе возникал вопрос о балансе: а не много ли мы перфоманса пожертвовали для того чтобы миллион тупых славян индусов смогли выдавать предсказуемый результат? И в случае с C# ответ очевиден: среда разработки, изначально таргетированная на рынок бизнес приложений внезапно стала востребованной и на рынке игр. Потому что перфоманса достаточно!

ARK>А новый компилятор — это не новое? Забавно.
Выход новой версии gcc — это канечна да, новый этап, знаменующий собой тотальный прогресс в С++7 пойду пацанам расскажу, посмеемся вместе

ARK>Хм, ну и что я там должен увидеть?
ARK>Вот это?
ARK>

The main point is to enable "native compilation" (so you don't need .NET framework/VM installed on the target machine.

 ARK>Ну, это довольно очевидно...
Перечитай пока не дойдет.


ARK>Подредактирую изначальное сообщение и скажу более мягко. Не указывайте людям, что делать, и они не укажут вам направление движения.
о хосподи, как с вами пионерами смешно. Но впрочем, если ты не пионер, то ето уже грустно.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.