Собственно, да. Я больше одного раза видел в договорах с провайдерами пункт о том, что за весь входящий трафик ответственность несет подписант договора.
(а) почему бы и не гонять? его стоимость на правильной базе невелика.
(б) если оказывается, что стоимость велика, можно кэшировать сабсет данных по поиску целиком, и в памяти делать выборки по нему.
Очень легко можно оценивать — вот представьте себе, что у компании есть крупная бизнес-библиотека, написанная на язык XYZ. Язык XYZ не является с/с++ и не вызывается из с/с++.
Логично же, что выбирая платформу для новых разработок, которая должна реализовывать ту же бизнес-функциональность, компания будет выбирать такой язык, который позволит reuse XYZ-библиотеки?
Просто библиотеками c/c++ жизнь не ограничивается.
Одна из вещей, которой учит Казман в курсе оценки архитектуры — собственно, важнейшая вещь — это понимание того, что любое решение есть компромис. Выбор платформы — это тоже компромис, плюсы и минусы которого надо осознавать.
И да.
Архитектурные решения принимаются на каждом уровне — включая микроуровень.
Да, язык выбирают по тому, с какими библиотеками (в том числе — написанными не на этом языке) он может использовать. Для того, чтобы упростить code reuse и сэкономить на разработке.
1) А вот зря. Иначе бы вы понимали, что c# — это одна вещь, а GC — другая. И если c# означает GC, обратное — неверно. И, как следствие, не приводили бы примеров, вызывающих столько дискуссий.
А отсюда и вывод: вот изучать параллельные вычисления — хорошо. Это полезно, это сейчас актуально и так далее. А вот изучать конкретный язык и средство, которые реализуют параллельность — например, Intel Parallel Studio — это, по большому счету, прямо обратно смыслу вашей статьи.
Все старое когда-то было новым. Ну и да, оно тоже не на пустом месте растет.
И еще, про трудность отладки. Parallel Studio встраивается в VS… а поддержка Parallel Tasks из .net 4 в студии есть «из коробки». Включая отладку и визуализацию.
Во-первых, вы продолжаете путать язык и технологию.
А во-вторых, сложность реализации проекта зависит от используемых технологий. Скажем, разница в «написать клиент-серверный транспорт самим» и «взять готовую реализацию» — человекомесяцы (если не годы). Вся ценность любой платформы разработки в том, что она позволяет разработчику думать о конкретных проблемах бизнес-приложения, а не о решении типовых задач класса «как мне написать кэш».
«Будет одинаково» — значит, выбор будет по прочим возможностям инструмента, языка и платформы.
В .net есть свои достоинства, оправдывающие его выбор при сравнении с другими языками. Соответственно, Parallel возвращает нам паритет средств разработки, давая нам возможности (легко) работать с параллельными вычислениями там, где они уже работают по каким-то другим причинам.
Так что не надо раз за разом переводить стрелки на Intel. На Parallel Studio свет клином не сошелся.
Using — всего лишь средство автоматически вызвать dispose. Понятно, что лучше его использовать (равно как и lock вместо явных вызовов Monitor), но это не всегда возможно.
«Просто мало еще кто понимает, что параллельность в программах намного важней, чем например красота языка и прочее. „
Вы, наверное, не в курсе, что в “новомодном» .net 4 есть отдельное пространство имен для упрощения работы с параллельными вычислениями?
Сколько на .net (кстати, шарп тут не при чем, сбор мусора — прикол CLR) не писал, никогда такого не видел — чтобы из-за GC тормозил интерфейс. Понятно, что телепатически проблему не диагностируешь, но скорее всего — ошибка архитектуры.
В частности, тот факт, что память управляется сборщиком, еще не означает, что не надо делать Dispose там, где он есть.
Просто надо отдавать себе отчет, что чудес — не бывает. Любое архитектурное решение — всегда компромис, выигрыш в чем-то за счет чего-то другого. Здесь, очевидно, выигрыш в производительности за счет надежности.
(б) если оказывается, что стоимость велика, можно кэшировать сабсет данных по поиску целиком, и в памяти делать выборки по нему.
Поэтому я и писал выше: «язык выбирают по тому, какие библиотеки (в том числе — написанные не на этом языке) он может использовать».
Обратите внимание на скобки.
Логично же, что выбирая платформу для новых разработок, которая должна реализовывать ту же бизнес-функциональность, компания будет выбирать такой язык, который позволит reuse XYZ-библиотеки?
Просто библиотеками c/c++ жизнь не ограничивается.
Одна из вещей, которой учит Казман в курсе оценки архитектуры — собственно, важнейшая вещь — это понимание того, что любое решение есть компромис. Выбор платформы — это тоже компромис, плюсы и минусы которого надо осознавать.
И да.
Архитектурные решения принимаются на каждом уровне — включая микроуровень.
Чего вы в этом не понимаете?
А отсюда и вывод: вот изучать параллельные вычисления — хорошо. Это полезно, это сейчас актуально и так далее. А вот изучать конкретный язык и средство, которые реализуют параллельность — например, Intel Parallel Studio — это, по большому счету, прямо обратно смыслу вашей статьи.
2) А что вы предлагаете?
И еще, про трудность отладки. Parallel Studio встраивается в VS… а поддержка Parallel Tasks из .net 4 в студии есть «из коробки». Включая отладку и визуализацию.
А во-вторых, сложность реализации проекта зависит от используемых технологий. Скажем, разница в «написать клиент-серверный транспорт самим» и «взять готовую реализацию» — человекомесяцы (если не годы). Вся ценность любой платформы разработки в том, что она позволяет разработчику думать о конкретных проблемах бизнес-приложения, а не о решении типовых задач класса «как мне написать кэш».
В .net есть свои достоинства, оправдывающие его выбор при сравнении с другими языками. Соответственно, Parallel возвращает нам паритет средств разработки, давая нам возможности (легко) работать с параллельными вычислениями там, где они уже работают по каким-то другим причинам.
Так что не надо раз за разом переводить стрелки на Intel. На Parallel Studio свет клином не сошелся.
Вы, наверное, не в курсе, что в “новомодном» .net 4 есть отдельное пространство имен для упрощения работы с параллельными вычислениями?
Сколько на .net (кстати, шарп тут не при чем, сбор мусора — прикол CLR) не писал, никогда такого не видел — чтобы из-за GC тормозил интерфейс. Понятно, что телепатически проблему не диагностируешь, но скорее всего — ошибка архитектуры.
В частности, тот факт, что память управляется сборщиком, еще не означает, что не надо делать Dispose там, где он есть.
Просто надо отдавать себе отчет, что чудес — не бывает. Любое архитектурное решение — всегда компромис, выигрыш в чем-то за счет чего-то другого. Здесь, очевидно, выигрыш в производительности за счет надежности.
А что вы хотите от пояснительной записки диплома?
Вообще, автору на заметку: научная работа и статья на хабре — это два разных жанра.