gpu user benchmark с вами не согласен. Intel HD 630 не дотягивает даже до GTS 450 (+20%), и существенно отстает даже от дешевых GTX 460 SE (+65%) плат, в то время как референс GTX 460 (+93%) вообще кажется чем-то недостижимым.
Но даже в случае офисного компьютера по любому лучше запихнуть какую-нибудь старинную GF8800
У нас около 850 ПК.
Найдите GF8800 хотя бы для 1% из них )
Но самое главное — в этом нет никакого смысла, так как GF8800GT — это уровень встроенных видео HD Graphics 4200, 4400, 4600, P4600 и P4700 — уровень 2013 года.
Но ПК из Эльдорадо конечно плохой пример, разве не так? Я бы сказал, очень, очень плохой.
Ну, вам не угодить. Сейчас люди предпочитают ноуты и планшеты, в которых другой графики, кроме встроенной вообще нет.
Я с 2005 года не встречал бюджетно-офисных компьютеров с отдельной видеокартой.
Офисных. Бюджетных полным полно. Но даже в случае офисного компьютера по любому лучше запихнуть какую-нибудь старинную GF8800, чем сидеть на встроенной графике. Ведь это так или иначе нагрузка на кристалл, а умрет GF8800 ее не жалко.
Когда появились магазины электроники — большая часть ПК «для дома» в них имела низкую цену и встроенную графику.
Но ПК из Эльдорадо конечно плохой пример, разве не так? Я бы сказал, очень, очень плохой.
Их низкая популярность обусловлена низкой производительностью.
Я с 2005 года не встречал бюджетно-офисных компьютеров с отдельной видеокартой.
А их только в нашей организации сотни.
Когда появились магазины электроники — большая часть ПК «для дома» в них имела низкую цену и встроенную графику.
Недорогие видеокарты сейчас берут, в основном, на замену вышедшим из строя, или слишком «горячим» видеокартам в старых компьютерах.
А что их замечать-то?
1 Встроенные видеоядра широко предлагаются покупателям с 2010 года и даже раньше (встроенные в чипсет были). Но популярности они никогда не имели. Почему?
2 Их низкая популярность обусловлена низкой производительностью. Видеоядра нужны не для игр, а для обработки и отображения 2d. В 3d режиме тягаться с видеокартами они не могут.
3 Следовательно встроенные видеоядра не составляют конкуренции видеокартам и на их рынок влияния оказывать не могут.
Странно, что этот факт не влияет на рассуждения автора
Ой. Автор не заметил процесс вытеснения недорогого ценового сегмента видеокарт — встроенными в процессор решениями, а вы требуете внимания к криптовалютам )
7 Особого беспокойства будут заслуживать цены на сильные и средне-сильные видеокарты. Т.к. NVIDIA уже давно вышла на плато, можно ожидать очередного скачка цен на вышеозначенные видеокарты в новом поколении, или в следующем. Как бы то ни было, скачок цен на топы не за горами.
Хуанг уже давно озвучил и повторил, что след.поколение 100% будет дороже, из-за дорогих НИОКР и неудержимого роста цен на оперативную память.
И дороже будет всё, не только топы.
Анодирование слабо отличается от краски, поясню. Анодированный алюминий отличается от обычного значительно увеличенной по толщине оксидной пленкой. Т.к. пленка весьма пористая, она очень легко подвергается пропиткам красителями, отсюда и приятное глазу разнообразие цветов. Кажется, что оксидированный алюминий лучше краски, но тут не учитывается уменьшение теплопроводности и электропроводности за счет пленки, а оно очень значительное. Я давно хотел заменить силиконовые прокладки на пластины оксидированного алюминия, но когда увидел повышение сопротивления после оксидирования то решил отложить это дело на будущее — повышение сопротивления это хорошо, это отлично, но вместе с ним точно так же падает и теплопроводность т.к. они находятся рядом. Да и странно было бы ожидать хорошей теплопроводности от слоя довольно пористого Al2O3.
В возможности добавить реализацию и состояние не ломая иерархию, очевидно.
Интерфейс — это синтетическая сущность, которая переваливает проблемы ромба с «головы» компилятора на программиста.
— Правда? А что такое интерфейс? Это то же самое что и класс?
— Ну… Не совсем!
— В каком плане? — Не один из его методов не должен иметь реализации.
Очень уж мне не нравится это определение интерфейса. Лично для себя сформулировал, что интерфейс — это описание контракта, и это не класс со всеми методами без реализаций. Это разные сущности, в том-же C# можно явно реализовать интерфейс, попробуйте сделать то же самое с абстрактным классом.
Народ, если у вас есть мнение, то, пожалуйста, выразите его словами.
Человек, для которого ООП сводится к наследованию ("Не пользуйтесь ООП в ООП") — настолько далёк от понимания предмета, что нет смысла даже тратить время на объяснения — просто ставишь минус и идёшь дальше.
Интерфейсы это ваш контракт. Это ваш api, если хотите.
Не люблю интерфейсы как раз потому, что они очень грубо описывают контракт. То есть вроде есть контракт, но в то же время он очень-очень общий. С одной стороны, вроде лучше чем ничего, а, с другой, иной раз тратишь много времени на оформление такого контракта, а толку мало: соблюдая его на уровне синтаксиса языка, имплементации полностью рушат все даже задокументированные пред- и постусловия с инвариантами.
Если у вас есть класс, который реализует так много интерфейсов, то проблема возникла раньше.
Идеальную чистоту интерфейсов можно содержать только в полностью контролируемой кодовой базе, то есть примерно никогда. Во всех остальных случаях интерфейсы плодятся как кролики, потому что они не версионируемые, они в принципе не поддерживают совместимость назад.
В результате в COM мы имеем наследование от IContextMenu1, IContextMenu2, IContextMenu3, IContextMenu4, а в C# имеем ICollection, IReadOnlyCollection, IReadOnlyList (причины разные, результаты разные, но последствия всегда неприятные). И вот никуда от этого не деться. Ну не задизайнить интерфейсы так, чтобы один раз и на всю жизнь.
Интерфейсы это ваш контракт. Это ваш api, если хотите. И если контракт меняется, значит на то была причина — изменилось требуемое поведение.
Ну вот допустим в C# был бы не класс FileStream, а интерфейс IFileStream. Теперь мы хотим добавить поддержку асинхронного чтения. Ваши действия? Добавить новый интерфейс? Расширить существующий? Любое решение с интерфейсами (без default interface implementation) будет неудобным для потребителя.
С композицией надо проверить только там, где изменилось.
Идеализирование. Реализация всего может поменяться в любой момент несовместимым способом. Ломается всё, независимо от архитектуры, поэтому всё равно вы всё будете тестировать, если хотите спокойно спать по ночам.
"Не пользуйтесь ООП в ООП"? Ну круто, теперь заживём.
ООП это не только наследование. Я не призываю отказываться от наследования совсем, но мой подход чем реже, тем лучше.
А если писать код как попало, то это "частенько" ведёт к нарушению всего SOLID. Это не причина.
Серебряной пули и правда нет. Но есть best practices и они появились не с пустого места. А насчёт аббревиатур — это удобный способ донести мысль другому человеку по-быстрому.
Ага. Все рекламируют композицию и делегирование, а что в большинстве языков нет реализации интерфейса через член, советующих не волнует — ну, крутись как хочешь, плоди сотни строк непродуктивного кода.
Везде свои компромиссы. Хотите хорошую систему, с которой приятно работать и удобно вносить изменения — делегируйте; проект небольшой — колбасьте код как угодно.
Да и про какие сотни строк вы говорите? Если у вас есть класс, который реализует так много интерфейсов, то проблема возникла раньше. Опять же из-за не следования хорошим практикам.
Жить вообще опасно. Просто если хочешь унаследоваться вместо композиции — подумай 10 раз, унаследоваться глубоко — 100, унаследоваться множественно — 1000.
Об этом и речь — зачем усложнять и думать 10-100-1000 раз, если можно сделать просто?
Интерфейсы ни от чего не спасают. Это ужасная сущность с точки зрения развития системы, потому что их изменять вообще невозможно. Любое изменение — всё, система сломана.
Интерфейсы это ваш контракт. Это ваш api, если хотите. И если контракт меняется, значит на то была причина — изменилось требуемое поведение.
Чем это лучше классов, где что-то в предках изменилось, и вдруг поломался потомок? Ну, хотя бы есть ненулевой шанс, что оно будет работать. Изменение интерфейса ломает систему всегда.
В том и проблема, что оно может будет работать. А может не будет. А может будет работать не так, как надо. А может появиться новое поведение, которое не ожидалось. В любом случае, чтобы быть уверенным придётся проверить всех наследников. С композицией надо проверить только там, где изменилось.
Рассуждение выше про интерфейсы немного устаревает с введением костыля под названием "default interface implementation" — интерфейсы теперь становятся недо-классами.
Согласен, default interface implementation неоднозначная фича. Пока что, я вижу ей применение для добавление утилитарного поведения, вроде того же observer'a.
Кстати, насчёт глубокой цепочки наследования в GUI — тот же реакт построен на High Order Components и там этот подход весьма органичен.
Нет, в таком случае обычно вводится ещё один промежуточный класс в иерархию
Что в свою очередь делает всю систему еще более запутанной. Видел я систему компонентов из 7+ уровней наследования, казалось бы все красиво и круто, но разбираться в этом – то еще удовольствие :(
Если существовала бы какая-то «серебряная пуля», которая помогала бы реализовать сложное поведение с помощью простой и очевидной модели, мы бы все ей пользовались :)
Из своего опыта могу сказать, что для меня «серебряная пуля» – это модульный подход (использовать interface и лишь один уровень иерархии).
Да, придется дублировать код в разных модулях, но в результате мы получаем Очевидную реализацию и поведение, легкость в тестировании и следование принципам LSP и SRP, что в свою очередь дает нам взаимозаменяемость модулей.
gpu user benchmark с вами не согласен. Intel HD 630 не дотягивает даже до GTS 450 (+20%), и существенно отстает даже от дешевых GTX 460 SE (+65%) плат, в то время как референс GTX 460 (+93%) вообще кажется чем-то недостижимым.
У нас около 850 ПК.
Найдите GF8800 хотя бы для 1% из них )
Но самое главное — в этом нет никакого смысла, так как GF8800GT — это уровень встроенных видео HD Graphics 4200, 4400, 4600, P4600 и P4700 — уровень 2013 года.
Ну, вам не угодить. Сейчас люди предпочитают ноуты и планшеты, в которых другой графики, кроме встроенной вообще нет.
Офисных. Бюджетных полным полно. Но даже в случае офисного компьютера по любому лучше запихнуть какую-нибудь старинную GF8800, чем сидеть на встроенной графике. Ведь это так или иначе нагрузка на кристалл, а умрет GF8800 ее не жалко.
Но ПК из Эльдорадо конечно плохой пример, разве не так? Я бы сказал, очень, очень плохой.
Я с 2005 года не встречал бюджетно-офисных компьютеров с отдельной видеокартой.
А их только в нашей организации сотни.
Когда появились магазины электроники — большая часть ПК «для дома» в них имела низкую цену и встроенную графику.
Недорогие видеокарты сейчас берут, в основном, на замену вышедшим из строя, или слишком «горячим» видеокартам в старых компьютерах.
1 Встроенные видеоядра широко предлагаются покупателям с 2010 года и даже раньше (встроенные в чипсет были). Но популярности они никогда не имели. Почему?
2 Их низкая популярность обусловлена низкой производительностью. Видеоядра нужны не для игр, а для обработки и отображения 2d. В 3d режиме тягаться с видеокартами они не могут.
3 Следовательно встроенные видеоядра не составляют конкуренции видеокартам и на их рынок влияния оказывать не могут.
Ой. Автор не заметил процесс вытеснения недорогого ценового сегмента видеокарт — встроенными в процессор решениями, а вы требуете внимания к криптовалютам )
Хуанг уже давно озвучил и повторил, что след.поколение 100% будет дороже, из-за дорогих НИОКР и неудержимого роста цен на оперативную память.
И дороже будет всё, не только топы.
Интерфейс — это синтетическая сущность, которая переваливает проблемы ромба с «головы» компилятора на программиста.
Очень уж мне не нравится это определение интерфейса. Лично для себя сформулировал, что интерфейс — это описание контракта, и это не класс со всеми методами без реализаций. Это разные сущности, в том-же C# можно явно реализовать интерфейс, попробуйте сделать то же самое с абстрактным классом.
Человек, для которого ООП сводится к наследованию ("Не пользуйтесь ООП в ООП") — настолько далёк от понимания предмета, что нет смысла даже тратить время на объяснения — просто ставишь минус и идёшь дальше.
Не люблю интерфейсы как раз потому, что они очень грубо описывают контракт. То есть вроде есть контракт, но в то же время он очень-очень общий. С одной стороны, вроде лучше чем ничего, а, с другой, иной раз тратишь много времени на оформление такого контракта, а толку мало: соблюдая его на уровне синтаксиса языка, имплементации полностью рушат все даже задокументированные пред- и постусловия с инвариантами.
Идеальную чистоту интерфейсов можно содержать только в полностью контролируемой кодовой базе, то есть примерно никогда. Во всех остальных случаях интерфейсы плодятся как кролики, потому что они не версионируемые, они в принципе не поддерживают совместимость назад.
В результате в COM мы имеем наследование от IContextMenu1, IContextMenu2, IContextMenu3, IContextMenu4, а в C# имеем ICollection, IReadOnlyCollection, IReadOnlyList (причины разные, результаты разные, но последствия всегда неприятные). И вот никуда от этого не деться. Ну не задизайнить интерфейсы так, чтобы один раз и на всю жизнь.
Ну вот допустим в C# был бы не класс FileStream, а интерфейс IFileStream. Теперь мы хотим добавить поддержку асинхронного чтения. Ваши действия? Добавить новый интерфейс? Расширить существующий? Любое решение с интерфейсами (без default interface implementation) будет неудобным для потребителя.
Идеализирование. Реализация всего может поменяться в любой момент несовместимым способом. Ломается всё, независимо от архитектуры, поэтому всё равно вы всё будете тестировать, если хотите спокойно спать по ночам.
ООП это не только наследование. Я не призываю отказываться от наследования совсем, но мой подход чем реже, тем лучше.
Серебряной пули и правда нет. Но есть best practices и они появились не с пустого места. А насчёт аббревиатур — это удобный способ донести мысль другому человеку по-быстрому.
Везде свои компромиссы. Хотите хорошую систему, с которой приятно работать и удобно вносить изменения — делегируйте; проект небольшой — колбасьте код как угодно.
Да и про какие сотни строк вы говорите? Если у вас есть класс, который реализует так много интерфейсов, то проблема возникла раньше. Опять же из-за не следования хорошим практикам.
Об этом и речь — зачем усложнять и думать 10-100-1000 раз, если можно сделать просто?
Интерфейсы это ваш контракт. Это ваш api, если хотите. И если контракт меняется, значит на то была причина — изменилось требуемое поведение.
В том и проблема, что оно может будет работать. А может не будет. А может будет работать не так, как надо. А может появиться новое поведение, которое не ожидалось. В любом случае, чтобы быть уверенным придётся проверить всех наследников. С композицией надо проверить только там, где изменилось.
Согласен, default interface implementation неоднозначная фича. Пока что, я вижу ей применение для добавление утилитарного поведения, вроде того же observer'a.
Кстати, насчёт глубокой цепочки наследования в GUI — тот же реакт построен на High Order Components и там этот подход весьма органичен.
Из своего опыта могу сказать, что для меня «серебряная пуля» – это модульный подход (использовать interface и лишь один уровень иерархии).
Да, придется дублировать код в разных модулях, но в результате мы получаем Очевидную реализацию и поведение, легкость в тестировании и следование принципам LSP и SRP, что в свою очередь дает нам взаимозаменяемость модулей.