Мнения разделились примерно поровну . Кроме того, меня несколько удивила низная активность. Подозреваю, что многие ответили бы "не знаю", если бы я такой вариант ответа предусмотрел.
Но тем не менее даже ныненшние результаты говорят о том, что тенденция есть. Если бы я такое голосование устроил 5 лет назад, результат был бы, скорее всего, 100:0.
Если вы согласны с тем, что замедление имеет место, то хотелось бы обсудить вопрос —
К каким последствиям оно приведет, если тенденция не изменится.
Подчеркиваю специально. Если она изменится — разговор иной. Я бы не хотел, чтобы начался разговор на тему — "а вот скоро появится память на кварках и процессоры на нейтрино, и уж тогда..."
В частности, как считают уважаемые коллеги — приведет ли это к приоритету интенсивного пути использования в противовес тому экстенсивному, который мы наблюдаем последние годы (ресурсов много, чего их жалеть, бери больше, аппаратура все спишет) ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В частности, как считают уважаемые коллеги — приведет ли это к приоритету интенсивного пути использования в противовес тому экстенсивному, который мы наблюдаем последние годы (ресурсов много, чего их жалеть, бери больше, аппаратура все спишет) ?
Замедление, безусловно, есть. Приведет оно, скорее всего, к распространению языков специально спроектированных для многопроцессорных машин (типа Erlang и других основанных не на древней mutex-ориентированной идеологии, а на передаче сообщений). Поскольку процессоров обещают много, то становится не так важно, насколько эффективно используется один процессор, сколько насколько эффективно используются несколько. На языках старого типа, как известно, программирование мультитредовых приложений крайне геморойно и сложно. Специализированные языки уменьшают количество ошибок связанных с синхронизацией (хотя бы тем, что запрещают прямой доступ к данным из нескольких нитей) и предлагают приятный синтаксический сахар для быстрого (в коде) создания потока, передачи сообщения, ожидания и т.п.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В частности, как считают уважаемые коллеги — приведет ли это к приоритету интенсивного пути использования в противовес тому экстенсивному, который мы наблюдаем последние годы (ресурсов много, чего их жалеть, бери больше, аппаратура все спишет) ?
Не приведет. В опросе явно сказано — пользовательские компьютеры. Надо провести еще один опрос — Как вы считаете, заменили ли сетьевые решения однопользовательские (такие как параллельные базы данных, remouting, веб службы, intranet/internet системы)? А потом в зависимости от вариации ответов на этот вопрос уже и плясать. А кластеры нынче в моде, не хватает производительности сервера — заменим его на 2 таких же.
Лет 5-7 назад 4 уровневая система была в диковинку, писали 2х или 3х уровневые системы. Сейчас же создать 3 уровневую систему — проявить неуважение к своим архитекторским способностям :-D А как вы понимаете — многоуровневые системы гораздо лучше масштабируются.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мнения разделились примерно поровну . Кроме того, меня несколько удивила низная активность. Подозреваю, что многие ответили бы "не знаю", если бы я такой вариант ответа предусмотрел.
Кстати очень грамотный ответ. Само голосование я пропустил, только сейчас увидел, но не суть.
Про всех не расскажу, про себя скажу.
Я помню в школе, в универе, я постоянно знал, что мой компьютер недостаточно быстрый, постоянно находились программы, которые тормозили. Игрушки — о да, они лидеры. Но не только. Ворд медленно работал, студия тоже была не шустрой. Постоянно хотелось что-то обновить... То и дело замечал что "эта программа тормозит, надо комп менять, а пока найти что-то поффективнее".
А сейчас я действительно не знаю чем характеризуются новые процессоры и материнки... Все программы с которыми я работаю (тут еще плюс что на игрушки мало времени ) — работают достаточно быстро для меня. Поэтому я уже давно не интересуюсь что там выходит и куда. Потому как не вижу смысла.
Я только винтами иногда интересуюсь — вот когда программа работает с большими объемами данных — я наблюдаю медлительность.
Ужасающее зрелище — комп тормозит, а процессор загружен на 15%
Но в них прогресс всегда шел медленно
так что я бы ответил "Не знаю, да и не интересно сейчас".
PD>В частности, как считают уважаемые коллеги — приведет ли это к приоритету интенсивного пути использования в противовес тому экстенсивному, который мы наблюдаем последние годы (ресурсов много, чего их жалеть, бери больше, аппаратура все спишет) ?
До тех пор, пока аппаратура будет списывать, будут полагаться на это. Когда не будет списывать — будут оптимизировать узкие места. Оно и сейчас так, на самом деле
Все должно определяться пользой. Просто так "интенсивный подход" внедрять никто не будет. Будет нужно для того, чтобы продавать ПО — внедрят автоматически. Прыгать выше головы впереди паровоза никто не будет
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Pavel Dvorkin, Вы писали:
У мееня одно замечание насчет многопоточности.
Многие годы у меня была однопроцессорная машина. Сейчас — Athlon Dual 3800+, уже месяца 3. Так вот — реально второй процессор простаивает. Специально наблюдал — более 50% загрузки по Task Manager не бывает практически. Приложения — самые обычные, ничего экзотического. Хотя те же Eclipse и DevStudio могли бы уж как самое передовое звено использовать два процессора, да и Windows могла бы сама распараллелить. Но реально этого не происходит.
А причина простая. Действия сами по себе у меня редко распараллеливаемые. Если бы счет какой-то нужно было устроить — я бы в своей программе постарался уж бы. А в интерактивных действиях я сам однопоточен. Переключился на DevStudio, поредактировал что-то там, откомпилировал, переключился на IE, зашел на rsdn и т.д. То есть чаще всего нагрузка на процессор, естественно, 0%, а иногда она поднимается до... вот именно, 50%. Вот тут и хотелось бы, чтобы именно это действие (загружающее на 50%) выполнилось как можно быстрее. А чтобы два таких действия были одновременно — просто не бывает.
Конечно, здесь можно мне возразить, не надо это делать, я сам все возражения вижу и понимаю. И все же практика десктопных компьютеров большей частью ИМХО такова, что реально имеет место однопроцессорность. В силу просто специфики человеческой деятельности.
(Разумеется, о серверах я не говорю).
Этот самый Athlon Dual Core 3800+ Windows показывает как 2.01 GHz (т.е 3800 имеется в виду на оба процессора) Я, пожалуй, променял бы его на однопроцессорную машину с 3.8 GHz на одном процессоре . Нет, не то чтобы очень тормозит, но все же порой хотелось бы быстрее — особенно когда я вижу 50% загрузки...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>У мееня одно замечание насчет многопоточности.
PD>Многие годы у меня была однопроцессорная машина. Сейчас — Athlon Dual 3800+, уже месяца 3. Так вот — реально второй процессор простаивает. Специально наблюдал — более 50% загрузки по Task Manager не бывает практически. Приложения — самые обычные, ничего экзотического. Хотя те же Eclipse и DevStudio могли бы уж как самое передовое звено использовать два процессора, да и Windows могла бы сама распараллелить. Но реально этого не происходит.
Ну вот Quintanar и говорил насчет возможного развития языков, которые будут поддерживать распараллеливание автоматически. Сейчас подавляющее большинство десктопных приложений не может выполняться параллельно. Потому что они рассчитаны на работу на одном процессоре. Сейчас разрабатывать десктопное приложение, которое бы поддерживало эффективное распараллеливание экономически совершенно невыгодно — в императивных языках для этого нужно прикладывать много усилий, а выигрыш пока что незначителен.
Если дальше будет развиваться многопроцессорность на десктопах, то возможен всплеск популярности функциональных языков, которые позволяют писать распараллеливаемые программы без лишних усилий. Что в свою очередь приведет к еще большему всплеску популярности многопроцессорных систем, поскольку они будут давать реальное усиление производительности, а не максимум 50% нагрузки Такое взаимоусиление выйдет.
Но это только возможность.
Зависит от того, что и как делать.
Я вот рад, что наконец пересел на 2-х ядерный процессор.
При компиляции (С++) наконец то могу еще что-то делать, а не просто тупо наблюдать за процессом.
С установленным на несколько машин incredibuild вообще одно удовольствие компилировать.
Еще я могу запустить на пару часов юнит тест, и продолжать спокойно работать дальше.
Раньше такой сценарий для меня лично был маловероятен.
Буду рад, если у меня появится 4 ядра и больше...
Другой пример.
Голосовой ввод явно выиграет от многоядерности.
Та, система, которую мы разрабатываем, запросто может выиграть (и уже реально выигрывает) от многопоточности.
Кстати, твои слова напомнили мне аргументы одного моего знакомого.
Как только стала распространяться винда, он говорил, что ему это нафиг не нужно.
Не нужны ему были куча окон, открытых одновременно.
Ему нужно чтобы каждая задача, которую он запускал, работала как можно быстрее.
Типа он все равно работает последовательно, а не одновременно с несколькими программами.
Интересно, что бы он сказал сейчас в ответ на те свои слова 15 лет тому назад.
Я вот сижу сейчас за 2-мя мониторами и не чувствую, что окон слишком много
С многоядерностью случится то же самое.
Им обязательно найдутся разумные применения.
Здравствуйте, fmiracle, Вы писали:
F>Если дальше будет развиваться многопроцессорность на десктопах, то возможен всплеск популярности функциональных языков, которые позволяют писать распараллеливаемые программы без лишних усилий.
Думаю скорее идеи из функциональных языков будут адаптироваться в мейнстрим языки (см. C# 3.0, STM, LINQ, в Java собираются добавить замыкания), а ФЯ, возможно, будут шире использоваться в каких-то определённых нишах (как Erlang).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кроме того, меня несколько удивила низная активность.
Тут влияют два фатора:
1. Вопрос мало интересный.
2. В голосовании нет возможности добавить свой вариант. Многие могут иметь другое мненение не вписывающееся в строгое "да" или "нет". Так что на будущее оставляй возможность добавлять свои ответы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, bkat, Вы писали:
B>При компиляции (С++) наконец то могу еще что-то делать, а не просто тупо наблюдать за процессом. B>С установленным на несколько машин incredibuild вообще одно удовольствие компилировать.
Однако если бы перехал с С++, то мог бы просто не ждать пока идет компиляция.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Простой вопрос — можно ли заметить изменение производительносии компа пользуясь только вордом и редактируя в нем небольшие документы?
Объем памяти до 128 мег различим. Процессор до 3-его Пня. Если документы большие, то они до сих пор тормозят. Плюс, например, наш макрос для конвертации ворда в РСДН-МЛ тормозит на больших статья вне зависимости от процессора .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, bkat, Вы писали:
B>>При компиляции (С++) наконец то могу еще что-то делать, а не просто тупо наблюдать за процессом. B>>С установленным на несколько машин incredibuild вообще одно удовольствие компилировать.
VD>Однако если бы перехал с С++, то мог бы просто не ждать пока идет компиляция.
Уже частично переезжаем.
Все равно на одноядренный процессор не пересяду
Здравствуйте, AndrewVK, Вы писали:
AVK>Простой вопрос — можно ли заметить изменение производительносии компа пользуясь только вордом и редактируя в нем небольшие документы?
Простой ответ — на прежней моей машине (p4-1600) в Worde прорисовка картинок (и таблиц) шла исключительно медленно. Причина, правда, не в процессоре, а (по видимому) видеокарте и древнем ее драйвере (по некоторым причинам не мог использовать более новый). На новой машине все нормально.
Здравствуйте, bkat, Вы писали:
B>Зависит от того, что и как делать. B>Я вот рад, что наконец пересел на 2-х ядерный процессор. B>При компиляции (С++) наконец то могу еще что-то делать, а не просто тупо наблюдать за процессом.
+1.
B>Другой пример. B>Голосовой ввод явно выиграет от многоядерности.
B>Кстати, твои слова напомнили мне аргументы одного моего знакомого. B>Как только стала распространяться винда, он говорил, что ему это нафиг не нужно. B>Не нужны ему были куча окон, открытых одновременно. B>Ему нужно чтобы каждая задача, которую он запускал, работала как можно быстрее. B>Типа он все равно работает последовательно, а не одновременно с несколькими программами.
Эти аргументы я помню. Но акцент здесьнемного не тот. Аргументировали так — мне не нужна многопрограммность, яделаю все последовательно. И это аргумент не утратил силы — в основном я действительно делаю последовательно. Удобство многопрограммных сред во многом не в том, что можно делать параллельно, а в том, что не надо закрывать одно приложение, чтобы переключиться на другое. Это утверждение, конечно, не есть истина, можно много привести контраргументов, но определенный момент истины в нем присутствует.
B>Интересно, что бы он сказал сейчас в ответ на те свои слова 15 лет тому назад. B>Я вот сижу сейчас за 2-мя мониторами и не чувствую, что окон слишком много
А вот это совсем другой разговор. Я бы, пожалуй, тоже не отказался от монитора площадью в квадратный метр
B>С многоядерностью случится то же самое. B>Им обязательно найдутся разумные применения.
Непременно найдутся. Вопрос не в этом. Лично мне не нужны приложения, которые загружают N процессоров эффективно. Мне нужно, чтобы те приложения, которые мне нужны, работали максимально эффективно. В конце концов рендеринг сцены в играх уж точно можно распараллелить, так что на 16-ядерном компьютере игры , может быть,будут просто летать,и это очень хорошо. Но я не брошу свои дела и не пересяду на Quake-16
И кстати, еще одно замечание. Распараллеливание потоков разных процессов возможно всегда. Но вот что касается отдельного приложения, то далеко не всегда можно его распараллелить. Алгоритм просто не всегда позволит. И никакие языки тут не помогут.
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Не приведет. В опросе явно сказано — пользовательские компьютеры. Надо провести еще один опрос — Как вы считаете, заменили ли сетьевые решения однопользовательские (такие как параллельные базы данных, remouting, веб службы, intranet/internet системы)?
Автору идеи — карты в руки. Устрой. Потом обсудим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Кроме того, меня несколько удивила низная активность.
VD>Тут влияют два фатора: VD>1. Вопрос мало интересный.
Сомнительно.
VD>2. В голосовании нет возможности добавить свой вариант. Многие могут иметь другое мненение не вписывающееся в строгое "да" или "нет". Так что на будущее оставляй возможность добавлять свои ответы.
+1. Но сделал не случайно — мне нужен был ответ "да" или "нет". Другое дело — надо было предусмотреть вариант "затрудняюсь ответить"
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>+1. Но сделал не случайно — мне нужен был ответ "да" или "нет". Другое дело — надо было предусмотреть вариант "затрудняюсь ответить"
Тебе нужен не значит что нужен остальным. У остальных может быть другое мнение о котором ты даже не подозреваешь. Когда человек видит закрытый список варинато и он имеет дополнительное менение, то он просто не голосует.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
AAV>>Не приведет. В опросе явно сказано — пользовательские компьютеры. Надо провести еще один опрос — Как вы считаете, заменили ли сетьевые решения однопользовательские (такие как параллельные базы данных, remouting, веб службы, intranet/internet системы)?
PD>Автору идеи — карты в руки. Устрой. Потом обсудим.
