← Десктоп суперкомпьютеры по500 евро за терафлопс: куда девать такую мощь
Обсуждение
Читать и комментировать в ЖЖ ↗
Есть алгоритмы вроде распознавания изображений, аудио и видео где без терафлопсов не обойтись никак. Как только появятся терафлопсы не только дешёвые, но и с низким энергопотреблением, они своё применение сразу же найдут в мобильной среде.
Комментарий
Ну, сами по себе данные, которые они сейчас считают — да, будут выкинуты. А приборы, которые они изменяют так, что на них считаются те данные — скорее всего, наоборот. В смысле — найдут свою полезную нишу. Например, чтобы автоматически определять новообразования размером с рисовое зёрнышко — таки требуется разрешэние чуть лучшэ этового рисового зёрнышка.
Комментарий
При таком сканировании -- согласен, считать нужно всё. Но мне почему-то кажется, что они не столько ищут рисовое зернышко, сколько смотрят. А для просмотра считают всё.
Комментарий
Я же не возражаю, что терафлопсы нужны даже в мобильниках. При предложенном мной способе работы какое-то количество терафлопсов в любом случае нужно, чтобы не 128*128 разрешение было доступно. Я просто говорю, что лишних терафлопсов не нужно.
Комментарий
> Я просто говорю, что лишних терафлопсов не нужно.
А я как раз говорю что лишних терафлопсов не бывает. Были бы ресурсы, а задач под них на столетия вперёд.
К примеру, вот будет у Вас 5 терафлопсов на десктопе. Один можете использовать сами, а остальными помогать расшифровывать геномы и прочие общеполезные массовые вычислительные задачи или сдавать в аренду уже за деньги.
Комментарий
Да я тут про другое пишу. Я пишу, как на том, что уже есть сейчас, решать задачи "из будущего". За счет изменения архитектуры. Это ведь четкий архитектурный паттерн.
Комментарий
И для того, чтобы это изменить, тожэ нужны тэрафлопсы! Чтобы усмотреть это глазами стало совсем невозможно.
Комментарий
Так проблема в том, что нет возможности вычленить сигнал "от этого кусочка". Он замешан в сигнале "с этой стороны". Никуда не деться от голографии. Конкретно тут надо менять не алгоритмику, а физику датчика. Но не на что.
Комментарий
Я, вроде, это специально оговорил в тексте, да? Я думаю, что это архитектурное решение: менять нужно весь тракт (включая датчики и способ сканирования, заканчивая визуализацией).
Контраргумент про автоматическое распознавание трехмерных сцен по отсканированному (т.е. просмотр не глазами) тут более сильный. Но и тут возможны разные стратегии поиска...
Комментарий
во многих задачах, когда делают кт костей, требуется весьма высокая точность - например, моделирование и установка костных имплантов.
по сути для улучшения точности есть два метода: 1) повышение точности датчиков 2) повышение качества обработки сигнала
я не вижу дешёвого пути улучшения пункта 1), а 2) улучшать, получается, научились.
по-моему, это достижение, хотя и экстенсивное, согласен
Комментарий
У АМД-шных GPU терафлопсы подешевше будут: HD 5870 стоит 500 баксов примерно и имеет производительность 2.72 терафлопа. HD 5970, два GPU, стоит в районе 1000 баксов, производительность 4.64 терафлопа.
Комментарий
Лет 5 назад уже удивлялся - как же интернеты-то по дибильному устроены. Пользователь нажимает какую-то простейшую хрень, а на сервере очень затратным образом генерируется куча хтмла, и вся эта байда каждый раз высылается пользователю. Трилионы ненужных гигабайтов трафика, трилионы трилионов ненужных операций на всех серверах.
А аякс тоже вполне бредовая хрень. В разных (новых!) браузерах абсолютно разные свои прибамбасы для асинхронной передачи данных. Несовместимые - нужно проверять какой браузер, после этого пытаться с ним работать (если библиотека подключается, то это она делает). И кода на джиесе получается куча страниц.
А есть простейшая вещь, даже в древних браузерах работающая. Просто и кратко.
Тут работающая асинхронно страничка. При нажатии на кнопочку загружаются данные и показываются. Всё здесь.
<iframe name='f' style='position:absolute;left:-100;top:-100;width:1px height:1px;'
onLoad="document.getElementById('t').innerHTML='Получены данные:'+this.document.body.innerHTML"
></iframe>
<input type='button' onClick="parent.frames['f'].location='site.site/?i=123'" value='Получить данные'>
<div id='t'></div>
Комментарий
Или вот ещё очень полезная штука. Частая задача. Например, проверка, есть ли пользователь с заданным именем во время ввода. Тоже в сто раз компактнее, универсальнее и проще чем типовыми "аяксами".
<input onKeyUp="document.getElementById('i').src='site.site/usr/'+this.value">
<div id='t'></div>
<img onLoad="document.getElementById('t').innerHTML='имя '+(['свободно','занято'])[this.width+1]">
Можно поразному доработать, например чтоб не на каждое нажатие проверялось а при возникновении паузы ввода с помощью setTimeout().Комментарий
Лет 5 назад уже удивлялся - как же интернеты-то по дибильному устроены. Пользователь нажимает какую-то простейшую хрень, а на сервере очень затратным образом генерируется куча хтмла, и вся эта байда каждый раз высылается пользователю. Трилионы ненужных гигабайтов трафика, трилионы трилионов ненужных операций на всех серверах.
Вот вот, больше всего меня убивает ПХП. Это надо было постараться сделать такую тормозню которая на современном многопроцессорном, многоядерном сервере выдает 50 запросов в секунду.
Комментарий
Меня эти особенности современного софта тоже убивают. Я помню, как работал на процессорах в 10 тысяч раз более медленных -- и все шуршало довольно быстро, и даже базы данных.
Комментарий
Не вижу, где у тебя про способ сканирования.
Да, с распознаванием - та же история: у тебя изначально есть проекция на заданную плоскость, хотя если бы ты знал, где находится интересующий объект - мог бы сделать снимок только его, с двух точек, и затратить на это меньше пикселей.
увы
масштабы сейчас не те
например сейчас легко могут запихнуть в ту базу в бинарном образе фотографии (например иконки)
или цельный документ в записи
вот и пухнет база данных
действуют те же законы эволюции
биосфера ведь существет так же -- заполнены все ниши которые доступны
а вот с вашим "архитектурным паттерном" заминочка получается
чтобы оно все так красиво работало, все равно ведь требуется чтобы эта информация ЗАРАНЕЕ была уже специально обработана и порезана на куски.
и если этого раньше не делали, то одна из главных причин какраз и заключается в том, что не было таких ресурсов.
про пресловутые гугловские датацентры, вы думаю знаете, не так ли
а они и есть та невидимая сила, которая обеспечивает "простоту" на стороне клиента, и сила эта совсем не простая.
Re: увы
Опять же, я тут не о том пишу, и мой комментарий к комментарию про пхп.
Комментарий
Я не про технологии, а вот про такую очевидную вещь.
Далеко не ходить, возьмём жожо. Запрос страницы - компилируется куча текстов - заголовок, длинный основной материал, большое обсуджение с кучей информации где все комментарии свёрнуты. Нажимаю "развернуть" маленькую веточку. Отправляется запрос, на сервере вся эта куча работы делается заново - достаются-компилируются большие разные тексты, ну и сервер не забывает заботливо вставить заказанный коментарий с текстом "превед медвед". Кпд меньше 1%.
Можно было бы сразу всё вставить. Если например ветка в <div id='t'>, сделать простую ссылочку <a href="javasript:t.style.display=(t.style.display=='block'?'none':'block')">свернуть/развернуть</a> или <span onClick="...">.Всё! Весь код для динамического сварачивания-разворачивания здесь.
Или если всё-таки "жалко"(хотя это както странно учитавая то как работает) трафика, можно сделать вариант, чтоб загружалась только ветка и вставлялась в нужное место.
Тут вообще как всё это получилось. Раньше предполагалось что интернет - куча простых разных текстов, с гиперсылками, указывающими на другие тексты.
Но потом двигались к всё большей "интерактивности", когда страница остаётся такой же (по ощущениям пользователя "я на (в) этом сайте"), а изменяется лишь небольшая часть контента, которую он захотел изменить (обновить). Но при этом продолжала (и сейчас) оставаться единственной логика "передачи каждый раз целиком страницы". Причём чаще всего даже вопрос о кэшировании сгенерированных страниц не вспоминается, сервер тыщи раз тупо делает одно и то же.
А про ПХП, тут можно небольшую но ожесточённую идеологическую войну устроить.
Мне нравится Перл, ПХП. Перл же вообще создавался как очень эффективное средство обработки текстов. И ПХП тоже, только упрощённый и специализированный для веб. А ведь как-раз только это и требуется - быстро сгенерировать текст (хтмл).
К джаве у меня вообще крайне негативное отношение. И к "веб-фреймворкам" на её основе. Разбирался как-то 3 дня внимательно, много всего читал-устанавливал, потом запустил, сидел с грустью смотря в монитор - "блин, чо нитак? всё же правильно сделал?". Но секунд через 10 увидел заветное "Хелло, Ворлд!!!". Ещё секунд 10 размышлял. После чего сказал раз и навсегда всем этим поделкам "досвиданья", ибо за 10 секунд на ПХП можно 3ю мировую войну промоделировать.
Возвращаясь к джаве. По моему скромному имхо, это самое идиоцкое изобретение человечества. Во первых, я к ооп всегда плохо относился, и особенно когда его преподносят как единственнуб истину, откровение свыше.
Во вторых, одна из прелестей интерпретируемых языков в том, что можно типов не указывать. А в джаве этож идиологическая заповедь (=>идиотизм). Да, если опыта мало, могут быть крайне неприятные ошибки. Но если разобраться, то это очень приятно когда в одной строке кучу типов перемешиваешь, зная и подразумевая как они все преобразуются одним единственным способом. Если бы эти пребразования определять явно, возможно получился бы десяток весьма скучных строк.
Re: увы
\\ Опять же, я тут не о том пишу, и мой комментарий к комментарию про пхп.
Да, это моя вина, я решил сэкономить здесь один пост, написав два разных комента в одном
А с ПХП какраз все очень просто -- это (рас)плата за простоту, за возможность делать что-то не задумываясь о низкоуровневых вещах.
По сути, он тот самый DSL для разработки веб-страниц. По крайней мере так оно начиналось. А потом, в виду успещности подхода, обросло ракушками улучшений -- самое обычное дело -- выигрывает не то что лучше, а то что выигрывает\вижывает и потом становится стандартом де-факто.
А потом уже оно улучшается... или не улучшается, смотря насколько большая необходимость.
Опять же биология... эволюция.
Было бы конечно интересно поставить себе на службу законы эволюции... но чтой-то сомнительно что это возможно... это все равно что поставить себе на службу энтропию. :)
А про "паттерн", у вас действительно упущено кое-что... рассуждая "в общем", с архитектурной точки зрения, вы упускаете из виду кое-какие мелкие, но очень существенные технические технические детали.
Это то, почему не работает голая архитектура, в виде формализации или там теории систем. Всегда оказывается, что нужен, необходим "механик" как в том анекдоте про чукчу-часовщиках и таракана в часах -- реальный обычный инженер, который может совсем не знает теориев, но зато печенкой чувствует как застваить вот эту хреновину работать.
...и опять грешу :)