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

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

F>>>>>Да мне не нужен аналог, мне нужна платформа решающая типичные проблемы кластера
D>>Уточни, pls, о каких типичных проблемах кластера идёт речь?
F> Ну я же писал выше, — автоматизация установки / обновления узлов, сервисы, для которых важно, что бы они были одной версии — предотвращать одновременную работу разных версий, для другой части важно иметь гибкий "роутинг", т.е. приоритет может иметь локалхост, но не везде это актуально. Конфигурирование — вероятно, если несколько узлов будут работать с одной конфигурацией, а другие — с другой — тоже как бы не гуд. Короче ничего сверхъестественного не нужно, но инфрастуктура нужна.

пока не понятно 2 вещи — причем тут нет? и чем плох грид?
из за нета потери быстродействия в математике в 1,5-3 раза по сравнению с с++(сам делал тесты), так что возможно проще не заморачиваться, а писать на С++?

Здравствуйте, Аноним, Вы писали:

А>пока не понятно 2 вещи — причем тут нет? и чем плох грид?
Нет при том, что всё сервисы на нете.
Теперь я не понял, — что значит чем плох грид?

А>из за нета потери быстродействия в математике в 1,5-3 раза по сравнению с с++(сам делал тесты), так что возможно проще не заморачиваться, а писать на С++?
Совершенно не проще, наоборот от C++ уходим, наконец-то безвозвратно.

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

А>>из за нета потери быстродействия в математике в 1,5-3 раза по сравнению с с++(сам делал тесты), так что возможно проще не заморачиваться, а писать на С++?
F> Совершенно не проще, наоборот от C++ уходим, наконец-то безвозвратно.
А что за задача?

Здравствуйте, Аноним, Вы писали:

F>> Совершенно не проще, наоборот от C++ уходим, наконец-то безвозвратно.
А>А что за задача?
Инфраструктура + бизнес логика + шлюзы к инородным системам. Ничего такого, где C++ был бы необходим.

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

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

Здравствуйте, <Аноним>, Вы писали:

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

А>На взброс думаю не потянет, но все же
А>Один из недостатков это связь с System Reflection Emit и в следствии чего нет нормальной работы в Mono.
hardcase выделяет работу с Reflection.Emit в отдельный класс/сборку — будет возможность делать сменные backends

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

F>Здравствуйте, Аноним, Вы писали:

F>>> Совершенно не проще, наоборот от C++ уходим, наконец-то безвозвратно.
А>>А что за задача?
F> Инфраструктура + бизнес логика + шлюзы к инородным системам. Ничего такого, где C++ был бы необходим.
Тут согласен. В математике нет проваливается очень сильно, а в остальном провал в 1,5 раза не о чем учитывая ложность написания на С++, функционал существенно важнее скорости.

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

D>Здравствуйте, <Аноним>, Вы писали:

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

А>>На взброс думаю не потянет, но все же
А>>Один из недостатков это связь с System Reflection Emit и в следствии чего нет нормальной работы в Mono.
D>hardcase выделяет работу с Reflection.Emit в отдельный класс/сборку — будет возможность делать сменные backends

Там не хватает поддержки extern alias , чтобы это дело завершить.

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

D>hardcase выделяет работу с Reflection.Emit в отдельный класс/сборку — будет возможность делать сменные backends
Н2? Смысла в сменных бакэндах по большому счету нет. Так как переносимость зависит в основном от библиотек. Только как вариант дать поиграться джавистам. Пусть завидуют.

Здравствуйте, <Аноним>, Вы писали:

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

D>>hardcase выделяет работу с Reflection.Emit в отдельный класс/сборку — будет возможность делать сменные backends
А>Н2?

Нет, в текущей версии nemerle — 1.x.
А>Смысла в сменных бакэндах по большому счету нет. Так как переносимость зависит в основном от библиотек. Только как вариант дать поиграться джавистам. Пусть завидуют.
Всё зависит от стандартной библиотеки...
Дальше можно сделать как в haxe — есть стандартная библиотека + возможность использовать возможности платформы
В теории можно даже в нэйтив компилировать... (Как в том же моно)...

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

VD>Я уверен, что недели знакомства с языком — это слишком мало чтобы серьезно разговаривать о его недостатках. Напиши что-то более менее реалистичное и тогда будет о чем поговорить.
Ясно.

Здравствуйте, <Аноним>, Вы писали:

А>Тут согласен. В математике нет проваливается очень сильно,

И это заблуждение.

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

DS>Здравствуйте, <Аноним>, Вы писали:

А>>Тут согласен. В математике нет проваливается очень сильно,

DS>И это заблуждение.

Это тесты мои. Текст переносился с С++ на шарп. исходник был примерно 10К. никаких классов и внешних библиотек. Провал в скорости был более 3 раз. время работы для С++ минут 10, так что запуск и т не играл роли. Программа работала в консоли и выдавали время начала, время окончания и результат.

Здравствуйте, Аноним, Вы писали:

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

DS>>Здравствуйте, <Аноним>, Вы писали:

А>>>Тут согласен. В математике нет проваливается очень сильно,

DS>>И это заблуждение.

А>Это тесты мои. Текст переносился с С++ на шарп. исходник был примерно 10К. никаких классов и внешних библиотек. Провал в скорости был более 3 раз. время работы для С++ минут 10, так что запуск и т не играл роли. Программа работала в консоли и выдавали время начала, время окончания и результат.

Угу — и где нибудь struct байт так на 200 через стек передевали наверное в цикле ? Неудивительно.
В моих задачах шарп сливает не больше 25%.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

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

DS>>>Здравствуйте, <Аноним>, Вы писали:

А>>>>Тут согласен. В математике нет проваливается очень сильно,

DS>>>И это заблуждение.

А>>Это тесты мои. Текст переносился с С++ на шарп. исходник был примерно 10К. никаких классов и внешних библиотек. Провал в скорости был более 3 раз. время работы для С++ минут 10, так что запуск и т не играл роли. Программа работала в консоли и выдавали время начала, время окончания и результат.

А>Угу — и где нибудь struct байт так на 200 через стек передевали наверное в цикле ? Неудивительно.
А>В моих задачах шарп сливает не больше 25%.

никаких структ, классов, стандартных библиотек и т д

только переменные, массивы, циклы, условия, передавал в функции только переменные, никаких структур.
больше математику и нет не скрещиваю

Здравствуйте, Аноним, Вы писали:

А>Это тесты мои. Текст переносился с С++ на шарп. исходник был примерно 10К. никаких классов и внешних библиотек. Провал в скорости был более 3 раз. время работы для С++ минут 10, так что запуск и т не играл роли. Программа работала в консоли и выдавали время начала, время окончания и результат.

Отстают массивы. Скорее всего тестах были матричные вычисления или что-то вроде того. Кроме того много зависит от версии фрэймворка, типа процессора, версии и типа компилятора С++ и т.п.

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

VD>Отстают массивы. Скорее всего тестах были матричные вычисления или что-то вроде того. Кроме того много зависит от версии фрэймворка, типа процессора, версии и типа компилятора С++ и т.п.

GCC 4.7
NET 4
почти матричные, дифуры.
core 5i sse3

Здравствуйте, Аноним, Вы писали:

А>GCC 4.7
А>NET 4
А>почти матричные, дифуры.
А>core 5i sse3

С матрицами в дотнете все плохо. Если GCC умеем применить sse, то разрыв будет еще больше. А так, арифметика примерно в то же время вычисляется.

Ну, а матрицы зачастую эффективнее на видеокартах вычислять. И тут у немерла есть ряд очень интересных решений.

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

VD>Отстают массивы. Скорее всего тестах были матричные вычисления или что-то вроде того. Кроме того много зависит от версии фрэймворка, типа процессора, версии и типа компилятора С++ и т.п.

Я недавно один микробенчмарк затеивал, так народ обнаружил, что от версии .net'а действительно зависит: чем выше версия, тем медленнее.
http://thedeemon.livejournal.com/49226.html?thread=581962#t581962
И разница между x64 и x86 в .net очень заметная получилась.

А на sse в gcc особо рассчитывать не приходится, он только очень примитивные циклы умеет векторизовать.

Здравствуйте, D. Mon, Вы писали:

К сожалению, могу лишь только подтвердить. При том, не смотря, на то что в блогах хвастались что x64 jit умеет такое, что не умеет x86 — x86 jit стабильно выигрывает на любой платформе (в смысле windows x86/x64). У них разная кодовая база для JIT — её обещают не первый год объеденить. Вот уже .NET 4.5 идёт — но судя по всему, они до сих пор разные.
Но — всё же зависит от задачи. Мне чего-то кажется, что от векторизации циклов толку в прикладном коде... ммм... ну не про математику — около нуля (или я ошибаюсь?). А вот я наблюдал картинку, когда код при наличии клиентского бэкграунд GC (в .NET4) начинает раза в 3-4 быстрее шуршать (на core 2 duo), против явного высвобождения памяти. Понятно, что с GC памяти тратится больше, но не катастрофически (мег на 20).