Позитивчик. В MSFT ведущие программисты сами себе засчитывают слив

>И, да, линакс у меня не тормозит ни на одном ядре, ни на полутора (одно с HT), ни на четырех
Сейчас припомнят тот самый баг: http://bugzilla.kernel.org/show_bug.cgi?id=12309

12309 тебе поможет

А он есть :(

В линуксах с этим вообще швах, лучше даже не начитать. Чего стоит только один пихаемый везде и всюду пайфон с его GIL. После этого Windows 7 просто сгусток скорости

Лучше бы ты это запостил http://news.slashdot.org/story/10/03/21/1731200

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

И только в 2010 году они говорят: блджад, наша система тормозит на 8 ядрах! Надо менять подходы, епрст!

Не, ну могли и не говорить.

Могли бы и не говорить, это уже все давно осознали.

А он есть :(

в отличие от M$, наши этот баг не признают ))))

> В линуксах с этим вообще швах, лучше даже не начитать.

Да что ты говоришь :)

>>В линуксах с этим вообще швах, лучше даже не начитать.
А чуваки, которые линукс используют на супер-компьютерах, и не в курсе....

> Сейчас припомнят тот самый баг:

Так это управление процессами, а то — система ввода-вывода и система управления виртуальной памятью, они же ж разные.

Интересно другое, что именно МS больше всех и пиарил эту ущербную модель все это время. А вот теперь они одумались наконец-то, когда уже сделали свое черное дело

Это называется "Огонь и движение". MS всегда этим занималась и занимается. Разве для кого-то есть тут скрытый смысл?

Это называется «Огонь и движение».

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

Разве для кого-то есть тут скрытый смысл?

А насчет потоков - скрытый смысл как раз был, ну может даже и не скрытый, а явный. Просто в венде нет форка, и запуск процесса тормознутый, вот они и выдумали потоки, чтоб удобнее кодерам было себе в ногу стрелять. И долго пиарили, как лучшую модель по сравнению с нормальной юниксовой моделью с процессами. Кодеры повелись на пиар, а теперь вон прямо в этом треде кричат про GIL в питоне, вместо того, чтоб задуматься - а зачем вообще потоки в питоне, в простом скриптовом языке для обучения.

в простом скриптовом языке для обучения.

Тонко!

Тонко!

Это случайно получилось :-). Мне вобщем-то все равно, что там в этом питоне, но интересно, что Гвидо курил, когда потоки добавлял. Хотя он голландец, ему можно. Главное, что в js этого бреда не будет, потому что в америке вещества запрещены, и Брендан очень хорошо понимает, что такое потоки http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html.

>> Сейчас припомнят тот самый баг: http://bugzilla.kernel.org/show_bug.cgi?id=12309

черт, я думал его зарезолвили, а там insufficient data

>Сейчас припомнят тот самый баг: http://bugzilla.kernel.org/show_bug.cgi?id=12309

Забавно но в винде он тоже проявляется))

Все правильно говорят, в модели многопоточности с разделением памяти написать что-то неглючащее и нетормозное - очень нетривиальная задача.

Как я понимаю поиски альтернатив уже некоторое время ведутся.

Взять хоть эту статью:

January 10, 2006 by Edward A. Lee The Problem with Threads

Вот что говорит Edward A. Lee в выводах своего отчета:

Concurrency in software is difficult. However, much of this difficulty is a consequence of the abstractions for concurrency that we have chosen to use. The dominant one in use today for general-purpose computing is threads. But non-trivial multi-threaded programs are incomprehensible to humans. It is true that the programming model can be improved through the use of design patterns, better granularity of atomicity (e.g. transactions), improved languages, and formal methods. However, these techniques merely chip away at the unnecessarily enormous nondeterminism of the threading model. The model remains intrinsically intractable.

If we expect concurrent programming to be mainstream, and if we demand reliability and predictability from programs, then we must discard threads as a programming model (выделение мое). Concurrent programming models can be constructed that are much more predictable and understandable that threads. They are base on a very simple principle: deterministic ends should be accomplished with deterministic means. Nondeterminism should be judiciously and carefully introduced where needed, and should be explicit in programs. This principle seems obvious, yet it is non accomplished by threads. Threads must be relegated to the engine room of computing, to be suffered only by expert technology providers.