Overhlopec
Статус: Не в сети Регистрация: 22.05.2006 Откуда: Москва
Чувствую в 2009 посмеюсь я над теми кто пишет что это "чушь"
я вот помню как про 64 бит говорили что это просто бред такой что уже не знают что еще придумать, и вот про многоядерность тоже бред говорили, что это почти не возможно, что тепло выделение будет таким что надо фреонку сразу итд... да все меняется и технологии тоже, все впишется в определенные рамки и цена и теплопакет и производительность.
Member
Статус: Не в сети Регистрация: 06.06.2006 Откуда: Симферополь
Для мат вычислений ИА-32 является узким местом. АМД64 тоже, хотя немного побыстрее будет. Переходить на риск архитектуру и ИА-64 никто не будет, так как дорого все это.
Поэтому логично было бы сделать графическое вычислительное ядро поближе к процу, чтоб можно было его задействовать как дополнительный вычислительный блок, дав доступ к нему программерам. Это будет новый набор инструкций быстрого вычисления, а на пол ставки ГПУ, так как РАМДАК сбодяжить особого труда не стоит. А кому нужно супер производительное графическое решение, ставят дискретку, а ГПУ в проце занимается на целую ставку вычислениям. Чем вам не нравится такой подход?
А можно вопрос ? Почемы Вы так быстро исчезли с ветки обсуждения K8L на ixbt, не хватило знаний аргументированно отвечать ?
Меня конечно не спрашивали, но мусолить K8L нельзя бесконечно, достаточно высказать свою позицию, кроме того господин бесс хоть и неплохо ориентируется в теме, ни чего конкретного не утверждает (при мне по крайней мере не было) или мне так показалось.
_________________ Кратчайшее расстояние между двумя точками это точка.
Для мат вычислений ИА-32 является узким местом. АМД64 тоже, хотя немного побыстрее будет. Переходить на риск архитектуру и ИА-64 никто не будет, так как дорого все это.Поэтому логично было бы сделать графическое вычислительное ядро поближе к процу, чтоб можно было его задействовать как дополнительный вычислительный блок, дав доступ к нему программерам. Это будет новый набор инструкций быстрого вычисления, а на пол ставки ГПУ, так как РАМДАК сбодяжить особого труда не стоит. А кому нужно супер производительное графическое решение, ставят дискретку, а ГПУ в проце занимается на целую ставку вычислениям. Чем вам не нравится такой подход?
+1 +1 +1 +1 +1
_________________ Так вот ты какой, серверный олень!
Чувствую в 2009 посмеюсь я над теми кто пишет что это "чушь"
я вот помню как про 64 бит говорили что это просто бред
Ну, извини меня, но это конечно, не бред, но особой пользы, мягко говоря, тоже никакой. На 64-битных процессорах 32-битные программы идут медленнее, а если учесть, что 32-битных программ - 93-94% на рынке то все становиться на свои места. Для 64-бит даже нормальную ОС придумать еще не могут (ХР 64 - ето, канешно мощна ), да и преимущества 64 битности раскрываются только когда оперы более 4 Гигабайт. А если учесть, что сейчас любому приложению больше 2 Гб не нужно, то становиться понятно, что 64-битность - это просто бренд. Сейчас такое время, что друг другу противостоят не качественные технические разработки, а рекламные и маркетинговые ходы, так что, кто лучше прорекламирует свой товар - тот и получит больше прибыли. А 64-битность отличный аргумент в рекламе, чтоб навешать лапшу людям далеким от архитектуры ЭВМ
Member
Статус: Не в сети Регистрация: 02.02.2007 Откуда: Казахстан
Технология это будет очень полезна для мобильных ПК, а для настольгых посмотрим, покажет результат будет и настольной (бюджетные ит.п., если по цене конечно подойдут под "бюджетность"). Насчет 64 битности, то она дает некоторое повышение произв., около 10-15%, но конечно не везде, она нужна там, где работа с большими числами (>2^32 без знака и т.п.), хотя и многие знают это, т.е. в такого рода программах как архиваторы, конверторы и т.п.
В Windows x64 насколько я знаю 32 битный код эмулируется как 16-битный в стандартных через NTVDM.
Переход 4 64-битности в принципе массово не нужен, а так кому-то (по делу), это полезная вещь.
Кстати где-то читал, что у нынешних интеловских процев проблема в 64-бинтых приложениях связана и с кэшем, механизм другой, проблемы (все таки 32-битность уже сколько сущ., привыкли видимо)
Цитата:
Чувствую в 2009 посмеюсь я над теми кто пишет что это "чушь"
я вот помню как про 64 бит говорили что это просто бред такой что уже не знают что еще придумать, и вот про многоядерность тоже бред говорили, что это почти не возможно, что тепло выделение будет таким что надо фреонку сразу итд... да все меняется и технологии тоже, все впишется в определенные рамки и цена и теплопакет и производительность.
Всее может быть. Мне тоже было смешно, когда я читал прогнозы интела о своих процах (новости железа и т.п. читаю внимательно только 2 месяца)
Что-то вроде "к 2010-2012 году частота проца 20 ГГц" смех да и только (сейчас по крайне мере)
Member
Статус: Не в сети Регистрация: 06.06.2006 Откуда: Симферополь
Manaus, немного мимо темы возмущение.
1. Вопрос интеграции, как раз таки помогает обогатить новыми инструкциями х86 и решить проблему, о которой вы писали (проблема саппорта софтерными компаниями). Вычислительные блоки ГПУ - это мощьный ресурс, который будут делить между собой встроенная видяха в проц и новый набор инструкций. Все это вместе увеличит производительность, снизит себестоимость в расчете на платформу.
2. Про 64 бита Вы конечно загнули. Падение производительности ничтожно мало. На столько, что я сижу уже 8 мес под вынь2003 х64 и не замечаю никаких проблем. Про оперу в 4 гига - это полный бред. НЕТ никакого преимущества в 32 софта в 64 битном режиме. Сама же 64-битность версии АМД - это мягкое и безболезненное раскрытие узкого горлышка ИА-32. Потерять сегодня в 64 битной оси на 32 битных приложениях 2-3%, ради стимулирования будущего перехода на 64 бита не так уж критично. Проблема 64 битности только в дровах. Новые девайсы и так идут с 64 битами, а старье вытеснится отсутствием сапорта и ПСИ портов на мамке. Так, что через пару лет все будут вспоминать о 32 битном софте, как года 4 назад о 16 битном все вспоминали. Добавлено спустя 19 минут, 17 секунд
Цитата:
В Windows x64 насколько я знаю 32 битный код эмулируется как 16-битный в стандартных через NTVDM.
Не эмулируется, в этом весь фокус АМД64. А работает на равных правах с 64 битными приложениями, не используя никаких посредников типа NTVDM. Разница только в том, что нет доступа к дополнительным регистрам. У самого же проца меняется только флаг состояния (который и так постоянно меняется, при переключении между задачами), информирующий проц о работе с 32 битным софтом.
Member
Статус: Не в сети Регистрация: 01.07.2005 Откуда: москва
TyyOx91 писал(а):
Вы видимо лучше осведомлены о планах АМД, чем сама АМД.
Да всё так общий контроллер памяти и кроссбар а Интела что? кустарщина собираются подклить к процессорному кристаллу(который к тому времени уже будет содежать кп (правда от этого же ведь пострадает гибкость конфигурирования систем!!!! ведь кп в северном мосту это так удобно и так рационально!!!)) графический чип
а Интела что? кустарщина собираются подклить к процессорному кристаллу(который к тому времени уже будет содежать кп (правда от этого же ведь пострадает гибкость конфигурирования систем!!!! ведь кп в северном мосту это так удобно и так рационально!!!)) графический чип
Сомневаюсь, что вам известно что именно собирается делать Интел (или снова хрустальный шар...? )
Кроме невнятных предположений с PCWatch, другой инфы нет. Но даже с такой компоновкой решение Интел может быть эффективнее (например, если CPU и GPU получат раздельный доступ к памяти.
Member
Статус: Не в сети Регистрация: 02.02.2007 Откуда: Казахстан
medcom Я не говорил имено про АМД. То что на равных правах, то в интеловских процах есть такая вещь как префикс (команда, перед опкодом, кажется для 32->16 66h), который означает какой код сейчас выполняется (32,64), на счет производительности сказать ничего не могу, но думаю не очень быстро и не очень медленно. НО это будет работать если это есть в программах, а в большенстве прог этого нет (пока вроде), а то что АМД-шные вып. на равных, это их плюсы, не зря же они называются А64 и АМД64. На счет проблем с дровами и жедлезом (старым), которые тормозят преход к 64-битности, это точно. Должно же это когда нибудь произойти, сколько уже 32-битность сущ.
Member
Статус: Не в сети Регистрация: 06.06.2006 Откуда: Симферополь
TyyOx91, интересно, чем противоречит этот слайд моим словам? Если дадут доступ к вычислительным блокам ГПУ программерам через какой=нибудь АПИ (а я именно об этиом где-то читал про АМД), то это и будет НОВЫЙ НАБОР ИНСТРУКЦИЙ.
Чтоб больше не улыбало, то напомню, что ФПУ когда-то назывался х87 и подключен тоже был через общую шину. ПРошло 7-10 лет, и это уже никого не улыбает (кроме ВАС). А Вам уже не нужно приобретать в свою систему сопроцессор "овердрайв". Добавлено спустя 6 минут, 23 секунды
Me4tatelI> писал(а):
medcom Я не говорил имено про АМД.
Я тоже не говорил именно про АМД. Я говорил (точнее будет писал) про набор инструкций АМД64 (или его общий алиас х86-64, или алиас по версии Интел ЕМ64Т.) Но как бы он там не назывался, этот набор инструкций на уровне АПИ ничем не отличается.
Если дадут доступ к вычислительным блокам ГПУ программерам
А сейчас не дают?
Цитата:
то это и будет НОВЫЙ НАБОР ИНСТРУКЦИЙ.
И чем он будет отличаться от старого (в текущих GPU)?
Цитата:
Чтоб больше не улыбало, то напомню, что ФПУ когда-то назывался х87 и подключен тоже был через общую шину.
Да, было такое дело . Называлось 8087. Реализовано это было через "одно место", так как CPU и FPU сидели на одной шине и оба декодировали каждую приходящую инструкцию (для этого имели дублирующие друг друга блоки BU и декодеры). Багов это вызывало немеряно и поэтому в следующей реализации (80287) Интел от этой идеи отказался и "повесил" FPU на специальные порты CPU.Надеюсь АМД не будет возвращаться в 21 веке к этой ущербной концепции .
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 17
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения