OpenCL и нематематическая задача

[bixbit]

Есть нематематическая задача - считать ячейку в ЖД.
Как её выполнить в *.cl файле имея готовый код даной функции (т.е. распаралелить выполнение)?
Или предложите другой метод распаралеливания

[Igors]

В любом случае не существует какого-то общего/универсального способа распараллеливания. Поэтому код ф-ции предъявляем.

Есть нематематическая задача - считать ячейку в ЖД.

У нас в городе построили новый ЖД вокзал (говорят очень красивый хотя я еще не видел). Так что ячейку наверное считаем 

[bixbit]

ЖД - Жесткий диск

Код:

if (ReadFile (hFile, buff, BYTECOUNT, &dwBytesRead, NULL))
{
	xor(buff, hash,buff);
	WriteFile (hAppend, buff, dwBytesRead,&dwBytesWritten, NULL);
}

Этот код как пример. Но суть не в самом коде а в том, чтоб получить минимальное время работы при количестве вызовов ~10⁹.

[Igors]

ЖД - Жесткий диск

Код:

if (ReadFile (hFile, buff, BYTECOUNT, &dwBytesRead, NULL))
{
	xor(buff, hash,buff);
	WriteFile (hAppend, buff, dwBytesRead,&dwBytesWritten, NULL);
}

Этот код как пример. Но суть не в самом коде а в том, чтоб получить минимальное время работы при количестве вызовов ~10⁹.

Кешировать чтение/запись, распараллеливание здесь ни при чем

[bixbit]

Кешировать чтение/запись, распараллеливание здесь ни при чем

Хорошо. Почитаю про кеширование.
Для конкретной задачи такое можно использовать.

Это одна из задач. А если к примеру нужно делать большое количество get запросов и они независимы как тогда добится максимальной производительности.

[Igors]

А если к примеру нужно делать большое количество get запросов и они независимы как тогда добится максимальной производительности.

Нет какого-то общего способа "чудесного распараллеливания", да и не всегда оно возможно. Напр если "ЖД" один - нет смысла писать параллельно. т.к. льется-то все равно в одну дырочку. Если имеется напр 4 ядра - 100 параллельных запросов не быстрее чем 4 а только медленнее. Поэтому нужен конкретный подход, а не "к примеру"

[bixbit]

А если к примеру нужно делать большое количество get запросов и они независимы как тогда добится максимальной производительности.

Нет какого-то общего способа "чудесного распараллеливания", да и не всегда оно возможно. Напр если "ЖД" один - нет смысла писать параллельно. т.к. льется-то все равно в одну дырочку. Если имеется напр 4 ядра - 100 параллельных запросов не быстрее чем 4 а только медленнее. Поэтому нужен конкретный подход, а не "к примеру"

Мне и не надо "чудесного распараллеливания".
Я хочу разобратся как мжно добиться максимального количества итераций, когда даные, которые мне возвращяет функия приходят с одинаковой задержкой независимо от того зделан 1 или 1000 запросов.
Так какие методы распрараллеливания подходят для круга задач с такой постановкой?

[Igors]

Мне и не надо "чудесного распараллеливания".
Я хочу разобратся как мжно добиться максимального количества итераций, когда даные, которые мне возвращяет функия приходят с одинаковой задержкой независимо от того зделан 1 или 1000 запросов.
Так какие методы распрараллеливания подходят для круга задач с такой постановкой?

Постановки (пока) нет. Все зависит от того что это за ф-ция, что она делает.

[bixbit]

Мне и не надо "чудесного распараллеливания".
Я хочу разобратся как мжно добиться максимального количества итераций, когда даные, которые мне возвращяет функия приходят с одинаковой задержкой независимо от того зделан 1 или 1000 запросов.
Так какие методы распрараллеливания подходят для круга задач с такой постановкой?

Постановки (пока) нет. Все зависит от того что это за ф-ция, что она делает.

Отправляет запрос на сервер. Проверяет наличие страницы и доступа к ней.

[Igors]

Отправляет запрос на сервер. Проверяет наличие страницы и доступа к ней.

Насколько мне известно alexis031182 этим довольно плотно занимается. Спросите у него

[alexis031182]

Я занимаюсь серверной стороной. И под ОС Linux. У Вас, получается, - клиентская часть. В любом случае Вам нужно использовать неблокирующие сокеты, а количество тредов здесь, по идее, не имеет значения, и одного достаточно будет. Или можно разделить на два. Один тред на отправку запросов, а второй - на приём ответов.