Здравствуйте, AndrewVK, Вы писали:
AVK>На С++ в таких случаях пишется шаблон, реализация которого прекрасно инлайнится, причем возможности инлайнинга у современных компиляторов С++ заметно выше дотнетного или джавовского джита.
Нужно уточнить что современные реализации С++ лучше инлайнят чем современный JIT но это не теоритическое ограничение.
Просто еще JIT'ы недоделали.
The choice of Java as a target for current supercompilation research is not coincidental. It was desired to choose a real-world programming language, in which there are numerous examples of large-scale programs needful of multifold optimization. C and C++ would seem to be the first choice; however, these languages are particularly unsuitable for global program optimization techniques, because of their use of pointers, which directly manipulate the memory heap. In order to do global program optimization on a C/C++ program, one would have to include in one's mathematical model of a program, a complete mathematical model of the memory heap and its interactions with the program. This is not impossible, but it would entail a huge increase in the complexity of the task involved.
То... кто кого порвет мы еще посмотрим.... шипела на тузика надутая до 100 атмосфер грелка.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А если предварительно пройтись сеперкомпилятором http://www.supercompilers.com/white_paper.shtml который для С++ реализовать мягко говоря не просто...
S> Серъезно? Ну-ка, ну-ка, и как же нужно модифицировать этот запрос, чтобы он наворотил тучу SQL запросов? Хочется подтвердить эту небезынтересную гипотезу реальным ахтунг-примером.
Здравствуйте, AndrewVK, Вы писали:
PD>>и результаты его меня просто пугают.
AVK>welcome to real world
"Этот прекрасный новый мир" (О.Хаксли) не читал ? Кстати, управляемый
PD>>А где там запутанность ? Нормальный код, как все на Win32 пишут.
AVK>Самому не смешно?
Ну тогда зайди в форум по Win32 и объяви во всеуслышание — все, что вы тут делаете — смешно. Потому что там именно такой код и пишут, и мой — не лучше и не хуже. Зайди и напиши, честное слово. Посмотрим на реакцию.
AVK>>>Вот, кстати, характерная твоя ошибка — говорим о дизайне кода, а ты даже не в состоянии привести пример без использования специфики Win32.
PD>>Опять ? Я же привел тебе описание задачи!
AVK>Тогда забудь в этом топике про слово Win32, ты же его через абзац упоминаешь.
А ты готов забыть в этом топике про C#, .Net. LinQ ? Либо уж оба забудем, либо оба нет
PD>> Ну не могу же я его привести, не упоминая окна и пикселей, если задача именно с окном и именно с пикселями.
AVK>Вот об этом и речь.
Андрей, мы что-то воду в ступе толчем. Не хочешь окна и пикселей — возьми массив двумерный произвольного происхождения с цветами в качестве элементов. Что изменится, кроме ожидания, конечно ?
PD>>Да никто и не заставляет. Ну не нравится тебе мое описание — сказал, я согласился, дал другое.
AVK>Нук а я тебе дал ответ. Что тебя еще не устраивает?
Да меня все устраивает, только, ей-богу, я уже не пойму, о каком ответе и каком вопрос речь идет
PD>> Впрочем, чтобы IT-ские проценты сравнить в AsParallel и без, то же придется сделать. Но все же никак не пойму — чего ты к пустякам придираешься ? Ну какое отношение к распараллеливанию имеет вопрос откуда и как брать эту матрицу ?
AVK>Win32, Win32, Win32, Win32. Напоминаю — обсуждать тут пытались конструкции языков программирования. Я понимаю, тебе про этот Win32 каждый день приходится студентам рассказывать, но надо хоть чуть чуть абстрагироваться, если тема разговора никакого отношения к Win32 не имеет.
Андрей, ну некорректные же аргументы. Не хочешь Win32 — не надо, но зачем педалировать-то ? Там распараллеливание алгоритма, это главное, остальное второстепенное. А про конструкции vs бмблиотеки я уже сказал.
PD>>Вообще-то нет. Про ФП я могу не знать, про LinQ тоже, а вот SQL знать надо, иначе я его этот SELECT и GROUP в нем не пойму.
AVK>А ты SQL не знаешь?
Знаю А если бы нет ? Вот предстваь себе — пишет некий X математическую обработку, ему SQL совсем не нужен. А матрицы по диагоналям он сплошь и рядом проходит — в линейной алгебре диагональных, трехдиагональных и нижне- или верхне- треугольных матриц хоть пруд пруди.
PD>>Андрей, это уж никуда не годится. Я привел этот пример именно, чтобы показать, что когда мне надо не в "горизонтально-вертикальном", а в произвольном направлении ходить, ваш подход ИМХО пробуксовывает.
AVK>Нигде он не пробуксовывает. Тебе уже два человека написали — начальные итераторы (в моем коде Enumerable.Range) можно написать какими угодно, причем код будет короче за счет наличия в шарпе специальных конструкций для этого.
Ну и прекрасно. Примем, что это сделать можно. Я же с самого начала писал — я вовсе не утверждаю, что это сделать нельзя.
PD>>Я вот одно понять не могу. Ну что стоит признать, что для определенной ситуации этот подход не очень хорош ?
AVK>О, вот очень удачно ты это спросил. Ты сам, лично, ни разу здесь не признал, что был не прав, даже если, порой, тебе приводили абсолютно неопровержимые аргументы. Зато с других ты это требуешь.
Прекрасно. Вот на этом месте я и закончу, иначе можно продолжать до бесконечности. Продолжение см. в моем следующем письме, поскольку хочу выделить это с отдельным заголовком.
Предлагаю всем, кто согласен, подписать следующую декларацию. Я один раз такое уже делал, несколько лет назад, но ничего, хуже не будет, повторим.
1. Существуют задачи, для решения которых использование низкоуровневых средств, таких как C/C++ или ассемблер, неэффективно и нецелесообразно, а применение высокоуровневых средств, таких как C# (включая LinQ), языки ФП и т.д. — оправданно и наиболее эффективно.
2. Существуют задачи, для решения которых использование высокоуровневых средств, таких как C# (включая LinQ), языки ФП и т.д., неэффективно и нецелесообразно, а применение низкоуровневых средств, таких как C/C++ или ассемблер — оправданно и наиболее эффективно.
Слова "неэффективно и нецелесообразно" и "оправданно и наиболее эффективно" понимаются в некотором общем смысле, без конкретной расшифровки. Просто — стоит такое использовать или же нет в реальной жизни.
Я, Дворкин П.Л., настоящим подписываюсь под этой декларацией и призываю моих оппонентов подписаться под ней.
Подпись под этой декларацией можно осуществить двумя способами. Либо поставьте мне на это сообщение плюс, либо ответьте на это сообщение своим со словом "согласен".
Несогласные с этой декларацией могут поставить мне минус или же ответить со словом "не согласен". Объяснение причин несогласия желательно, но не обязательно.
Персонально приглашаю AndrewVK и Sinclair подписаться под этой декларацией
Здравствуйте, AndrewVK, Вы писали:
AVK>welcome to real world
Вот, кстати, про real world. Со мной уже все ясно — проценты я считать не умею, ладно . Но не я один такой. Оказывается, и суммы-то точно считать не умеют, и кто — страшно сказать!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот, кстати, про real world. Со мной уже все ясно — проценты я считать не умею, ладно . Но не я один такой. Оказывается, и суммы-то точно считать не умеют, и кто — страшно сказать!
PD>Не иначе как они это суммирование распараллелили
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Предлагаю всем, кто согласен, подписать следующую декларацию. Я один раз такое уже делал, несколько лет назад, но ничего, хуже не будет, повторим.
<skipped>
PD>Слова "неэффективно и нецелесообразно" и "оправданно и наиболее эффективно" понимаются в некотором общем смысле, без конкретной расшифровки. Просто — стоит такое использовать или же нет в реальной жизни.
Павел! понятия эффективности и целесообразности без специальных оговорок весьма субъективны.
Подпись под такой декларацией позволит и дальше оппонентам иметь разные мнения об эффективных и целесообразных мерах для решения одной конкретной задачи. А факт существования таких задач из пунктов 1) и 2), где по поводу эффективности сойдутся большинство мнений — не интересен.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Андрей, мы что-то воду в ступе толчем. Не хочешь окна и пикселей — возьми массив двумерный произвольного происхождения с цветами в качестве элементов. Что изменится, кроме ожидания, конечно ?
Мне в такие моменты не жлако тестовых примеров написать. Суммирование столбцов матрицы, машина у меня двухпроцессорная.
На C++ по приведенному ранее коду:
const int matrixWidth = 1280;
const int matrixHeight = 1024;
struct CHUNK
{
unsigned int *matrix;//!int xStart, xEnd;
int nHeight;
};
unsigned* columnSum;
unsigned __stdcall ThreadFunc(void* arg)
{
CHUNK* pChunk = (CHUNK*) arg;
int xEnd = pChunk->xEnd;
int nHeight = pChunk->nHeight;
unsigned int* matrix = pChunk->matrix;//!for (int x = pChunk->xStart; x <= xEnd; x++)
{
unsigned s = 0;
for ( int y = 0; y < nHeight; y++)
{
s += matrix[x + y * matrixWidth];//!
}
columnSum[x] = s;
}
return 0;
}
int _tmain(int argc, _TCHAR* argv[])
{
unsigned int *matrix = new unsigned int[matrixWidth*matrixHeight];//!for(int i=0; i<matrixWidth*matrixHeight; i++)
{
matrix[i] = i;
}
int nHeight = matrixHeight;
int nWidth = matrixWidth;
columnSum = new unsigned[nWidth];
// без распараллеливания
DWORD nTime1, nTime2, dwTimeStart , dwTimeEnd;
dwTimeStart = GetTickCount();
for ( int x = 0; x < nWidth; x++)
{
unsigned s = 0;
for(int y = 0; y < nHeight; y++)
{
s += matrix[x + y * matrixWidth];//!
}
columnSum[x] = s;
}
dwTimeEnd = GetTickCount();
nTime1 = dwTimeEnd - dwTimeStart;
// а теперь распараллелим
SYSTEM_INFO si;
GetSystemInfo(&si);
unsigned nProcNumber = si.dwNumberOfProcessors;
int xChunkWidth = nWidth / nProcNumber;
CHUNK * pChunks = new CHUNK[nProcNumber];
HANDLE* hThread = new HANDLE[nProcNumber];
for ( unsigned i = 0; i < nProcNumber; i++)
{
pChunks[i].nHeight = nHeight;
pChunks[i].xStart = xChunkWidth * i;
pChunks[i].xEnd = xChunkWidth * (i + 1) - 1;
pChunks[i].matrix = matrix;//!
}
pChunks[si.dwNumberOfProcessors - 1].xEnd = nWidth - 1; // спишем на него остаток от деления
dwTimeStart = GetTickCount();
for ( unsigned i = 0; i < nProcNumber; i++)
{
hThread[i] = (HANDLE)_beginthreadex(NULL, 0, ThreadFunc,pChunks +i, 0, NULL);
}
WaitForMultipleObjects(nProcNumber, hThread, TRUE, INFINITE);
dwTimeEnd = GetTickCount();
nTime2 = dwTimeEnd - dwTimeStart;
std::cout << "nTime1 = " << nTime1 << " nTime2 = " << nTime2;
for ( unsigned i = 0; i < nProcNumber; i++)
CloseHandle(hThread[i]);
delete[] pChunks;
delete[] hThread;
delete[] columnSum;
delete[] matrix;
return 0;
}
K>Оптимизация тут вот где. Есть у нас один общий алгоритм для вычисления произведения матриц над кольцом P, где само кольцо передаётся в качестве параметра. При этом кольцо представляет из себя интерфейс. Далее, пишем реализации этого интерфейса для понятий "целые числа", "действительные числа", "выражение". Если бы это компилировали в C++, то на каждое сложение/умножение пришлось бы вызывать виртуальный метод, что не быстро.
Бог с тобой. Это темплейтами вполне делается, без всякой виртуальности.
>В случае с нормальным языком (тот же C#) вызов может заинлайниться. Т.е. он не просто превратится в невиртуальный вызов, а вообще для сложения будет использоваться что-то вроде add eax, abx, тут же, по месту для случая целых чисел.
Именно это и будет.
template <class T > class A
{
private:
T m_t;
public :
A(T t = 0)
{
m_t = t;
}
T operator+(A& a)
{
return m_t + a.m_t;
}
};
// глобальные - чтобы оптимизатор VC++ Release не выкинул весь этот код, как бесполезный. Он это умеет :-)
A<int> i1(10), i2(20), i3;
A<float> f1(10.5f), f2(20.8f), f3;
int _tmain(int argc, _TCHAR* argv[])
{
i3 = i1 + i2;
f3 = f1 + f2;
return 0;
}
Что там инлайнинг — он еще и порядок действий поменял.
K>А вот жизнь такая штука. Зачем по 100 раз писать один и тот же код, если его можно взять у другого, и заниматься решением _своей_ задачи, а не решать сотни других мелких подзадач? Платят же за задачу, а не за написание велосипедов.
Можно. Вот недавно взял. Исходный код работал 5 сек. Теперь у меня работает 1.5 секунды. А надо 200 мсек. Сделаю, теперь уже не сомненваюсь. Вот за это мне и платят
K>Думаю, не стоит недооценивать компиляторы в этом аспекте. Кроме того, у них есть достоинство — они не ошибаются. Точнее, ошибаются, как и всякая программа. Но! На компилятор рано или поздно наложат заплатку, и он не будет ошибаться. Компилятор один раз пишут, а компилируют им миллионы человек миллионы раз. А человек, если ошибся один раз, не факт, что из-за своего невнимания не наступит на те же грабли в другой.
Может, и наступит. Может , и нет. Но вот сделать то, благодаря чему мой код стал работать в 3 раза быстрее — компилятор не сможет. Ручаюсь. Потому что я там отнюдь не на ассемблере оптимизации проводил (и, надеюсь, не придется, хотя я там собираюсь SSE2 применить, но спасибо авторам C++ за intrinsic).
PD>>Оптимизировать задачу "постройте мне автоматически собор святого Петра" — нельзя. Для этого Браманте и Микеланджело нужны. А если эту задачу оптимизировать автоматически, то в итоге получится утепленная собачья будка размером с собор святого Петра.
K>Микеланжело лично клал кирпичи?
При чем здесь это ? Лично ты пишешь программу или руководишь группой программистов, которые пишут — какое это отношение к делу имеет ?
Здравствуйте, Sinclair, Вы писали:
S>Я продолжаю поражаться способностью некоторых людей смотреть в книгу, а видеть известную фигуру из трех пальцев. В том плане, что Рихтер как раз описывает способ минимизировать количество ядерных потоков для реализации асинхронных задач. Простой вопрос на понимание сути: для чего все эти припрыгивания с процедурами завершения, если можно тупо сделать блокирующий вызов в своем потоке?
Подумай сам, может, и поймешь. Хинт — процедура завершения никак не связана с созданием нового потока, она всегда выполняется в контексте потока, который начал эту операцию ввода-вывода. См. ReadFileEx. Хинт 2 — пока операция выполняется в ядре, в потоке, ее иницировавшем, можно успеть что-то сделать, прежде чем заснуть тревожным сном в ожидании вызова процедуры завершения.
Опять пальцем в небо попал
>>>Если бы ты дал себе труд ознакомиться с архитектурой высокопроизводительных приложений, то убедился бы, что никто не выделяет "1 поток — 1 задача".
PD>>Нет такого понятия в Windows — задача. Исключено при переходе Win16->Win32. Если речь идет о процессе, то он здесь ни при чем, так как Windows занимается квантованием времени на уровне потоков, а не процессов. Так что уж, будь добр, определи, что означает слово "задача" в твоем понимании, а тогда и обсудим, сколько потоков должно быть на задачу или задач на поток. Только все же сначала почитай Рихтера. Там эта архитектура подробно рассматривается. S>Задача здесь подразумевается пользовательская. К примеру, "прочитать 8192 байта с диска". Или, более крупно, скажем "обработать входящий http-запрос".
Вот это уже лучше. Насчет http — это не по моей части. А насчет прочитать 8192 байта с диска — зачем, по-твоему, асинхронный ввод/вывод существует ? Ну и читали бы себе последовательно по 8192 байта, так нет, зачем-то придумали асинхронный в/в, с процедурами завершения (а можно и без них, кстати, но все равно асинхронный — с ивентом). Зачем, как ты думаешь ?
S>Очевидное решение — выделить каждое соединение в отдельный поток, чтобы обеспечить максимальный параллелизм. Вот только так никто не делает: слишком велики накладные расходы на управление сотнями потоков, так как они большую часть времени спят. Делают пул в пару десятков потоков на ядро, и его с запасом хватает для всех этих операций. Почитай Рихтера, там это хорошо описано
Именно. Я же тебе и объяснил — почитай его , особенно насчет I/O Completion Port. На нем этот пул и сидит, возможно.
>>>Для распараллеливания ожидания эффективнее кооперативная многозадачность и программный параллелизм. PD>>Привет от Windows 3.11 S>Нет. Привет от файберов, lighttpd и SQL Server. Не стесняйся, Павел, учи матчасть.
Ну-ну. Предложи разработчиками Windows заменить потоки в процессе System на файберы. То-то весело будет
Кстати, маленький вопрос можно ? Соломон-Руссинович (а это классика по внутреннему устройству Windows) потоками посвящают массу страниц, а про файберы — вот все, что у них написано
Fibers allow an application to schedule its own "threads" of execution rather than rely on the priority-based scheduling mechanism built into Windows 2000. Fibers are often called "lightweight" threads, and in terms of scheduling, they're invisible to the kernel because they're implemented in user mode in Kernel32.dll. To use fibers, a call is first made to the Win32 ConvertThreadToFiber function. This function converts the thread to a running fiber. Afterward, the newly converted fiber can create additional fibers with the CreateFiber function. (Each fiber can have its own set of fibers.) Unlike a thread, however, a fiber doesn't begin execution until it's manually selected through a call to the SwitchToFiber function. The new fiber runs until it exits or until it calls SwitchToFiber, again selecting another fiber to run. For more information, see the Platform SDK documentation on fiber functions.
Все.
У Рихтера немного поинтереснее. Выделено мной
Microsoft added fibers to Windows to make it easy to port existing UNIX server applications to Windows. UNIX server applications are single-threaded (by the Windows definition) but can serve multiple clients. In other words, the developers of UNIX applications have created their own threading architecture library, which they use to simulate pure threads. This threading package creates multiple stacks, saves certain CPU registers, and switches among them to service the client requests.
Obviously, to get the best performance, these UNIX applications must be redesigned; the simulated threading library should be replaced with the pure threads offered by Windows. However, this redesign can take several months or longer to complete, so companies are first porting their existing UNIX code to Windows so they can ship something to the Windows market.
...
To help companies port their code more quickly and correctly to Windows, Microsoft added fibers to the operating system. In this chapter, we'll examine the concept of a fiber, the functions that manipulate fibers, and how to take advantage of fibers. Keep in mind, of course, that you should avoid fibers in favor of more properly designed applications that use Windows native threads.
Читать классиков надо. Вдумчиво, не спеша. С толком, с расстановкой.
S>Это, Павел, от того, что твои знания — совершенно бессистемные. Ты не понимаешь, что JIT по отношению к x86 делает c MSIL то же самое, что Pentium делает с x86 кодом по отношению к своему микрокоду. Не понимаешь, что ожидание в www-сервере, файлового ввода-вывода, и таймера устроены совершенно одинаково. И методы везде применяются те же самые.
М-да. Тут уже Рихтер не поможет. Тут надо про организацию файлового ввода/вывода в ядре читать. Про драйверы, про асинхронную модель ввода/вывода в ядре. Про списки ожидания, про потоки. Советую все же Соломона с Руссиновичем почитать, там много об этом. Правда, про www-сервер там ни слова.
S>>>Причем опять же, пространство решений для неё слишком велико, чтобы покрыть его "оптимизированным кодом, написанным на ассемблере". Читать про свитч AXD-301. PD>>Вот уж это читать не буду. У меня других дел хватает, чтобы еще свитчами заниматься. S> Да здравствует упорствующее невежество.
Глупо. Если я не собираюсь читать книги по ненужным мне свитчам — это есть упорствующее невежество
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну зачем же так подставляться. Павел, ИМХО, совершенно сознательно переводит любой разговор на обсуждение тонкостей Win32
Да нет же, честное слово, Андрей!
> а ты ему такой подарок делаешь.
Не заметил. А жаль. ПО-джентльменски не воспользуюсь. А мог бы. Тут есть что сказать.
PD>>>>Компилятор будет в лучшем случае оптимизировать "в среднем", то есть в расчете на некую среднюю задачу. И чем выше уровень абстракций, тем хуже он это будет делать. Оптимизировать цикл можно очень хорошо, а оптимизировать задачу "сделай вот это" — можно лишь на бвзе некоторых правил оптимизации общего порядка. Как только попадется нечто, что под эти правила не подходят — результат будет плохим.G>>>Можно не писать то, что под эти правила не подходит.
PD>>Так я об этом и говорю. Каждому инструменту — свое назначение. Где Linq, где ассемблер. кесарю кесарево, слесарю — слесарево
G>Из всего вышесказанного следует что программа написанная на более высоком уровне лучше поддается оптимизации.
ИМХО следует наоборот. Я же ясно сказал — см. выделенное.
Здравствуйте, gandjustas, Вы писали:
PD>>Да, конечно. Я просто хотел подчеркнуть, что распараллеливание — совсем не такое простое действие. G>Это смотря как писать.
Разумеется
PD>>Иногда и на одном процессоре можно, иногда — не имеет смысла. Иногда и то и другое G>Еще раз: распараллеливание вычислений на одном процессоре только уменьшит быстродействие.
При условии, что ожиданий там нет вообще, то есть загрузка процессора на 100% — верно.
G>Распараллеливание ожидания лучше выполнять не с помощью ручного создания потоков.
Это я не понял. Thread pool ты предлагаешь, что ли ? Если да — это тема для отдельного разговора, скажу лишь, что это зависит от того, что и как ожидать. Если у меня нет массового обслуживания, а есть один рабочий code flow, которому периодически другие дают задания, а он спит и ждет эти задания — на что мне тут пул, зачем мне на него ресурсы тратить ? А в других случаях — пул, да.
Если не о пуле речь — поясни, что имеешь в виду.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
PD>>>>>Компилятор будет в лучшем случае оптимизировать "в среднем", то есть в расчете на некую среднюю задачу. И чем выше уровень абстракций, тем хуже он это будет делать. Оптимизировать цикл можно очень хорошо, а оптимизировать задачу "сделай вот это" — можно лишь на бвзе некоторых правил оптимизации общего порядка. Как только попадется нечто, что под эти правила не подходят — результат будет плохим. G>>>Можно не писать то, что под эти правила не подходит.
PD>>>Так я об этом и говорю. Каждому инструменту — свое назначение. Где Linq, где ассемблер. кесарю кесарево, слесарю — слесарево
G>>Из всего вышесказанного следует что программа написанная на более высоком уровне лучше поддается оптимизации.
PD>ИМХО следует наоборот. Я же ясно сказал — см. выделенное.
Увас с логикой проблемы. Не используем элементы, которые плохо оптимизируются => Получаем более оптимальный код. С другой стороны более высокоуровневые декларативные конструкции оптимизируются гораздо лучше низкоуровневых. Следовательно программа написанная на более высоком уровне лучше поддается оптимизации.
Здравствуйте, Mirrorer, Вы писали:
PD>>Сравнивать же твои результаы с моими бессмысленно — сначала надо о размере окна договориться M>Не могу не согласиться
А если серьезнее — ты делаешь то же самое, разница между скоростью суммирования в C++ и C# здесь скорее всего не проявится (подумаешь, задача — матрицу 500*500 просуммировать) на фоне ожидания в GetPixel. Так что результаты должны быть примерно одинаковы — на одной и той же машине, конечно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Иногда и на одном процессоре можно, иногда — не имеет смысла. Иногда и то и другое G>>Еще раз: распараллеливание вычислений на одном процессоре только уменьшит быстродействие.
PD>При условии, что ожиданий там нет вообще, то есть загрузка процессора на 100% — верно.
G>>Распараллеливание ожидания лучше выполнять не с помощью ручного создания потоков.
PD>Это я не понял. Thread pool ты предлагаешь, что ли ? Если да — это тема для отдельного разговора, скажу лишь, что это зависит от того, что и как ожидать. Если у меня нет массового обслуживания, а есть один рабочий code flow, которому периодически другие дают задания, а он спит и ждет эти задания — на что мне тут пул, зачем мне на него ресурсы тратить ?
Это и есть описание пула. Только с одним потоком, каждое следующее задание ждет завершения предыдущего. Если вруг станет надо обрабатывать задания пока есть свобоные ресурсы, то увеличим количество потоков, например до количества процессоров.
Реализация пула в неуправляемой среде — несложное дело, ресурсов хавает минимум.
PD>А в других случаях — пул, да.
В каких других?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, AndrewVK, Вы писали:
AVK>>welcome to real world
PD>Вот, кстати, про real world. Со мной уже все ясно — проценты я считать не умею, ладно . Но не я один такой. Оказывается, и суммы-то точно считать не умеют, и кто — страшно сказать!
если я не ошибаюсь — примерно пишут потому что есть страницы которые похожи друг на друга, но физически находятся на разных урлах. Гугль видит похожесть и скрывает копии страниц из поиска.
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>welcome to real world
PD>"Этот прекрасный новый мир" (О.Хаксли) не читал ? Кстати, управляемый
Демагогия.
AVK>>Самому не смешно?
PD>Ну тогда зайди в форум по Win32 и объяви во всеуслышание — все, что вы тут делаете — смешно. Потому что там именно такой код и пишут, и мой — не лучше и не хуже. Зайди и напиши, честное слово. Посмотрим на реакцию.
Демагогия.
AVK>>Тогда забудь в этом топике про слово Win32, ты же его через абзац упоминаешь.
PD>А ты готов забыть в этом топике про C#, .Net. LinQ ? Либо уж оба забудем, либо оба нет
Уже два раза объяснял, почему твоя аналогия не годится.
PD>Андрей, мы что-то воду в ступе толчем.
Если пропускать мимо ушей половину того, что я пишу, так и будет.
PD> Не хочешь окна и пикселей — возьми массив двумерный произвольного происхождения с цветами в качестве элементов. Что изменится, кроме ожидания, конечно ?
Ты чего то попутал — у меня с абстрагированием от конкретики проблем нет, это ты все пытаешься на обсуждение Win32 свернуть.
PD>Андрей, ну некорректные же аргументы.
Некорректно, это когда ты упорно пытаешься сменить тему. Сразу скажу — со мной это не пройдет. Обсуждать здесь Win32 я не буду, и не надейся. Речь про функциональное программирование. Не нравится шарп — ОК, давай возьмем ML или Немерле, годится?
PD> Не хочешь Win32 — не надо, но зачем педалировать-то ?
Опять же, не переваливай с больной головы не здоровую. Все что я хочу — чтобы Win32 здесь не обсуждалось.
PD> Там распараллеливание алгоритма, это главное, остальное второстепенное. А про конструкции vs бмблиотеки я уже сказал.
Распараллеливание тоже не главное. Главное — конструкции языка, которые его использование позволяют упростить.
AVK>>А ты SQL не знаешь?
PD>Знаю
Ну вот и ладненько.
PD> А если бы нет ? Вот предстваь себе — пишет некий X математическую обработку, ему SQL совсем не нужен.
А мне этот Х не интересен. Мне интересно реальное положение дел. Как ты думаешь, сколько народу в этом форуме ничего не знают про SQL?
PD> А матрицы по диагоналям он сплошь и рядом проходит — в линейной алгебре диагональных, трехдиагональных и нижне- или верхне- треугольных матриц хоть пруд пруди.
При чем тут матрицы? Нить разговора потерял или специально? Претензии касались не матриц, а Win32.
PD>Прекрасно. Вот на этом месте я и закончу, иначе можно продолжать до бесконечности.
Вобщем понятно, кода так и не будет. Приятно, когда твои предсказания сбываются .
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Microsoft added fibers to Windows to make it easy to port existing UNIX server applications to Windows. UNIX server applications are single-threaded (by the Windows definition) but can serve multiple clients. In other words, the developers of UNIX applications have created their own threading architecture library, which they use to simulate pure threads. This threading package creates multiple stacks, saves certain CPU registers, and switches among them to service the client requests.
О как. Интересно, где это они нашли для UNIX'а такую threading library, и серверные аппликации, на ней написаные, которые имеет смысл "make it easy to port"?
Все-таки по-моему у виндовсных людей UNIX — это такая легенда, типа лешего, который живет (или жил когда-то) в лесу, и про него столько же примерно известно.
Серъезно? Ну-ка, ну-ка, и как же нужно модифицировать этот запрос, чтобы он наворотил тучу SQL запросов? Хочется подтвердить эту небезынтересную гипотезу реальным ахтунг-примером.
