При создании оберток нужно не забывать что обертка делается для человека а не наоборот.
Не следует запрещать самому себе все и вся, это вредно — именно это обычно порождает проблемы.
P.S. Производительность практически всегда приносится в жертву удобству, и наоборот. Если видите что система получается слишком сложной (взаимозависимости технологий друг от друга большое), лучше остановиться и прекратить решать как еще извратиться чтобы получить результат (анекдот про программиста и чайник помните?). Лучше написать своё.
хм, корпус 180х180х30 мм стоя два по высоте вроде влезают (1u=4,445см) а по ширине стойки 750 мм (ширина) x 1070 мм (глубина) рядышком влезет 20-25 шт, а в глубину можно еще рядок другой добавить :) но уже обслуживание неудобное.
Итого 50шт на 1u… блин, при стоимости компьютеров в 500т.р. эта стоечка 'заткнет за пояс' по производительности (… и энергопотреблении) любой сервер такого же размера.
А если собрать все тоже самое но в корпусе 1u? — пластик корпусов + общие БП + свой собственный гигабитный свич. Что то жуткое получается :).
Отдельно RAM диски почему то не прижились или есть но баснословно дорогие.
С появлением mini itx машинок + мини UPS (бесперебойник) + гигабитка + нетрадиционный NAS (ну к примеру функция fsync() заменена заглушкой) с iSCSI (лучше попроще что-нибудь вида AOE/NBD) = то что надо и типоразмер влезает в ATX, только если присобачить к боковой крышке.
спасибо, посмотрел, поискал варианты. Можно считать что нету.
ну его, с такой скоростью что оно перерисовывается,… я успеваю за такое время прочитать треть страницы такого формата, а если это документация, то я бы уже листал следующую.
А вы не пробовали посмотреть на сравнения производительности xen и реального железа? что то мне говорит что на задачах, где требуются вычисления, виртуалка будет очень далеко… позади.
В случае с vds та же фигня. Порт то у виртуальной машины один (уж точно не на каждого пользователя).
И вообще перестаньте воспринимать сетевой порт как нечто выделенное и личное, давно все уже шейпится либо управляемым свичом либо дальше.
XP что, не может решать задачи, которые возлагаются на нетбуки? Какая нафиг разница, сколько лет назад было создано ПО, если оно решает текущие задачи хорошо и даже лучше.
Устанавливаемое оборудование обязательно должно быть одним из этих двух вариантов, или можно собрать что-то своё? При условии сохранения габаритов конечно же.
Если из вопроса убрать слова 'популярны/распространены' (не обладаю достаточными данными чтобы отвечать именно на это), то…
* Кеширование EAV?
Самое первое решение, что приходит обычно в голову, это возврат к модели преставления данных, проблемы которой оно и решает, т.е. создание таблиц с полями — соответствующих элементам из EAV. Само собой только для тех атрибутов, доступ к данным которых — узкое место.
EAV: prop(id,name)={1: это,2: то,3: тому,4: того,...}, object(id,...), values(id,object_id,prop_id,data)
Кэш: cache(object_id,prop1,prop2,prop3)
Плюсы: облегчает задание сложных ограничений целостности (constraint на кэш), увеличивает скорость доступа к значениям пропертей (индексы на propX у кэша)
Минусы: неполная транзакционность (изменение prop, да еще внутри тригеров — кошмар), вроде нет БД предоставляющих транзакции на команды DDL, меняет подход к построению SQL запросов и ограничивает/усложняет удаление элементов из prop.
* Соответствие кеша данным?
Что тут можно предложить, только тригеры или использование прослойки между БД и приложением (фактически свои собственные тригеры).
Прослойка между приложением и БД вообще полезная вещь не только для подобных задач, если использовать информацию о модели данных, на этапе проектирования в (полу)автоматическом режиме, то создание подобных кешей можно вообще практически полностью автоматизировать.
Ну по поводу пунктов про ORM, EAV и IDE я бы поспорил.
* ORM — нужно изобретать, в идеале, править имеющиеся. Так как то что есть далеки от идеала. На практике реально использовали практически полностью своё, первая версия конечно же больна всеми болезнями, что дают велосипедостроение и первооткрыватели, но идеи, особенно на вторую версию, очень даже здравые.
* EAV — отказываться от этой модели не просто глупо а преступление :) в некоторых случаях без нее просто не обойтись. Говорить что эта модель в чем то ограничивает как то глупо, я не согласен, изменение структуры данных без изменения структуры физического хранилища очень большой плюс. Проблемы с производительностью решаются, к примеру, 'кешем' в нормальных формах, для критичных для скорости данных.
* IDE — полностью отказываться конечно тяжело да и не нужно, практика показывает что в части задач разработки лучше использовать что 'то мышастое' (это шутка, имеется в виду готовые инфраструктуры сборки, отладки, тестирования, генерации установки и т.д.) чтобы не тратить на это время, за это же можно заплатить потерей производительности конечной программы (хотя выбор IDE и фреймворка должен быть обдуманным с оглядкой именно на производительность, а не только на возможности). но практика показывает что какие то задачи удобнее решать 'своими силами', в этом случае IDE, которое можно допилить до желаемого, предпочтительна.
Может быть 'каким критином надо быть, чтобы для несложных задач покупать дорогущее и мощнейшее железо?' А мизерные размеры вы не замечаете? а энергопотребление? а уровень шума?
А то получается, покупают супер комп от 3к$, а на нем 'секретарша' дальше пасьянса, ворда и вконтакте не вылезает.
Видео декодеры на сколько я знаю пока не cuda (офицально), но явно используют производные технологии.
Подскажите, кто имеет опыт работы с mini itx решениями со встроенными видео nvidia. интересует производительность cuda приложений, для тестов можно воспользоваться готовыми примерами, входящими в состав cuda sdk (например particles.exe -n=500000 -grid=200 у меня притормаживает на 9800gtx+)
Не следует запрещать самому себе все и вся, это вредно — именно это обычно порождает проблемы.
P.S. Производительность практически всегда приносится в жертву удобству, и наоборот. Если видите что система получается слишком сложной (взаимозависимости технологий друг от друга большое), лучше остановиться и прекратить решать как еще извратиться чтобы получить результат (анекдот про программиста и чайник помните?). Лучше написать своё.
Итого 50шт на 1u… блин, при стоимости компьютеров в 500т.р. эта стоечка 'заткнет за пояс' по производительности (… и энергопотреблении) любой сервер такого же размера.
А если собрать все тоже самое но в корпусе 1u? — пластик корпусов + общие БП + свой собственный гигабитный свич. Что то жуткое получается :).
С появлением mini itx машинок + мини UPS (бесперебойник) + гигабитка + нетрадиционный NAS (ну к примеру функция fsync() заменена заглушкой) с iSCSI (лучше попроще что-нибудь вида AOE/NBD) = то что надо и типоразмер влезает в ATX, только если присобачить к боковой крышке.
ну его, с такой скоростью что оно перерисовывается,… я успеваю за такое время прочитать треть страницы такого формата, а если это документация, то я бы уже листал следующую.
И вообще перестаньте воспринимать сетевой порт как нечто выделенное и личное, давно все уже шейпится либо управляемым свичом либо дальше.
eeepc 901 при полной зарядке 3 часа 20 мин.
* Кеширование EAV?
Самое первое решение, что приходит обычно в голову, это возврат к модели преставления данных, проблемы которой оно и решает, т.е. создание таблиц с полями — соответствующих элементам из EAV. Само собой только для тех атрибутов, доступ к данным которых — узкое место.
EAV: prop(id,name)={1: это,2: то,3: тому,4: того,...}, object(id,...), values(id,object_id,prop_id,data)
Кэш: cache(object_id,prop1,prop2,prop3)
Плюсы: облегчает задание сложных ограничений целостности (constraint на кэш), увеличивает скорость доступа к значениям пропертей (индексы на propX у кэша)
Минусы: неполная транзакционность (изменение prop, да еще внутри тригеров — кошмар), вроде нет БД предоставляющих транзакции на команды DDL, меняет подход к построению SQL запросов и ограничивает/усложняет удаление элементов из prop.
* Соответствие кеша данным?
Что тут можно предложить, только тригеры или использование прослойки между БД и приложением (фактически свои собственные тригеры).
Прослойка между приложением и БД вообще полезная вещь не только для подобных задач, если использовать информацию о модели данных, на этапе проектирования в (полу)автоматическом режиме, то создание подобных кешей можно вообще практически полностью автоматизировать.
* ORM — нужно изобретать, в идеале, править имеющиеся. Так как то что есть далеки от идеала. На практике реально использовали практически полностью своё, первая версия конечно же больна всеми болезнями, что дают велосипедостроение и первооткрыватели, но идеи, особенно на вторую версию, очень даже здравые.
* EAV — отказываться от этой модели не просто глупо а преступление :) в некоторых случаях без нее просто не обойтись. Говорить что эта модель в чем то ограничивает как то глупо, я не согласен, изменение структуры данных без изменения структуры физического хранилища очень большой плюс. Проблемы с производительностью решаются, к примеру, 'кешем' в нормальных формах, для критичных для скорости данных.
* IDE — полностью отказываться конечно тяжело да и не нужно, практика показывает что в части задач разработки лучше использовать что 'то мышастое' (это шутка, имеется в виду готовые инфраструктуры сборки, отладки, тестирования, генерации установки и т.д.) чтобы не тратить на это время, за это же можно заплатить потерей производительности конечной программы (хотя выбор IDE и фреймворка должен быть обдуманным с оглядкой именно на производительность, а не только на возможности). но практика показывает что какие то задачи удобнее решать 'своими силами', в этом случае IDE, которое можно допилить до желаемого, предпочтительна.
А то получается, покупают супер комп от 3к$, а на нем 'секретарша' дальше пасьянса, ворда и вконтакте не вылезает.
P.S. картинка трафик кушает 8кб/сек
Подскажите, кто имеет опыт работы с mini itx решениями со встроенными видео nvidia. интересует производительность cuda приложений, для тестов можно воспользоваться готовыми примерами, входящими в состав cuda sdk (например particles.exe -n=500000 -grid=200 у меня притормаживает на 9800gtx+)