Здравствуйте, Cyberax, Вы писали:
C>Не получится. В КУДЕ точно так же идёт работа с указателями. С помощью них можно что угодно делать с карточкой, фактически. Но вот проверку на выход за диапазон ты просто поставить везде не сможешь — ветвления жутко дорогие без предсказателя переходов.
Поэтому нужна статическая верификация кода и устранение избыточных проверок.
C>Основной метод борьбы с глючными ядрами (программами для КУДА) сейчас — это переинициализация карты по таймауту. Ну и ещё есть зачаточная виртуальная память.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Поэтому самый простой вариант кода будет открывать файлмэппинг, GetEnumerator будет возвращать новый экземпляр IEnumerable<string>, который содержит в себе текущую позицию, а Last будет обращаться к концу отмапленной области.

При открытии файлмэппинга никакой IEnumerable получить нельзя, потому что нечего энумерировать. Есть только хэндл мэппинга, больше ничего. Всякая деятельность может начинаться только при открытии view (MapViewOfFile), а вот тут тебя проблемы и будут ждать.

S>Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.

Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.


Но вопрос-то не в этом. Дело не в возможности, а в логике этих действий. Если мне нужна последняя строка — зачем это простое действие привязывать к IEnumerable ? Зачем создавать интерфейс, в котором, мягко говоря, нет логики ? Зачем мне тут IEnumerable, когда и без него хорошо ? Он ведь никак не поможет для собственно задачи получения последней строки — если, конечно, не вернуться к алгоритму перебора их по одной.

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

FR>>Для C++ тоже вполне реально, та же изоляция в системный процесс например.
S>Это фантастика. Для классического неуправляемого приложения граница разрушения — это процесс. Взаимодействие процессов — очень дорогое. Поэтому реализация всех кирпичиков в виде отдельных процессов в большинстве случаев неприемлема по производительности. (Хотя, конечно, и возможна).

Это в основном на виндовсе из за её богатой истории.

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

S>>Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.

PD>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.

Это и есть "исчерпать АП раньше времени"

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

C>Хех. Тебе рассказать про то как извращаются с памятью для увеличения локальности?
C>Вот пример: http://en.wikipedia.org/wiki/Z-order_(curve)
И чё?
Заводим функцию с сигнатурой что-то вроде

def ZOreder{n : nat | isPowOf2(n)}(x : nat | x < n, y : nat | y < n) -> (res : nat | res < n * n)

И вперед с песней.
Учитывая что я с ходу не придумал как ее эффуктивно реализовать через стандартные операции что-то мне подсказывает что есть аппаратная реализация этого дела.
Так что просто при компиляции заменяем это дело на вызов соответствующей комманды и все.

C>Чего-нибудь простое типа: http://developer.download.nvidia.com/compute/cuda/sdk/Projects/convolutionTexture.zip
А как реагирует tex2D на выход за приделы текстуры?
Ибо мне что-то подсказывает что там на краях текстуры индексы получаются за приделами текстуры...

__global__ void convolutionRowGPU(
    float *d_Result,
    int dataW,
    int dataH
){
    const   int ix = IMUL(blockDim.x, blockIdx.x) + threadIdx.x;
    const   int iy = IMUL(blockDim.y, blockIdx.y) + threadIdx.y;
    const float  x = (float)ix + 0.5f;
    const float  y = (float)iy + 0.5f;

    if(ix < dataW && iy < dataH){
        float sum = 0;

#ifdef UNROLL_INNER
        sum = convolutionRow<2 * KERNEL_RADIUS>(x, y);
#else
        for(int k = -KERNEL_RADIUS; k <= KERNEL_RADIUS; k++)
            sum += tex2D(texData, x + k, y) * d_Kernel[KERNEL_RADIUS - k];
#endif

        d_Result[IMUL(iy, dataW) + ix] = sum;
    }
}

C>Кстати, ты ещё не забывай, что в CUDA часто индексы — не целые, а float'ы. С аппаратной интерполяцией.
А чё? Данному механизму всеравно с чем работать. Он и то и другое прожует.

C>Да, а ещё я могу с помощью race condition'ов элементарно сделать невалидные указатели.
Так язык должен не позволять устраивать гонки.

C>И это ты НИКАК не проверишь — нет в CUDA сильной типизации.
За это разработчикам этой КУДЫ нужно отрывать голову. Ибо никаких причин для такого решения нет.

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

C>>Чего-нибудь простое типа: http://developer.download.nvidia.com/compute/cuda/sdk/Projects/convolutionTexture.zip
WH>А как реагирует tex2D на выход за приделы текстуры?
железо умеет автоматически WRAP или CLAMP. Не помню уже как в CUDA этим управлять.

C>>Да, а ещё я могу с помощью race condition'ов элементарно сделать невалидные указатели.
WH>Так язык должен не позволять устраивать гонки.
Железо зато позволяет. А средства синхронизации очень дороги.

C>>И это ты НИКАК не проверишь — нет в CUDA сильной типизации.
WH>За это разработчикам этой КУДЫ нужно отрывать голову. Ибо никаких причин для такого решения нет.
Есть. Аппаратная реализация была ДО того как появилась CUDA.
Грубо говоря, CUDA это API к уже имеющимся аппаратным решениям, которые архитектурно много лет затачивались для задач обработки графики.

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

WH>>А как реагирует tex2D на выход за приделы текстуры?
CC>железо умеет автоматически WRAP или CLAMP. Не помню уже как в CUDA этим управлять.
Раз железо не позволяет обращаться мимо текстуры то вообще никаких проблем.

CC>Железо зато позволяет. А средства синхронизации очень дороги.
Несколькими сообщениями выше Cyberax говорил тоже самое про проверки границ массивов.
Как видишь проверки легко устраняются статически.
С гонками можно сделать тоже самое.

CC>Есть. Аппаратная реализация была ДО того как появилась CUDA.
CC>Грубо говоря, CUDA это API к уже имеющимся аппаратным решениям, которые архитектурно много лет затачивались для задач обработки графики.
И чё?
Разве нельзя было сделать нормальный язык, а не кошмарить и так кошмарный С++?

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

CC>>Железо зато позволяет. А средства синхронизации очень дороги.
WH>Несколькими сообщениями выше Cyberax говорил тоже самое про проверки границ массивов.
WH>Как видишь проверки легко устраняются статически.
Не вижу. Где смотреть? Ссылку на практику дай. Теории я и сам могу напридумывать.
Ты не забывай что кроме текстур есть еще и обычные массивы, для которых нет никакого wrap/clamp.

WH>С гонками можно сделать тоже самое.
Та ты шо? Где этот мегатул? Ссылку!

CC>>Грубо говоря, CUDA это API к уже имеющимся аппаратным решениям, которые архитектурно много лет затачивались для задач обработки графики.
WH>И чё?
WH>Разве нельзя было сделать нормальный язык, а не кошмарить и так кошмарный С++?
Дык сделай, раз так просто! На той ограниченной аппаратной реализации что есть сейчас реально работает очень покоцаный сабсет С.
С++ там и близко нет. Там и до полной поддержки С еще пилить и пилить.
Причем С как язык идеально подходит из-за минимального оверхеда. Будучи по сути высокоуровневым ассемблером он не генерит никакой автоматики, которая бы хавала львиную долю выигрыша скорости от использования CUDA.

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

CC>Не вижу. Где смотреть? Ссылку на практику дай. Теории я и сам могу напридумывать.
Ссылку я уже давал.
Вот более прямая ссылка раз ты пару кликов сделать не можешь http://www.cs.cmu.edu/Groups/fox/people/fp/papers/pldi98dml.pdf

CC>Ты не забывай что кроме текстур есть еще и обычные массивы, для которых нет никакого wrap/clamp.
А ты ссылочку то прочитай... там какраз про массивы. Бенчмарки тоже имеются.

CC>Та ты шо? Где этот мегатул? Ссылку!
Это только не большая их часть. Смотри те где нет "obsrvable nondeterminism"
The principal programming paradigms

Автор: remark
Дата: 05.12.09

WH>>Разве нельзя было сделать нормальный язык, а не кошмарить и так кошмарный С++?
CC>Дык сделай, раз так просто!
Сколько заплатишь?

CC>На той ограниченной аппаратной реализации что есть сейчас реально работает очень покоцаный сабсет С.
CC>С++ там и близко нет. Там и до полной поддержки С еще пилить и пилить.
А с каких это пор в С шаблоны появились?

////////////////////////////////////////////////////////////////////////////////
// Loop unrolling templates, needed for best performance
////////////////////////////////////////////////////////////////////////////////
template<int i> __device__ float convolutionRow(float x, float y){
    return 
        tex2D(texData, x + KERNEL_RADIUS - i, y) * d_Kernel[i]
        + convolutionRow<i - 1>(x, y);
}

template<> __device__ float convolutionRow<-1>(float x, float y){
    return 0;
}

template<int i> __device__ float convolutionColumn(float x, float y){
    return 
        tex2D(texData, x, y + KERNEL_RADIUS - i) * d_Kernel[i]
        + convolutionColumn<i - 1>(x, y);
}

template<> __device__ float convolutionColumn<-1>(float x, float y){
    return 0;
}

CC>Причем С как язык идеально подходит из-за минимального оверхеда. Будучи по сути высокоуровневым ассемблером он не генерит никакой автоматики, которая бы хавала львиную долю выигрыша скорости от использования CUDA.
Тут наблюдается какаято вера в то что все что имеет более высокий уровень чем С вносит оверхед.
Это не правда.
Вот например http://www.impredicative.com/ur/ компилируется в С. ГЦ за собой не тянет.

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

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

FR>>Для C++ тоже вполне реально, та же изоляция в системный процесс например.
S>Это фантастика. Для классического неуправляемого приложения граница разрушения — это процесс. Взаимодействие процессов — очень дорогое. Поэтому реализация всех кирпичиков в виде отдельных процессов в большинстве случаев неприемлема по производительности. (Хотя, конечно, и возможна).

А интерпретирующий эрланг почему-то приемлем.
Взаимодействие процессов через ту же разделяемую память не так уж и дорого, правда их рождение в default ос конечно дороговато.

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

С этим я не спорю. Просто говорю что и на C++ возможна эрлангоподобная организация системы хоть и коряво.

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

I>Здравствуйте, Pavel Dvorkin, Вы писали:

S>>>Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.

PD>>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.

I>Это и есть "исчерпать АП раньше времени"

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

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

S>>>>Основная сложность будет в том, чтобы аккуратно работать с файлами "слишком большого" размера, чтобы не исчерпать адресное пространство раньше времени.

PD>>>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.

I>>Это и есть "исчерпать АП раньше времени"

PD>Не совсем. Во-первых, время тут вообще ни при чем.

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

>Во-вторых, большой файл нельзя уложить целиком в АП независимо от чего бы то ни было (ну кроме перехода в x64).

"нельзя уложить целиком в АП" == "исчерпать АП раньше времени"

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

>>Во-вторых, большой файл нельзя уложить целиком в АП независимо от чего бы то ни было (ну кроме перехода в x64).

I>"нельзя уложить целиком в АП" == "исчерпать АП раньше времени"

Нельзя уложить целиком в АП — означает , что это вообще нельзя, независимо от времени.

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

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

>>>Во-вторых, большой файл нельзя уложить целиком в АП независимо от чего бы то ни было (ну кроме перехода в x64).

I>>"нельзя уложить целиком в АП" == "исчерпать АП раньше времени"

PD>Нельзя уложить целиком в АП — означает , что это вообще нельзя, независимо от времени.

Я в курсе. Просто сообщаю, то что ты хочешь сказать можно сказать иначе, с пом. идиомы русского языка "раньше времени".

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

PD>Еще раз — не стоит в процентах измерять эти множества. Это как грибы — чтобы наполнить корзину, хватит десятка белых, а опят понадобятся сотни.

Главное тут, как и в грибах, не перепутать, и не собрать десяток опят, игнорируя белые, угробив на это весь день и порадовавшись удачному результату.

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

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

PD>От заказчика беречь просто невозможно, а конкурентов нет.

Да не от заказчика, а его самого! А то так ляпнешь его название на форуме — и конкуренты и появятся. Я уже окромя нашего маркетолога могу порекомендовать гендиректора и пару аналитиков, которые воспоют такие дифирамбы умному JIT, что ассемблерные вставки покажутся каменым веком.
Ну а мы, как команда разработчиков, будем исправно увеличивать быстродействие от релиза к релизу.
Всю стену комнаты благодарностями увешаем!
А стена у нас длииииная...

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

PD>Но вопрос-то не в этом. Дело не в возможности, а в логике этих действий. Если мне нужна последняя строка — зачем это простое действие привязывать к IEnumerable ? Зачем создавать интерфейс, в котором, мягко говоря, нет логики ?

А если предпоследняя? А если 7я с конца?

А если ровно 7 последних строк надо?

Один умный мужик, Бьерн Страуструп, в одной умной книжке — "Язык программирования С++", с которой я начинал свое знакомство с промышленным программированием (и которая до сих пор стоит у меня на полке, хотя я давно программирую на .NET), писал разное про обработку данных — и представь, активно призывал пользоваться именно стандартной библиотекой шаблонов и enumenator-ами (итераторами с терминологии stl), и в т.ч. приводил примеры обратных итераторов — т.е. когда файл может читаться енумератором с начала до конца, а может с конца до начала... Ну а може их середины к обоим концам, через четные строки, кратные пяти по четвергам и трем — по пятницам. А код, использующий этот итератор не меняется от изменения способа перебора входных данных ни на символ. Это преподносилось как достижение в переиспользуемости кода, гибкости, расширяемости, и сокращению издержек. На нативном С++, напоминаю.

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

I>Это в основном на виндовсе из за её богатой истории.
Да-да-да. Напомните мне, на какой системе изобрели FastCGI?

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


PD>При открытии файлмэппинга никакой IEnumerable получить нельзя, потому что нечего энумерировать. Есть только хэндл мэппинга, больше ничего. Всякая деятельность может начинаться только при открытии view (MapViewOfFile), а вот тут тебя проблемы и будут ждать.
Рекомендую на досуге ознакомиться с определением IEnumerable и глупостей больше не писать.

PD>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать.
(Вздыхает).
1. Павел, а кто тебе сказал, что всё АП принадлежит твоей функции? Поэтому слово "больших" тут не нужно. Речь идёт об исчерпании АП, и вовсе не обязательно иметь пятигигабайтный файл, чтоб на него нарваться.
2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен.

PD>Но вопрос-то не в этом. Дело не в возможности, а в логике этих действий. Если мне нужна последняя строка — зачем это простое действие привязывать к IEnumerable ? Зачем создавать интерфейс, в котором, мягко говоря, нет логики ? Зачем мне тут IEnumerable, когда и без него хорошо ? Он ведь никак не поможет для собственно задачи получения последней строки — если, конечно, не вернуться к алгоритму перебора их по одной.
Логика действий — неумолимая. Я реализую класс, который предоставляет доступ к строкам файла как к коллекции.
И я могу сделать одинаково эффективный доступ как по очереди, так и с конца. Вот только логика чтения файла тут изолирована от алгоритма, который ею пользуется.
Алгоритму важно сказать Last() и не париться — может, там все данные уже в памяти построчно сидят. Реализация при этом, как видишь, никак в эффективности не проигрывает.

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

FR>С этим я не спорю. Просто говорю что и на C++ возможна эрлангоподобная организация системы хоть и коряво.
Ну, в некотором смысле — да. То есть можно написать ядро ерланг-системы на C++, и исполнять на нём эрланг-программы. Но я не считаю это "эрлангоподобной организацией системы".
А на чистом C++ ничего близкого получить не удастся. Семантика языка не та.