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

H>>Это не предположение, это этакая параллель... .NET core библиотеки-то насквозь C++'сные.

VD>Да, ну? А почему 99% из них декомпилируется Рефлектором?

mscoree.dll — Microsoft .NET Runtime Execution Engine
mscorwks.dll — Microsoft .NET Runtime Common Language Runtime — WorkStation
normalization.dll — Microsoft Unicode Normalization

Вполне себе нативные, корковые библиотеки...

S>>>Что мешает компилятору на Руби выдавать под LLVM, или сразу в машинные инструкции?

H>>Ничего не мешает.

VD>Ну, так ты понял, что спорол чушь?

Вовсе не чушь, если учесть означенное "если".

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

H>>Не сомневайся. Но вот о чем следует подумать, так это о том, что исполняющийся код будет работать не в вакууме.

VD>Думаю понятие вакуума к коду вообще не применимо. Код будет исполняться процессором.

Да. А еще он будет исполняться в окружении нативных модулей и с их участием.

VD>В остальном есть такие вещи как бутсрапинг. Слышал про такое?

Ага. Используется?

H>>Или вы тут копья ломаете по поводу перформанса кода вида "x + y"?

VD>Да, в общем-то любой код состоит из ряда примитивных операций.

Так вы тут эти примитивные операции чтоль обсуждаете?

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

AB>Думаю, что их как раз есть. Они-то и плюются на моно. А вот защищают его те, кто на нем даже hello word не сотворил, ИМХО. Вот этим защитникам я сначала и предлагаю попробовать написать на нем что-то вменяемое и, если не произойдет промывания желудка, защищать его, так сказать, уже во всеоружии. Моя уверенность строится на том, что после C# я пытался подходить к этому снаряду под линуксом уже раз не помню сколько — с каждым разом Qt мне нравится все больше и больше по сравнению с ним.

Ну я учавствовал в паре довольно крупных проектов на моно, дальше что?

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

T> Ну я учавствовал в паре довольно крупных проектов на моно, дальше что?

А дальше барабанная дробь, вероятно, и фанфары

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

VD>>> Что ты хочешь увидеть?
AB>>Мастер-класс, я же написал
VD>Это типа попрограммировать на публике чтобы все рты по открывали?

Да нет, Влад. От тебя мне будет достаточно, чтобы RSDN заработал на Nemerle под рантаймом Mono. Стабильно, без сбоев, быстро. Это будет высший мастер-класс.

VD>Да, давно пора. Слив, с твоей стороны, уже произошел. Что еще обсуждать?

* А пока что я вижу фаната-Влада, который носится с Nemerle как с писаной торбой;
* Я вижу сайт RSDN, который в течении полутора (или уже больше?) месяцев периодически или ложится или выдает HTTP-500 или тормозит безбожно;
* Я вижу насквозь сишный юниксойдный nginx, который поставили для латания брешей, с которыми не справляется IIS и начинка, и который бог знает сколько пытались настроить (хоть спасибо за сжатие — всего каких-то 740 килобайт сишного кода решили проблему, которую так долго не могли решить на IIS и Co);
* Я вижу лежащий уже с несколько недель поиск, который мало того, что лежит, так еще находится на стороннем ресурсе;
* Я вижу AndrewVK, который отдувается за всю команду и боится трогать код сайта от греха подальше (и в чем-то я его понимаю);
* Я вижу в форумах сообщения о том, что "безопасный" код сайта боятся открывать потому что в нем много дыр;
* Я вижу неработающие ссылки, которые отваливаются по таймауту и некому и нечему (и нечем, судя по всему) просматривать логи;
* Я не вижу Янус... впрочем, это уже другая история.

З.Ы. Да, я знаю, что это удар ниже пояса, но хотелось ответить по теме и без эмоций.

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

C>Не тратьте время. Они все-равно будут верить только в то, во что хотят верить. Переубедить их сможет только жизнь.

Или смерть.

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

ГВ>Группа маленьких модулей логически объединена в общий модуль, с которым программа работает через некоторый интерфейс. Этот сборный модуль тестируется отдельным набором тестов... Как называется это тестирование?

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

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

G>Проснись, оптимизация дотупа к массивам давно сущесвует.

То, что ты привел, работает только для i<array.Length, а это для тех же числомолотилок, которые переливают из предвыделенных буферов в буфера нереальный сценарий. Я уже как-то писал на эту тему, но могу еще раз.

uint[] data = _data;
for(int i=0, e=_buffLen; i<e; i++)
{
  SomeProccess(data[i]);
}

_data и _buffLen — члены класса, data и buffLen — локальные переменные, на них нет ссылок по ref, а из алгоритма видно, что значения неизменяемые в теле цикла, поэтому проверить можно buffLen лишь однажды при инициализации цикла, а затем уже не проверять границы. Однако, эту оптимизацию не делают.

G>Если нужет произвольный быстрый доступ, то есть unsafe.

Если использовать пиннинг — то тормозно (чем больше одновременных пинов, тем дороже каждый следующий), если же самостоятельно выделять память через всякие Marshal.AllocXXX, то смысл в управляемой платформе вообще исчезает, да и проблемы с ClickOnce для unsafe сборок. Вывод сделаешь сам.


G>Что касает числомолотилок, то в самых тупых линейных случаях (как md5 например), при использовании uncheked, .NET будет проигрывать на проценты. Что в реальной программе погоды не сделает.

Это зависит от характера вычислений. Например, фильтрация — это крайне примитивные вычисления, там затраты на проверку на границу цикла сопоставимы с полезными вычислениями (сопоставимы потому, что джиттер даже не кеширует в регистре длинну массива, а каждый раз лезет за ней через коссвенную адресацию), и вместо непосредственного приращения указателя каждый раз вычисляет адрес элемента (что вполне понятно, у нас же GC). Итого, мы сможем сделать таких простых вычислений в 2-3 раза меньше.

G>Кроме того такие случаи элементарно оптимизируются заменой на Сшный код или распараллеливаются (в .NET далется очень легко).

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

G>ЗЫ. Я ещ не упоминул такие оптимизации, которые делает mono. См Mono.Simd

Спасибо, интересно. На С++ мы делаем разные сборки для без SSE, и отдельно для SSE1/2/3, которые будем подгружать динамически, в зависимости от возможностей проца. Если джиттер научится делать это сам, то кое-что можно будет пересмотреть. Однако, вот тот доступ к массивам — это затык №1 для нас, ибо обычные вычисления действительно неплохо выглядят после джиттера.

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

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

G>>Проснись, оптимизация дотупа к массивам давно сущесвует.

V>То, что ты привел, работает только для i<array.Length, а это для тех же числомолотилок, которые переливают из предвыделенных буферов в буфера нереальный сценарий. Я уже как-то писал на эту тему, но могу еще раз.
V>

V>uint[] data = _data;
V>for(int i=0, e=_buffLen; i<e; i++)
V>{
V>  SomeProccess(data[i]);
V>}
V>

V>_data и _buffLen — члены класса, data и buffLen — локальные переменные, на них нет ссылок по ref, а из алгоритма видно, что значения неизменяемые в теле цикла, поэтому проверить можно buffLen лишь однажды при инициализации цикла, а затем уже не проверять границы. Однако, эту оптимизацию не делают.
Это C++ники так пишут код на шарпе. Не надо так писать. Пишите нормально i<data.Length и будет счастье.

G>>Если нужет произвольный быстрый доступ, то есть unsafe.

V>Если использовать пиннинг — то тормозно (чем больше одновременных пинов, тем дороже каждый следующий), если же самостоятельно выделять память через всякие Marshal.AllocXXX, то смысл в управляемой платформе вообще исчезает, да и проблемы с ClickOnce для unsafe сборок. Вывод сделаешь сам.
А причем тут пиннинг, он имеет значние только когда выделяется память. Есть хоть один числомолотильный алгоритм, в котором удно выделять память в процессе прохода по массиву?
Такая операция в С++ взовет большие тормоза, чем проверки границ в .NET.


G>>Что касает числомолотилок, то в самых тупых линейных случаях (как md5 например), при использовании uncheked, .NET будет проигрывать на проценты. Что в реальной программе погоды не сделает.

V>Это зависит от характера вычислений. Например, фильтрация — это крайне примитивные вычисления, там затраты на проверку на границу цикла сопоставимы с полезными вычислениями (сопоставимы потому, что джиттер даже не кеширует в регистре длинну массива, а каждый раз лезет за ней через коссвенную адресацию), и вместо непосредственного приращения указателя каждый раз вычисляет адрес элемента (что вполне понятно, у нас же GC). Итого, мы сможем сделать таких простых вычислений в 2-3 раза меньше.
Фильтрация чего?
Еще раз нужен быстрый линейный проход по массиву — используйте unsafe.

G>>Кроме того такие случаи элементарно оптимизируются заменой на Сшный код или распараллеливаются (в .NET далется очень легко).
V>В моей задаче распараллеливание одного вычисления не нужно, у меня их и так конкуррентно тысячи идут, я борюсь за эффективность каждого из них.
Будешь бороться за каждого — производительности не будет. Компутер гораздо лучше умеет шедулить задания, чем ты сам.

G>>ЗЫ. Я ещ не упоминул такие оптимизации, которые делает mono. См Mono.Simd

V>Спасибо, интересно. На С++ мы делаем разные сборки для без SSE, и отдельно для SSE1/2/3, которые будем подгружать динамически, в зависимости от возможностей проца. Если джиттер научится делать это сам, то кое-что можно будет пересмотреть. Однако, вот тот доступ к массивам — это затык №1 для нас, ибо обычные вычисления действительно неплохо выглядят после джиттера.
Дык используйте unsafe и указатели.

NBN> VD>От уровня языка зависят и проектные решения
NBN> Чушь.

Действительно чушь — что использовать. Готовый gen_server из поставки языка или написать свой аналог за 3-4 дня (Erlang) или искать специалиста, который аналог этого будет полгода лабать на С++

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

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

Рассмотрю предложение на вакансию Тьюринг-тестера.

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


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

ГВ>Рассмотрю предложение на вакансию Тьюринг-тестера.

Детский сад, вторая группа.

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

ГВ>>Рассмотрю предложение на вакансию Тьюринг-тестера.
C>Детский сад, вторая группа.

Предложения без вилки з/п не принимаются!

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

Похоже, ты смылся, поэтому поставлю точку сам.

C>>>Пример классического ламеризма. Может стоило бы для начала что-то узнать о предмете обсуждения? Например, что версия CLR все еще 2.0.х, а не 3.0

Да, версия стандарта 2.0.x (т.к. формат метаданных не поменялся), а название стандарта ты озвучил. Тем не менее, сам рантайм и .Net-сборки от второго фреймворка обновлялись с выходом каждого последующего или их SP. Для интереса, вот список изменений только лишь для 2.0SP1 http://support.microsoft.com/kb/945757, остальное найти так же не трудно, если есть желание.

То, что ты совершенно не в курсе об постоянных обновлении рантайма и .Net сборок и о характере этих обновлений — это понятно, но поверь, абсолютно не смертельно. Что непонятно, так это твоя реакция: неужели настолько смертельным было то, что ты предположил? И что будешь делать сейчас? Посыпать голову пеплом?


C>Вы даже не знаете разницы между фреймворком и CLR. Продолжайте писать в таком же духе — это становится очень забавно.

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


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

Кто тут имеет слабое представление, понятно-то давно. Мне лишь непонятна эта тяга везде найти ламеров вокруг себя. Так все плохо?

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

V>Похоже, ты смылся, поэтому поставлю точку сам.

C>>>>Пример классического ламеризма. Может стоило бы для начала что-то узнать о предмете обсуждения? Например, что версия CLR все еще 2.0.х, а не 3.0

V>Да, версия стандарта 2.0.x (т.к. формат метаданных не поменялся), а название стандарта ты озвучил. Тем не менее, сам рантайм и .Net-сборки от второго фреймворка обновлялись с выходом каждого последующего или их SP. Для интереса, вот список изменений только лишь для 2.0SP1 http://support.microsoft.com/kb/945757, остальное найти так же не трудно, если есть желание.

Вам не надоело самого себя "опускать"? В который раз доказали, что Вы банально не понимаете разницы между фреймворком и CLR.

Ликбез: версия CLR не менялась со времен дотнет 2.0 — v2.0.50727.

Жду публичного признания своей неправоты, уважаемый.

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

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

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


G>Это C++ники так пишут код на шарпе. Не надо так писать. Пишите нормально i<data.Length и будет счастье.

А мне надо именно i<buffLen.
Поймешь сейчас, или еще одну итерацию прогоним?

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

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

G>А причем тут пиннинг, он имеет значние только когда выделяется память.

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

V>>Это зависит от характера вычислений. Например, фильтрация — это крайне примитивные вычисления, там затраты на проверку на границу цикла сопоставимы с полезными вычислениями (сопоставимы потому, что джиттер даже не кеширует в регистре длинну массива, а каждый раз лезет за ней через коссвенную адресацию), и вместо непосредственного приращения указателя каждый раз вычисляет адрес элемента (что вполне понятно, у нас же GC). Итого, мы сможем сделать таких простых вычислений в 2-3 раза меньше.
G>Фильтрация чего?

Ээээ... сигналов.

G>Еще раз нужен быстрый линейный проход по массиву — используйте unsafe.

Да понял, заклинило. Ты им пользовался "по-взрослому", или на форуме тут нахватался? Если последние, то ищи лучше мои посты о предмете и еще об интеропе за последние года 3, т.к. похоже больше меня тут с этим вряд ли кто возился.

V>>В моей задаче распараллеливание одного вычисления не нужно, у меня их и так конкуррентно тысячи идут, я борюсь за эффективность каждого из них.
G>Будешь бороться за каждого — производительности не будет. Компутер гораздо лучше умеет шедулить задания, чем ты сам.

И что сказать хотел? Что на наш двухядерник тысячи конкурентных вычислений мало, надо еще в несколько раз распарралелить и, соотвественно, еще уменьшить гранулярность блокировок? Ты хоть глубину это чуши понимаешь? Вот когда будет отношение кол-ва ядер к количеству конкурентных вычислений хотя бы 1/10, то тогда я шедуллеру с радостью всё и поручу, а пока что, только лишь пересмотрев сценарии и укрупнив гранулярность блокировок, повысил емкость системы раза в полтора (кол-во одновременно обслуживаемых абонентов).

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

V>Да, версия стандарта 2.0.x (т.к. формат метаданных не поменялся), а название стандарта ты озвучил. Тем не менее, сам рантайм и .Net-сборки от второго фреймворка обновлялись с выходом каждого последующего или их SP. Для интереса, вот список изменений только лишь для 2.0SP1 http://support.microsoft.com/kb/945757, остальное найти так же не трудно, если есть желание.
Ну т.е. в принципе, при наличии двух сервис-паков, Photoshop CS2 можно смело назвать Photoshop CS4???

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


AB> * А пока что я вижу фаната-Влада, который носится с Nemerle как с писаной торбой;
AB> * Я вижу сайт RSDN, который в течении полутора (или уже больше?) месяцев периодически или ложится или выдает HTTP-500 или тормозит безбожно;
AB> * Я вижу насквозь сишный юниксойдный nginx, который поставили для латания брешей, с которыми не справляется IIS и начинка, и который бог знает сколько пытались настроить (хоть спасибо за сжатие — всего каких-то 740 килобайт сишного кода решили проблему, которую так долго не могли решить на IIS и Co);
AB> * Я вижу лежащий уже с несколько недель поиск, который мало того, что лежит, так еще находится на стороннем ресурсе;
AB> * Я вижу AndrewVK, который отдувается за всю команду и боится трогать код сайта от греха подальше (и в чем-то я его понимаю);
AB> * Я вижу в форумах сообщения о том, что "безопасный" код сайта боятся открывать потому что в нем много дыр;
AB> * Я вижу неработающие ссылки, которые отваливаются по таймауту и некому и нечему (и нечем, судя по всему) просматривать логи;
AB> * Я не вижу Янус... впрочем, это уже другая история.

Перепишите на С++ и мы посмотрим как Вы запоете.

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

G>Кроме того уже не за горами запуск числомолотилок на GPU, там тоже высокоуровневые языки будут более уместны, так как позволят генерить код для GPU в рантайме.
Занимаюсь я щас как раз GPU числомолотильней для финансовых расчетов.
Там пока всё мрачно и сурово.
Язык вообще роли не играет — хоть на ассемблере пиши. Все равно везде упираешься в особенности и ограничения самого железа.