гена - идиотское имя, крокодил ты ебучий

соси заочно

как было б хорошо, если у нас были медленные компы
Ага, как было бы хорошо физикам, архитекторам, фотографам и еще много, много кому.

развивался бы Forth, Lisp, Smalltalk, все бы знали ассемблер
Форт - возможно. Ассемблер? Прощай, переносимость. Ну да, программы были бы чертовски мелкие и шустрые. Взамен пришлось бы каждую софтину писать практически с нуля для переноса на какое-то другое железо.
Лисп и смоллток, ЕМНИМС, очень память кушать любят, да и от быстродействия избыточного не страдают.

Тормоза и прожорливость явовских и дотнетовских приложений общеизвестны.
И в обозримом будущем им быстрее нативных приложений не стать.

Каким образом он будет быстрее, если все равно транслируется в нативный машинный код? В лучшем случае - догонит...

За счет анализа динамики выполнения кода, невозможного в случае статической генерации. Например, инлайнить наиболее часто вызывающиеся методы.

нативный код, генерящийся существующими компиляторами,
ориентирован на стандартную х86 архитектуру, то есть,
он по определению не может использовать специализированные инструкции,
типа SSE, MMX, 3DNow и т.д.,

ЕМНИМС, интеловский сишный компилятор умеет как минимум SSE.

JIT (just in time)-compiler знает об архитектуре компьютера юзера всё,
и компилирует код на лету (или заранее - native images) в оптимизированный под данный тип процессора

В теории. На практике с этим как-то не очень весело, хотя сказки про шибко умные JIT-компиляторы я слышу уже лет 10 минимум.

а если ты будешь компилить под SSE, работать прога будет -
только под SSE

И что? Может, мне еще беспокоиться об совместимости с оригинальным 386-м, х.з. когда снятым с производства?

ты что, надо мной издеваешься?
если ты компилишь в нативном компиляторе, он тебе по умолчанию выставляет максимальную совместимость
:))))
Про то, что компиляторы имеют настройки, ты не слышал?

даже хотя бы только под pentium 4,
никто твоей программой пользоваться не будет.
потому что у людей amd, pentium 3, и т.д.
Подразумевается, что люди используют только и исключительно уже скомпилированные программы?
Даже если так - почему автор программы не может предоставлять несколько бинарников (под разные процессоры, в данном случае - чистый 386, чистый пентиум, +SSE и т.п.)?
Зачем делать на машине каждого конечного пользователя то, что может быть сделано один раз?
Архитектур

эти бинарники генерирует автоматически джит-компилятор и создаёт из них native images, улавливаешь мысль?

Для тех, кто в танке: а нахрена это делает JIT-компилятор на машине каждого пользователя, когда это может сделать один раз "обычный" компилятор на машине программиста?

зря пиздеть мне некогда
Слив засчитан?

Даже Java уже в общем по скорости давно от нативного кода не сильно отличима.
Только жабьих приложений, которые не тормозили бы там, где нативные летают, я еще не видел.

Хехе. Для какого-нибудь офисного пакета и 2 раза не катастрофа. А для графического редактора, или расчетной программы?

> нативный код, генерящийся существующими компиляторами,
> ориентирован на стандартную х86 архитектуру, то есть,
> он по определению не может использовать специализированные
> инструкции, типа SSE, MMX, 3DNow и т.д.,
> иначе код не сможет запускаться на х86 железе,
> не поддерживающим эти расширения

А писали существующие компиляторы исключительно студенты-недоучки, нифига не знающие про возможность runtime-определения возможностей процессора и вызова соответственно оптимизированных реализаций функций.
Об одном вас прошу - не говорите о невозможности использования специализированных инструкций моему компилятору GCC 4.1 (знаю, старьё). А то он при компиляции OGG-encoder-а с оптимизацией под мой процессор перестанет делать в два раза более производительный бинарник, чем при компиляции под i386.

> платформонезависимый ассемблер + правильный JIT-компилятор может уделать нативный код, как деда внука
Вам слова "emerge world" ни о чём случайно не говорят?

> > как было б хорошо, если у нас были медленные компы
> Ага, как было бы хорошо физикам, архитекторам, фотографам и еще много, много кому.
Красноглазым линуксоидам, сидящем в tty-консольке в mutt-е.

> ассемблеры есть не зависящие от железа
Си и Си++, ага.
Только вся беда как раз в том, что... низкого уровня описания алгоритма, предоставляемого этими "платформонезависимыми ассемблерами", уже не хватает. Взять хотя бы полное отсутствие описания параллелизуемости алгоритмов (ну, OpenMP можно, конечно, в качестве костыля использовать), весьма зловредное в век двуядерных (а то и четырёхядерных) процессоров. Или отсутствие встроенной в язык возможности описания многопоточности - это сказывается уже не только на многоядерниках, но скорее на любых системах, пытающихся хоть сколь-нибудь выползти за пределы узких штанишек архитектуры i386. Например, для шейдеров. Или, ещё лучше, для Cell. Вот попомните моё слово - Cell помрёт из-за говнокодеров, увязших в C++ и неспособных мыслить за его пределами.

> > Си и Си++, ага.
> C, C++ - это языки высокого уровня, а не ассемблеры

Вы не одиноки в этом маркетоидном заблуждении.

Язык, в котором перенос приложения с 32-битной системы на 64-битную занимает хрен-знает-дофига человекомесяцев вместо простейшей перекомпиляции, языком высокого уровня называться не достоин.

> в остальном ни хуя не понял
> где утверждение в твоем тексте?
Я понял, главные мысли надо будет выделять болдом, а то многа букав. «Только вся беда как раз в том, что... низкого уровня описания алгоритма, предоставляемого этими "платформонезависимыми ассемблерами", уже не хватает.»

В век P2P-систем, многоядерных процессоров и видеоускорителей, более мощных, чем компьютеры в ЦУПах первых космических полётов, народ с помощью компьютеров начал решать всё более и более сложные задачи. (Примеры: поиск внеземной жизни. Ну, или игра в управление автомобилем, "совсем как настоящим").
Которые только для того, чтобы быть решёнными, требуют всё более и более сложных инструментов для их решения. (Примеры: статистический анализ, лет 20 назад бывший доступным только серьёзным компьютерным центрам. Ну, или автосимуляторы с достойной современного уровня физикой автомобиля и детальностью трасс. Опять же, лет 20 назад доступные только серьёзным компьютерным центрам. Если вообще доступные.)
Которые, только для того, чтобы быть написанными, требуют всё более и более высокоуровневых языков программирования.
Потому что с помощью ассемблера Оракл не напишешь.
Не, вообще не напишешь.
Даже если сто тысяч программистов посадить. "Мифический человеко-месяц" Брукса.
Даже если одного программиста на двадцать лет посадить решать - всё равно не напишешь. Потому что сложность программы с её ростом растёт не линейно по отношению к её росту, а линейно по отношению к количеству связей в ней. Ну, для простоты, можно считать, что экспоненциально по отношению к росту.

Из песка совочком можно налепить куличиков. Или построить песочный домик. Только не то что небоскрёб - пятиэтажку совочком уже не построить. Потому что там уже другие материалы, другие взаимосвязи между ними... уже у пятиэтажки слишком много отличий от песочного домика. А небоскрёб будет существенно отличаться и от пятиэтажки.

Даже если совочек сделать таким, что он сможет работать с бетоном, и им можно будет даже поддевать кирпичи - он останется совочком. Для решения фигурных "совочечных задач".

Ассемблер - это совочек. Платформонезависимый ассемблер - это универсальный совочек.

> я так понимаю, языков высокого уровня ещё нету в природе?
Ну почему же. Шелл-скрипты вполне одинаково работают на 32-битном и 64-битном линуксе. Надо ещё Perl и Python попробовать, но думаю, проблем не будет.

> я нигде не мог спиздеть, что нужно программить на ассемблере
Что ж, это уже лучше. Только...

> я лишь объяснял, почему платформонезависимый ассемблер - шаг вперёд
> он занимает свою ступень в качестве прослойки в иерархии средств программирования
> на него сверху водружаются платформонезависимые языки
Я так понял, что имелось в виду скорее что-то "платформонезависимого машинного кода". Ибо ассемблер - это всё-таки human-readable представление машинного кода, а человеку на этот уровень спускаться вовсе и не надо. Меня слово "ассемблер" в данном случае смутило.

Впрочем, это не лучше. Платформонезависимый машинный код, будь то IL, Java bytecode или ещё что-то подобное, как самоцель тоже смысла не имеет. Проинлайнить вызов функции современный компилятор и так способен догадаться, а дополнительный код, собирающий статистику вызова методов, будет жрать весьма немало ресурсов. При таки достаточно сомнительной от него пользе.
Но при этом на этапе компиляции компилятору ЯВУ доступно гораздо больше информации, чем интерпретатору промежуточного кода. И больше времени, ага - компилятор во времени особо не ограничен, а интерпретаторокомпилятор промужеточного кода должен работать в какие-нибудь конечные разумные сроки.

> что касается прогресса в отношении новых ставящихся задач,
> нету усложнения алгоритмической сложности, и не было особо за последние 30 лет,

Ну смотря какого усложнения вы ищете. Вы примерно внутренности последних СУБД Oracle-а представить можете? А как вам рендереры фотореалистичных картинок, работающие нынче чуть ли не в реальном времени в компьютерных игрушках, а 30 лет назад... кхм, вообще только начинавшиеся (http://en.wikipedia.org/wiki/Timeline_of_CGI_in_films#1970s)? А в современных "властелинах колец" не просто векторную картинку скриптуют, а создают модели бегущих толп...

> есть растущий масштаб разрабатываемых программных систем, и ничего более
А в общем-то, это и есть проблема. Самая большая. Создать систему в тысячу строк исходного кода - это одно. Создать систему в сто тысяч строк - это уже совершенно другое. И при создании такой системы первостепенными будут совершенно другие проблемы, в проектировании будут совершенно другие приоритеты... Проблемы не просто создания "работающих кусков кода", а проблемы разбиения системы на независимые блоки, взаимодействия этих блоков.

> > Ну почему же. Шелл-скрипты вполне одинаково работают на 32-битном и 64-битном линуксе.
> ещё на Виндозе, угу охуенная переносимость
А что, ничего переносимость. На линуксах под пару десятков нехило различающихся платформ, да на десятке проприетарных юниксов, на которые портированы интерпретаторы шелла. Ну, и ещё на Windows. Куда уж больше...

> > СУБД Oracle-а представить можете? А как вам рендереры фотореалистичных картинок, работающие нынче чуть ли не в реальном времени в компьютерных игрушках

> это всё хуйня и грязь
"В женской логике каждое утверждение может быть не только опровергнуто, но и отвергнуто." Вопросов больше не имею.

Дык ЛИСП-машины как раз и умерли из-за развития стандартной архитектуры.
Джавский JIT генерит весьма хороший код, вот памяти жрет много конечно.

...а как становится весело, когда она кончается и просыпается сборщик мусора...

Мне совершенно по барабану, как он работает внутри.
Мне так же по барабану, с какой скоростью бегают тесты.
Всякие угробища вроде Idea - тормозят, причем невооруженным глазом видно зависимость скорости работы от объема отожранной памяти.

"При чем" тут не сколько сам GC, сколько ублюдский подход к программированию, подразумевающий "бери памяти сколько хошь и не освобождай, пущай GC напрягается".
"Совершенно любое" нативное приложение обычно (если программист был не индус) освобождает отожранный кусок памяти сразу после того, как он уже не нужен.

>>как было б хорошо, если у нас были медленные компы

Ага, как было бы хорошо физикам,

Ну, Бонбу сделали вообще без компьютеров - зато за последние 10 лет, с расплодившимися кругом пнями - ни.уя никаких открытий нету.
Зато у них многогигагерцовые КореДуро с ВыньХрю.

архитекторам,

"...архитектор Растрелли. Тяжело мучался без компьютера, создавая Зимний Дворец. Если бы не это он бы построил ещё Летний, Осенний, Весениий и Весенне-Осенний дварцы"

фотографам

"Сто лет фотографии" знаете когда отмечалось?
Наверное, когда ваша матушка пешком под стол ходила...

и еще много, много кому.

В основном губошлёпам из поколения пепси, только и способным,
что всунуть плату в щель - и крикнуть "Вау" когда plug-n-prey потребует под неё дрова.
В полной уверенности, что "это и есть сисадмин".

--
Всего наилучшего,
Андрей.

> Ну, Бонбу сделали вообще без компьютеров

Неправда.

"Неправда" - что?
Расскажите мне, пожалуйста, про компьютер у американцев в 1945м, а в СССР - в 1948м, ну очень хочецца.

В частности, Фейнман пишет такое:

А па-русски этого текста нетути? Ну мне очень ломы переводить с инглиша. И, кстати, - период активной деятельности "Мистера Фейнамана" как-раз пришёлся на время без "современных" компьютеров. Дяденька был плохой физик?

[...]

Как минимум - расшифровали кучу геномов, в т.ч человека.

Сначала шёл разговор о физике, теперь плавно перешли к "геномам". А с каких пор это "отсканировать и переписать на магнитный ноститель" стало эквивалентом "понять"? В моём представлении без понимания говорить о "расшифровке" однозначно нельзя.
А в случае генома "понять" - это сказать "вот этот кусок текста означает, что у объекта будут кривые руки..."

--
Всего наилучшего,
Андрей.

P.S. Кстати, неожиданно услышал в одной дискуссии, что цифровая фотография проигрывает плёночной в широте динамического диапазона. Так что далеко не все фотографы в восторге от компьютеров.

> Тогда программисты были бы отличимы от офисного шлака, развивался бы Forth, Lisp, Smalltalk, все бы знали ассемблер.

Чушь. В своё время Lisp как раз и проиграл Fortran-у потому, что Lisp был ориентирован на удобство программиста (за счёт ресурсов компьютера), а Fortran - на удобство компьютера (от простоты компилятора до большей скорости скомпилированных программ) за счёт программиста. Вот именно что расплодилась бы куча кодеров на ассемблере и си, а все ЯВУ бы были в упадке.

> Люди тратили бы на говно меньше времни.
Люди тратили бы на говно больше времени. Вместо создания интересных и полезных высокоуровневых алгоритмов анализа данных искали бы способы наиболее эффективного перегона байтиков из одной области памяти в другую. Знаем, проходили. Погонщики байтиков, блин.

А обработка видео и 3D графика?

Распараллеливается. Если кому-то нужно много ресурсов, то он может купить 10 компьютеров и организовать кластер.
Или процессоров докупить, если бы не развивали эту злоебучую x86, а сразу делали бы упор на risc, межпроцессорные связи и многоядерность, как сейчас вот начали (после того как выжали из говнох86 все деньги).