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

Pzz>И не забывайте еще одно. Вот выйдет новый процессор Интел, а мелкософт скажет, что ему не интересно. И не будет его специальным образом поддерживать. Дворкин-то выматерится и руками все соптимизирует. А вы куда пойдете?

Ну зачем же мне материться ? Не в моем это стиле.

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

AF>Я это читал. ...

Это переводит ваш вопрос из категории "невежественные" в категорию "глупые".

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

AF>Ты это у меня спрашиваешь?

Как так, специалист по Немерле, и не знает, как тамошний компилятор устроен? ЕМНИП там есть функциональное RB-tree, неплохо работающее в том числе и в таких сценариях. Опять же — если не страдать пуризмом, то можно использовать классы с изменяемым состоянием, если они хорошо оттестированы, и демонстрируют эту изменяемость в крайне ограниченных пределах.

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

Pzz>А использование SQL-сервера в качестве примера готового продукта не может мирно сосуществовать с использованием его в качестве примера разрабатываемой программы?

Может. В отдельном топике. А вот при обсуждении примера Антона — не может, если ты хочешь придерживаться корректности.

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

Pzz>А если так: для любой программы на языке высокого уровня существует эквиавалентная программа на ассемблере, которая работает не хуже?

А может, проще — для любой программы на языке ВУ существует эквивалентная программа на ассемблере, которая работает так же. Потому что программа на языке ВУ не работает вообще, а работает в конечном счете ассемблерный (машинный) код, порожденный из нее с помощью компиляторов. линкеров и прочих JIT'ов. Вот и возьмем эту эквивалентную программу в машинных кодах. Теперь одно из двух — либо ее нельзя улучшить (когда она уже в кодах), либо можно. Если верно первое — это значит, что компилятор и прочие создали такой код, который является идеальным, его же нельзя улучшить, так ? Из этого утверждения логически следует, что разрабатывать новые версии компилятора по крайней мере для этого процессора незачем, так как существующий компилятор уже создает идеальную программу. Если второе — доказано как минимум то, что существует программа, лучшая, чем создает компилятор. Это не помешает, конечно, улучшить компилятор, но после этого мы опять вернемся к исходной позиции. Вот и все доказательство теоремы.

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

Pzz>Если бы это было никому не нужно, зачем бы в линухе это стали делать?
Писать в обход кеша? нужно, только непонятно какое это имеет отношение к обсуждаемому вопросу.

Pzz>Так же непонятно, с чего речь шла только о венде.
"поверх MS SQL"

Pzz>Кто такие мы?
Это оборот речи такой.

Pzz> могу лишь посоветовать раздвинуть свои горизонты.
Могу посоветовать — не советовать.

Pzz>Вы мне рассказываете, что есть такой слоистый мир, в котором программа на каждом уровне пользуется предыдущим слоем, а что ниже ее не касается.
Нет. Я рассказываю, что есть разные уровни абстракции, и более высокий уровень абстракции в состоянии дать более эффективный результат, чем более низкий. А уж пользуются ли более высокие уровни, нижележащими реализациями, или не пользуются — малосущественные подробности.

Pzz>Я вам привел пример программы, которая живет не так, как принято в рамках этого вашего слоистого мира.
Нет не привел. Не смотря на то, что промышленные СУБД действительно оборудованы возможностю работать с голым диском в обход FS, процент практического использования такого сценария стремится к нулю. Более того, в конкретной обсуждаемой задаче MSSQL работал поверх FS, пользуясь ее публичным API.

Pzz>На что смотреть, простите?
На то что архитектурные особенности сиквела не имеют никакого отношения к обсуждаемому вопросу.

Pzz>И что?
И то. Онточно так же переводит высокоуровневые конструкции ФЯ в низкоуровневый ассемблер.

Pzz>Шансов восстановить, хотя бы частично, сломанную ФС значительно больше, чем восстановить аналогично поломаную БД.
Это заблуждение. БД гораздо более устойчива чем FS и возможности по повышению устойчивости БД тоже существенно больше.

Pzz>Уже потому, что у ФС структура значительно проще.
Ну и что?

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

S>Ключевой момент — вот этот "SetHtml". Общепринятого стандарта на него нету, в отличие от "NavigateTo".
S>Поэтому действительно, самый кроссплатформенный способ — это сделать NavigateTo на соответствующий адрес.
S>В IE применяют специальные трюки для того, чтобы не поднимать честный HTTP-сервер: например, регистрируют свой псевдопротокол.
S>Или пользуются интерфейсом принудительной загрузки из IStream. Но это не кросс-браузерное решение.

В MSIE насколько я помню вообще можно повеситься на событие Navigate и произвольно обрабатывать запросы даже без регистрации всяких псевдо-протоколов.

S>Резюме тут примерно такое: встроить в себя браузер — нетривиальное занятие. А держать локальный HTTP-сервер стоит не слишком дорого.

Может, я, конечно, сужу со своей колокольни, но мне казалось, что тот же Геко — достаточно кроссплатформенное решение. И о возможности встроить его в приложение на подобие MSIE я слышал уже давно — точно не год назад. А какой-нибудь аналог SetHtml там же явно есть.

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

AVK>>Нет.

PD>Ну что же, все ясно.

Смешно. Потрясающий ты человек, Павел Дворкин.

PD> Ответ свой я дал в ответе IT.

Нет, там ты тоже его не дал. Итого — доказать, что ты в императивном стиле напишешь не хуже функционального ты не смог. Вот и весь итог.

PD>Еще раз (на этот раз тебе) объясняю — требовать от меня чего-либо ни ты, ни он не можешь.

Да я и не требую. Только выглядят после этого твои слова, как бы это помягче, неубедительно.

AVK>>Я хочу не кашу из звездочек и стрелочек, а вменяемое описание алгоритма.

PD>Ну насчет каши — не нравится язык — дело твое. Я другой язык использовать не буду.

Кто бы сомневался.

PD> А описание — мне казалось , что я его дал.

Вот именно что казалось.

>>поэтому я просто распараллелил вычисление сумм красных компонент по столбцам окна.

Компонент чего, rакого окна? О чем вообще речь? Сравни свое "описание" с описанием IT. Ну хотя бы по объему. А с таким описанием я тебе могу дать точно такой же ответ:

return things.AsParallel().Select(thing => thing.RedComponent).Sum();

Из комментариев еще можно понять, что у тебя там вроде бы есть еще и непараллельный алгоритм, но AsParallel реально параллелит только если есть несколько ядер. Впрочем, явно указать тоже не проблема:

return (isParallel ? things.AsParallel() : things).Select(thing => thing.RedComponent).Sum();

А теперь сравни со своей простыней. Что там у нас осталось? Параллелить вкривь и вкось различными способами? Все это задается начальными итераторами, теми, которые на вход AsParallel поступают. И тут тоже у шарпа с его итераторами возможностей по понятной и эффективной реализации всяких причудей будет больше, чем ты сможешь на С++ изобразить. Впрочем, это уже не ФП.

PD>Дано окно Windows с неким рисунком в нем. Пройти по всем пиксельным столбцам клиентской области этого окна и найти для каждого столбца сумму R (красных) компонент пикселей , записать результаты в массив columnSum. Две реализации — в лоб без распараллеливания, и с распараллеливанием
PD>Реализация с распараллеливанием — создаются N потоков, где N — число процессоров (возвращает GetSystemInfo). Если процессоров 2, то один поток займется левой половиной окна, а другой правой. Если 3 — левой, средней и правой соответственно. И т.д.

Если это все, тогда в первый вариант вместо things подставляем:

window.Rows.SelectMany(row => row.Values)

Или, если тебе хочется исключительно индексы, то:

Enumerable.Range(0, Width).SelectMany(x => Enumerable.Range(0, Height).Select(y => pixels[x, y]))

Или, используя query comprehension

from x in Enumerable.Range(0, Width)
from y in Enumerable.Range(0, Height)
select pixels[x, y]

Ну и все вместе:

return
    (
        from x in Enumerable.Range(0, Width)
        from y in Enumerable.Range(0, Height)
        select pixels[x, y].Red
    )
    .AsParallel()
    .Sum();

А теперь я поработаю чуток предсказателем — ты все равно не напишешь пример IT в императивной форме.

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

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

Pzz>>А если так: для любой программы на языке высокого уровня существует эквиавалентная программа на ассемблере, которая работает не хуже?

PD>А может, проще — для любой программы на языке ВУ существует эквивалентная программа на ассемблере, которая работает так же.

Я точно так же могу доказать, что для любой программы, написанной на чем угодно, существует программа, составленная из байтов на коленке, или более того, полученная с помощью rnd.Next() (понадобится достаточно большое кол-во попыток), которая работает так же как данная.

Только какая польза от этого утверждения?

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

S>Так ведь это ж не индексер контента — это почтовый сервер. Никого не интересует, что у него унутре — куча файлов, одно хранилище, или несколько.
Не интересует. Но тем не менее, считать любой софт, не использующий MSSQL (или на худой конец Oracle) заведомо тормозным — тоже некорректно.

C>>PostgreSQL и Oracle. Код был самый тупой — проверяем права пользователя (один простой SQL-запрос), делаем запрос в хранилище по ID файла, получаем blob и отдаём по HTTP. Тупее некуда.
S> Логи лайти смотрели? Сколько он отдает 304 Not Modified?
Почти нет совсем. Задача такая.

S>Еще раз повторяю для тех, кто не читает: речь не идет про сравнение винды и линукса. Хочешь поговорить об этом — иди в КСВ и бейся там до упаду. Мы сравниваем "рукопашную" реализацию с "высокоабстрактной".
А я тебе показываю, что разница в скорости между ними зависит, скорее, не от абстрактности, а от прямоты их реализации.

Если я буду запрашивать файлы через web-сервис с кодировкой base64, то это будет ещё более абстрактно. Какая будет скорость у этого счастья — сам понимаешь.

S>Ну, это не совсем то, что доктор прописал. К примеру, gzip компрессию так применить не получится а это может увеличить скорость отдачи (естественно, при использовании кэширования с zero-copy) еще серъезнее, чем просто zero-copy.
Там файлы уже сжатые (сканы документов).

C>>Такое сделать с БД — просто не получится. Если не организовать, конечно, файловый кэш для полученных из БД данных.
S>Смотря какая БД. Вон, команда SQL Server обещает получить производительность линейного чтения blob из БД сравнимой с голой файлухой. А это означает, что буфера db-client можно отдавать прямо в сокет, и результаты будут удивительными
А у меня оно уже без обещаний работает

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

PD>Я предложил свой код и продемонстрировал. Это мое право — предложить код, который я хочу для демонстрации.

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

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

PD>А может, проще — для любой программы на языке ВУ существует эквивалентная программа на ассемблере, которая работает так же. Потому что программа на языке ВУ не работает вообще, а работает в конечном счете ассемблерный (машинный) код, порожденный из нее с помощью компиляторов. линкеров и прочих JIT'ов. Вот и возьмем эту эквивалентную программу в машинных кодах.

В какой момент времени? Она может меняться в процессе выполнения, оптимизироваться с учётом каких-то параметров, зависящих, в частности, от входных данных. Спекулятивный инлайнинг к примеру.

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

PD>А может, проще — для любой программы на языке ВУ существует эквивалентная программа на ассемблере, которая работает так же.

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

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

Pzz>И не забывайте еще одно. Вот выйдет новый процессор Интел, а мелкософт скажет, что ему не интересно. И не будет его специальным образом поддерживать. Дворкин-то выматерится и руками все соптимизирует. А вы куда пойдете?

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

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



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

public partial class Form1 : Form
    {
        [DllImport("user32.dll")]
        static extern IntPtr GetDC(IntPtr hWnd);
        [DllImport("user32.dll")]
        static extern int ReleaseDC(IntPtr hWnd, IntPtr hDC);
        [DllImport("gdi32.dll")]
        static extern int GetPixel(IntPtr hDC, int x, int y);
       
        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
            sw.Start();
            
            var columnSum = new int[this.Width];
            IntPtr hDC = GetDC(this.Handle);
            foreach (var x in Enumerable.Range(0, this.Width))
            {
                int sum = 0;
                foreach (var y in Enumerable.Range(0, this.Height))
                {
                    int colorRef = GetPixel(hDC, x, y);
                    sum += (int)(colorRef & 0x000000FF);
                }
                columnSum[x] = sum;
            }

            ReleaseDC(this.Handle, hDC);
            sw.Stop();
            System.Console.WriteLine(sw.ElapsedMilliseconds.ToString());
        }

Результаты в миллисекундах

478
489
487
492

машинка. Intel 1.73 ГГц

PD>В релизе на моей машине (AMD Dual 4200+)

PD>nTime1 == 2375
PD>nTime2 = 1593

вот. для параллелизации если я правильно понимаю нужно будет вместо

  foreach (var x in Enumerable.Range(0, this.Width))
            {
                int sum = 0;
                foreach (var y in Enumerable.Range(0, this.Height))

написать

  foreach (var x.AsParallel() in Enumerable.Range(0, this.Width))
            {
                int sum = 0;
                foreach (var y.AsParallel in Enumerable.Range(0, this.Height))

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

Pzz>>Если бы это было никому не нужно, зачем бы в линухе это стали делать?
IB>Писать в обход кеша? нужно, только непонятно какое это имеет отношение к обсуждаемому вопросу.

В качестве дидактического примера. Сколько раз вы еще зададите этот вопрос?

Pzz>>Так же непонятно, с чего речь шла только о венде.
IB>"поверх MS SQL"

Мы давно уже отошли от обсуждения, почему одна реализация почтового сервера медленнее другой. Обсуждение MS SQL осталось уже позади, забудьте.

Pzz>>Вы мне рассказываете, что есть такой слоистый мир, в котором программа на каждом уровне пользуется предыдущим слоем, а что ниже ее не касается.
IB>Нет. Я рассказываю, что есть разные уровни абстракции, и более высокий уровень абстракции в состоянии дать более эффективный результат, чем более низкий. А уж пользуются ли более высокие уровни, нижележащими реализациями, или не пользуются — малосущественные подробности.

Программа, написанная с использованием более высокоуровнего API может работать эффективнее, чем программа, написанная с использованием более низкоуровнего API. Это как-бы очевидное утверждение. А может и менее эффективно — смотря как написана

То, что использование более высокоуровнего API всегда и по волшебству дает более эффективный результат — это неверное утверждение. Я вам привел опровергающий пример.

Pzz>>Я вам привел пример программы, которая живет не так, как принято в рамках этого вашего слоистого мира.
IB>Нет не привел. Не смотря на то, что промышленные СУБД действительно оборудованы возможностю работать с голым диском в обход FS, процент практического использования такого сценария стремится к нулю. Более того, в конкретной обсуждаемой задаче MSSQL работал поверх FS, пользуясь ее публичным API.

А я говорю, что привел. Что дальше делать будем?

Pzz>>На что смотреть, простите?
IB>На то что архитектурные особенности сиквела не имеют никакого отношения к обсуждаемому вопросу.

Почему? Мы говорим о философии программирования. Почему бы не говорить об этом на примере SQL-сервера?

Pzz>>Шансов восстановить, хотя бы частично, сломанную ФС значительно больше, чем восстановить аналогично поломаную БД.
IB>Это заблуждение. БД гораздо более устойчива чем FS и возможности по повышению устойчивости БД тоже существенно больше.

Еще одно волшебство.

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

Наверное, в случае смерти файловой системы жившая на нем БД становится ангелом, который потом вселяется в файл назад, после его починки

Pzz>>Уже потому, что у ФС структура значительно проще.
IB>Ну и что?

То, что ее чинить при необходимости проще.

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


PD>1. Напиши аналогичное со свои любимым AsParallel, только не вертикальными полосами, а прямоугольно-гнездовыми кусками. Мне, как понимаешь, это на пять минут работы — массив columnSum превратить в двумерный, а в CHUNK вместо nHeight ввести yStart, yEnd.

по поводу этого. просто foreach поменяется. Будет не для каждого игрека, а для только нужных.

PD>2. То же самое по диагоналям. Каждый тред занимается своей диагональю, параллельной главной (или побочной)
см. пункт 1

PD>3. Сделай так, чтобы некоторые из процессоров не использовались этими потоками. Список этих процессоров дан. Мне это ничего не стоит — SetThreadAffinityMask — и все дела.
если это апишная функция ничего не стоит дернуть ее из це шарпа. хотя может есть более красивое решение хз.

PD>4. Сделай так, чтобы треды работали в фоне, то есть основной поток имел при этом больший приоритет — его работа для меня более важна, чем это суммирование.
приоритеты можно ставть используя класс Thread. Наверное для этого придется отказаться от AsParallel.

PD>5. Ну и напоследок. Сделай так, чтобы эти треды информировали периодически некий третий поток о том, как у них прогресс идет. Для меня тут, конечно, минут на 10 работы — еще один поток надо сделать, причем с петлей сообщений а потом просто PostThreadMessage когда надо.
см.пункт 4

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

PD>Вот и все доказательство теоремы.
Вот и все опровержение: http://zabivator.livejournal.com/290293.html?format=light

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

Pzz>Мы давно уже отошли от обсуждения, почему одна реализация почтового сервера медленнее другой. Обсуждение MS SQL осталось уже позади, забудьте.

Мне кажется, это только ты постоянно пытаешься соскочить с темы. А вот твои собеседники все таки говорят все о том же.

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

S>Ключевой момент — вот этот "SetHtml". Общепринятого стандарта на него нету, в отличие от "NavigateTo".
S>Поэтому действительно, самый кроссплатформенный способ — это сделать NavigateTo на соответствующий адрес.
S>В IE применяют специальные трюки для того, чтобы не поднимать честный HTTP-сервер: например, регистрируют свой псевдопротокол.
S>Или пользуются интерфейсом принудительной загрузки из IStream. Но это не кросс-браузерное решение.

S>Резюме тут примерно такое: встроить в себя браузер — нетривиальное занятие. А держать локальный HTTP-сервер стоит не слишком дорого.

Тем более, что и МС не гнушаются делать хелп в виде ASP.NET приложений. У них, правда, причины другие, но факт остается фактом.