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

C>>И что? Мой код все равно будет на 20% быстрее работать.
WH>Не будет. Ибо на том процессоре не будет аппаратной защиты памяти. Следовательно твой код запускать на нем полное безумие. И ничкто этого не сделает.
WH>К томуже скорей всего там будет совсем другая система комманд.
Понимаете, вычислительному коду абсолютно пофиг есть ли защита памяти. Все что он делает — обрабатывает один буффер, записывая результат в другой. И что-то пока даже на сумасшедших RISCах люди умудряются писать код, работающий быстрее компилятора.

>>> Отсутствие арифметики указателей? Не понимаю зачем оно тебе надо.
C>>Я понимаю.
WH>Объясни.
В том же коде wavelet-преобразования у меня, например, используется адресная арифметика. Или в коде тесселяции поверхности (он на С++).

>>> Присутствие ГЦ?
C>>_Обязательное_ присутствие ГЦ (или никакой динамической памяти).
WH>Ну ГЦ можно заменить на счетчик ссылок. Плюс value типы...
Не может. Во-первых, счетчик ссылок дает overhead некоторый overhead. Во-вторых, value-типы ограничены (см. другое сообщение).

C>>Не привык я зря выкидывать деньги.
WH>Ты на отладке больше потеряешь.
Нет.

C>>Вот хотя бы: http://www.cs.rochester.edu/research/cashmere/
WH>Таки NCC-NUMA.
ncNUMA тоже называют (по аналогии с ccNUMA).

WH>Итого в общем случае это куча процессоров у каждого есть своя память. Причем передача данных между процессорами очень медленная.
Не "очень медленная", а "медленнее по сравнению с локальной".

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

>>> Про value типы слышал?
C>>Про ограничения value-типов слышал?
WH>А какие именно ограничения тебе так не нравятся?
А может ли value-тип реализовать мой интерфейс?

vvotan wrote:
> C>И как ни странно, мне Java очень нравится для написания Web-приложений.
> C>Tapestry+Hibernate — рулят
> С указанными технологиями не знаком, но как язык меня Java раздражает.
Мне как раз нравится, что Java — тупой как пробка язык с минимумом
сложностей. Поэтому всякую фигню типа Web-приложений на ней очень удобно
писать.

Ну и для Java есть огромное количество OpenSource-инструментов.

> C>Еще я использую Python (замечательный язык!) для скриптов через
> C>Boost.Python.
> Мне в последнее время больше нравится Ruby. В питоне эта маразматичная
> идея форматирования кода пробелами меня что-то не цепляет.
Я привык

> Только вот жалко аналога boost::python для Ruby нет.
Собственно, именно это меня и удерживает. Ну и еще в Python'е подсчет
ссылок замечательно совмещается с С++.

VladD2 wrote:
> На каком объеме? Понятно, что одну конкретную функцию в режиме тюнинга
> ты может и раскачегаришь. Но вот если ты попробушь написать все
> приложение на асме, то вряд ли сможешь опередить хороший компилятор.
Блин, ну никто не собирается на ассемблере писать все приложение! Он
нужен только для критичных внутренних циклов.

VladD2 wrote:
> C>Вы вообще, С++ знаете?
> Это очень смешно, но предупреждаю, что следующий кто будет заниматься
> исследованиями в области компетенции другого резко пойдет в баню на недел.
Это был вопрос, чтобы выяснить на каком уровне объяснять дальше.

VladD2 wrote:
> C>Тогда должны знать:
> C>1. Что refcount слишком дорог.
> Тут кто-то недавно давал ссылку на ЖЦ основанный на подсчете ссылок.
Этим "кто-то" был я

Дело в том, что в С++ я могу использовать такие вещи, как placement new
для коллекций value-типов (где value-коллекции в .NET?????). Поэтому
распределение памяти — достаточно редкая операция.

> C>2. Есть _быстрые_ автоматические объекты, которые refcount просто погубит.
> C>3. Есть схемы управления, которые не выражаются простым refcount'ом.
> Об этом там тоже рассказвалось.
В той доке циклические ссылки периодически собирались обычным GC.
Собственно, детектор циклов — это и есть GC.

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

WH>>>Например есть такой компилятор называется Intel C++... я уверен что не смогу написать на ассемблере код который будет лучше чем генерирует этот компилятор.
V>>А я смогу. Более того, неоднократно писал.

VD>На каком объеме?
Естественно, на минимально необходимом.

VD>Понятно, что одну конкретную функцию в режиме тюнинга ты может и раскачегаришь. Но вот если ты попробушь написать все приложение на асме, то вряд ли сможешь опередить хороший компилятор.
А нафига мне писать все приложение на асме? Ему всему предельная производительность не нужна, но фишка в том, что без предельной производительности отдельных частей, все приложение будет ненужно

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

VD>Здесь же именно о таком случае говорили видимо.
Насколько я понял, нет. Спорили о том, что какая бы ни была среда(управляемая или не очень), должна быть возможность, когда это необходимо, опустится на уровень ниже: в некоторых случаях перейти на более производительный неуправляемый код(на С++ как наиболее адекватном для этого неуправляемом языке), а иногда и на ассемблер, несмотря на все "фи" фанатичных адептов поддерживаемости и переносимости.

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

WH>>А какие именно ограничения тебе так не нравятся?
C>А может ли value-тип реализовать мой интерфейс?
Может. Может ты хотябы изучишь .NET? К томуже учти что можно реализовать это все намного умнее чем это сделали мелкософты..

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

C>Дело в том, что в С++ я могу использовать такие вещи, как placement new для коллекций value-типов (где value-коллекции в .NET?????). Поэтому распределение памяти — достаточно редкая операция.
В .NET 2 List<T> прекрасно работает с value типами.
К томуже для value типов new Type(...) это фактически placement new.

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

VD>Ты поглядел бы пример. Речь идет о том, что индексы массива могут сами по себе лежать в другом массиве. Причем исходный массив может иметь размер задаваемый в рантайме. Задать типами такое не удастся, так как тип не сможет отследить динамическое изменение размеров массива.
В некоторых случаях статический анализ таки может это сделать.
Скажем в таком коде это вполне возможно

class Mesh
{
    int[] _indexes;
    Vertex[] _vertexes;
    invariant
    {
        foreach(int i in _indexes)
            if not ( i in [0, _vertexes.Length - 1])
                error;
    }
    public const int[] Indexes
    {
        get { return _indexes; }
    }
    public const Vertex[] _Vertexes
    {
        get { return _vertexes; }
    }
}

Имея информацию о инварианте Mesh'а компилятор вполне может повыкидывать кучу проверок.
Хотя над этими механизмами нужно еще очень хорошо подумать никаких принципиальных препятствий я не вижу.

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

C>Понимаете, вычислительному коду абсолютно пофиг есть ли защита памяти. Все что он делает — обрабатывает один буффер, записывая результат в другой. И что-то пока даже на сумасшедших RISCах люди умудряются писать код, работающий быстрее компилятора.
Угу... пока... и не сильно...

C>В том же коде wavelet-преобразования у меня, например, используется адресная арифметика. Или в коде тесселяции поверхности (он на С++).
То что ты ее используешь это и так понятно. Вопрос в том, а оно действительно нужно?

C>Не может. Во-первых, счетчик ссылок дает overhead некоторый overhead. Во-вторых, value-типы ограничены (см. другое сообщение).
Вот только я занимался оптимизацией .NET приложений, а ты нет. Так что не надо говорить про ограничения value типов. Их возможностей для того чтобы что-то разогнать болие чем достатояно.

WH>>Таки NCC-NUMA.
C>ncNUMA тоже называют (по аналогии с ccNUMA).
Вот только гугль по ncNUMA ведет только на пару немецких сайтов...

C>Не "очень медленная", а "медленнее по сравнению с локальной".
Не суть важно. Главное что общение между процессорами нужно минимизировать.

WolfHound wrote:
> C>Понимаете, вычислительному коду абсолютно пофиг есть ли защита памяти.
> Все что он делает — обрабатывает один буффер, записывая результат в
> другой. И что-то пока даже на сумасшедших RISCах люди умудряются писать
> код, работающий быстрее компилятора.
> Угу... пока... и не сильно...
Разбудите когда не смогут больше....

> C>В том же коде wavelet-преобразования у меня, например, используется
> адресная арифметика. Или в коде тесселяции поверхности (он на С++).
> То что ты ее используешь это и так понятно. Вопрос в том, а оно
> действительно нужно?
В самой первой версии был красивый код тесселяции с std::vector и
контролем индексов. Работал в два раза медленнее.

> Вот только я занимался оптимизацией .NET приложений, а ты нет. Так что
> не надо говорить про ограничения value типов. Их возможностей для того
> чтобы что-то разогнать болие чем достатояно.
Чтобы "разогнать .NET" — достаточно. Чтобы заменить автоматические
объекты С++ — нет.

> WH>>Таки NCC-NUMA.
> C>ncNUMA тоже называют (по аналогии с ccNUMA).
> Вот только гугль по ncNUMA ведет только на пару немецких сайтов...
У меня так в журналах написано ("Открытые Системы").

> C>Не "очень медленная", а "медленнее по сравнению с локальной".
> Не суть важно. Главное что общение между процессорами нужно минимизировать.
Естественно. Его и в случае с SMP нужно оптимизировать — синхронизация
кэшей все равно не быстрый процесс.

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

C>В самой первой версии был красивый код тесселяции с std::vector и контролем индексов. Работал в два раза медленнее.
Контроль индектов в С++ оптимизировать практически не реально.

C>Чтобы "разогнать .NET" — достаточно. Чтобы заменить автоматические объекты С++ — нет.
А что таково в автоматических объектах чего не могут дать value типы?

C>Естественно. Его и в случае с SMP нужно оптимизировать — синхронизация кэшей все равно не быстрый процесс.
Просто сейчас алгоритмы однопоточные и данные модифицирует только один поток. Так что ничего синхронизировать не надо.
Синхронизация понадобится если алгоритмы начнут паралелить. Но тут опять таки нужна высокоуровневая оптимизация.

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

C>Это был вопрос, чтобы выяснить на каком уровне объяснять дальше.

Этот вопрос выглядел очень некрасиво. Ты бы для разнобразия в топ С++ поглядел бы.

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

WH>В некоторых случаях статический анализ таки может это сделать.

Ключевое слово здеть "В некоторых случаях". Еще раз. Общего решения тут быть не может.
Первые динамические данные и ты приехал. А зачем данные в массивы пихать если они не динамические?

В общем, тут проще положиться на рантайм проверки. В релизе их можно убрать.

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

VD>Ключевое слово здеть "В некоторых случаях". Еще раз. Общего решения тут быть не может.
Как правило именно эти некоторые случаи и являются критическими по производительности...
VD>Первые динамические данные и ты приехал. А зачем данные в массивы пихать если они не динамические?
Я не случайно выбрал именно такие имена для класса и челенов класса... Например это загруженая с диска модель или текстура или еще какиенибудь данные.

VD>В общем, тут проще положиться на рантайм проверки.
Если можно убрать проверки статическим анализом то нужно их убирать.
VD>В релизе их можно убрать.
А вот это делать не нужно. Особенно если мы говорим об управляемой ОС то там это сделать вобще нельзя.

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

C>WolfHound wrote:
>> Вобщем С++ хороший язык... когдато был...
>> А сейчас рулят ковровые клинья и танковые бомбандировки тфу ты
>> управляемые среды, а дальше будут рулить упровляемые ОС типа Singularity
>> для которых на С++ вобще писать будет довольно проблематично.
C>Да вы, батенька, оптимист.

C>Будут рулить вещи типа cell-архитектур для которых C# не подходит
C>абсолютно и полностью. С++ тоже плохо подходит, правда.


Все написаное основано на прочтении след. статьи

Некоторые особенности SPE:
— 256KBytes local store — здесь располагаются данные и программа
— Процессор предназначен для векторных вичисление. Обычные вычисления он делать может, но это не его задача, кроме того он также не предназначен для логики (много переходов)
— Своя система команд, хотя и есть пересечение с AltiVec (т.е. код нужно будет по крайне мере под него пересобрать)

Языки/решения:
1) Разделение языков. На основном процессоре (PPE) используется любой язык, для работы с SPE используется библиотека позволяющая загрузить некий job, посылать и получать данные с SPE, синхронизироваться. Для SPE используется некий достаточно низкоуровневый язык, с поддержкой векторных вычисление (ну или асм вставки) и примитивами для общения с другими SPE и PPE.

Для десктоп систем язык SPE возможно будет позводять создавать законченные mini-jobs, работающие по приниципу загрузился в SPE, сделал работу, освободили место для других.
Возможно будет некий язык описания интерфейсов на подобие IDL для COM/CORBA

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

2) Мини VM (без JIT), сидящая в SPE.
Это вряд ли, получиться медленно, да и памяти там не так много чтобы и VM и программу и еще входные и выходные данные засунуть. Но в любом случае это VM должна поддерживать все векторные возможность SPE.
Вообще моловероятные вариант, SPE сам по себе можно в качестве это VM и рассматривать (есть такие слова в статье)


3) VM c JIT.
Памяти надо еще больше чем в пред. пункте. Плюс тратить время на JIT, SPE под это не заточен

4) JIT на PPE генерирует native код для SPE из управляемого.
Т.е. на неком управляемом языке пишем, получаем IL, дальше JIT генерит код и грузит сразу в SPE на выплнение.
Забавно наверное выйдет.

В любомом случае маловероятным кажется, что все будет написано на одном языка. Слишком разные процессоры (один векторный и это его фишка), слишком разные задачи, необходимость выделения параллельных кусков для SPE, синхронизация, все компилатору/framework-у доверять не стоит.


P.S. Apple отказался от использования процессоров IBM хотя про Cell наверняка в курсе, видимо там считают, что на рынок Desktop систем это процессор ничего революционного не принесет

P.P.S. Вообще создалось такое впечатление, что автор пиарит Cell неколько больше чем следует. Да и вцелом от этого чуда ожидают больше чем оно сможет дать

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

RRM>4) JIT на PPE генерирует native код для SPE из управляемого.
RRM>Т.е. на неком управляемом языке пишем, получаем IL, дальше JIT генерит код и грузит сразу в SPE на выплнение.
RRM>Забавно наверное выйдет.
ИМХО наиболие разумный вариант.

RRM>В любомом случае маловероятным кажется, что все будет написано на одном языка. Слишком разные процессоры (один векторный и это его фишка), слишком разные задачи, необходимость выделения параллельных кусков для SPE, синхронизация, все компилатору/framework-у доверять не стоит.
Если спроектировать ВМ для работы на NCC-NUMA системах, а это не только и не столько cell. То можно все делать на одном фреймворке. Болие того м коде программ можно раставлять хинты оптимизатору для того чтобы он лучше паралелил.

WolfHound wrote:
> WH>>А какие именно ограничения тебе так не нравятся?
> C>А может ли value-тип реализовать мой интерфейс?
> Может. Может ты хотябы изучишь .NET? К томуже учти что можно реализовать
> это все намного умнее чем это сделали мелкософты..

Value types can have fields, properties, and events. They can also have
static and nonstatic methods. When they are boxed, they inherit
the virtual methods from System.ValueType, and they can implement zero
or more interfaces.

И зачем мне забоксированый value-тип?

WolfHound wrote:
> C>Можно использовать "fat pointers" — то есть в указатель записывается
> еще и длина адресуемого блока (так было и на AS/400).
> Те указатели в общем случае должны быть в два раза больше?
Да.

> В любом случае это не спасет от смещения указателя на пол размера структуры. Те
> нам понадобится еще и размер структуры. Те указатель должен быть в 3
> раза больше... плюс куча транзисторов для проверки.
Поэтому толстые указатели и не используются.

> C>Но это обычно никому не нужно, главное дать гарантию, что код
> теоретически не сможет вырваться из своего sandbox'а. А для этого tagged
> pointer'ов вполне хватает.
> это нужно всем. Это надежность программы.
Нет. Это _не_ надежность программы. Надежность программы — это
отсутствие ошибок.

> Короче я так и не понял зачем нужны все эти сложности на низком уровне
> если анализ проведенный на высоком уровне позволяет этого избежать?
Нудно: "Затем что 'высокоуровневый' анализ накладывает слишком много
ограничений". Тем более, что tagged pointer'ы — это давно испробованый и
надежный вариант. Для его использования даже модули памяти не надо
менять — можно использовать бит четности для тэга.

> 1)В подавляющем большинстве случаев компилятор генерирует оптимальный код.
Однако это не всегда так. И в тех случаях, когда все-таки нормальный код
не генерируется — ничего сделать нельзя.

> 2)Упрощение процессоров позволит поднять производительность процессоров.
Небольшое упрощение.

> 3)Работы по совершенствованию оптимизаторов постоянно ведутся.
Я это слышу уже лет... не знаю сколько.