Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет Misha Verbitsky ([info]tiphareth)
@ 2007-01-17 09:45:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Настроение: sick
Музыка:Damo Suzuki - IN THE NIGHT
Entry tags:dos, igry, linux

dosbox последней версии
А между прочим, dosbox последней версии (0.65) поддерживает,
кажется, все вообще досовские игры, по крайней мере
те две игры, которые я доселе не мог запустить
(Master of Orion II и Conquest of the New World)
на новой версии досбокса прекрасно ходят. На Win XP,
что забавно, с немалыми проблемами, и их теперь
запускают только через досбокс.

Линукс неожиданно оказался очень продвинутой игровой
платформой, и в общем гораздо более удобной, чем Виндовз.
По крайней мере для людей, которые думают, что досовские игры
лучше (а это в общем достаточно распространенная
позиция - среди линуксоидов, я думаю, доминирующая).

Забавно.

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

Это, кстати, основной источник всех человеческих
бед и напастей, от Путина и до Буша. Капиталистам
выгодно превращать людей в идиотов, и они не покладая
рук этим занимаются. Вот почему в школах собираются
преподавать религию вместо дарвинизма? Потому что
это выгодно. Человек глупый и послушный - это не
только идеальный гражданин репрессивного государства.
Это еще и идеальный потребитель.

Привет



(Читать комментарии) - (Добавить комментарий)


[info]mc6312.livejournal.com
2007-01-17 15:54 (ссылка)
как было б хорошо, если у нас были медленные компы
Ага, как было бы хорошо физикам, архитекторам, фотографам и еще много, много кому.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-17 15:58 (ссылка)
ассемблеры есть не зависящие от железа
java-байткод, msil

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-17 17:21 (ссылка)
Тормоза и прожорливость явовских и дотнетовских приложений общеизвестны.
И в обозримом будущем им быстрее нативных приложений не стать.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-17 18:08 (ссылка)
хуйня

ява действительно медленней, и быстрее ей не стать
а вот дотнет - пиздёж, я лично замеры делал
на простых вычислительных тестах не более 10% потерь производительности
по сравнению с нативным кодом, за остальным флеймом - на rsdn.ru

теоретически платформонезависимый ассемблер должен быть быстрее нативного кода
пока не обогнал по скорости нативные приложения, это да
но в будущем нативный код отсосёт

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-17 19:33 (ссылка)
Каким образом он будет быстрее, если все равно транслируется в нативный машинный код? В лучшем случае - догонит...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]joppux.livejournal.com
2007-01-17 19:52 (ссылка)
За счет анализа динамики выполнения кода, невозможного в случае статической генерации. Например, инлайнить наиболее часто вызывающиеся методы.

(Ответить) (Уровень выше)


[info]phantom
2007-01-17 19:54 (ссылка)
это правильный вопрос
объясняю

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

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

платформонезависимый ассемблер + правильный JIT-компилятор может уделать
нативный код, как деда внука

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-17 22:32 (ссылка)
нативный код, генерящийся существующими компиляторами,
ориентирован на стандартную х86 архитектуру, то есть,
он по определению не может использовать специализированные инструкции,
типа SSE, MMX, 3DNow и т.д.,


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

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


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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-17 23:01 (ссылка)
>ЕМНИМС, интеловский сишный компилятор умеет как минимум SSE.

ну и что?
повторяю, ты будешь компилить под обобщённую х86 архитектуру,
а если ты будешь компилить под SSE, работать прога будет -
только под SSE

>про шибко умные JIT-компиляторы я слышу уже лет 10 минимум.

и что?
вот джава - старый джит-компилятор, работает медленно
джит от микрософта - более новый, работает быстро
сортировка массивов - 10% потери скорости от С++ максимум

потихоньку прогресс движется

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-18 09:31 (ссылка)
а если ты будешь компилить под SSE, работать прога будет -
только под SSE


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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-18 13:30 (ссылка)
> И что? Может, мне еще беспокоиться об совместимости с оригинальным 386-м, х.з. когда снятым с производства?

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

если ты будешь компилить только под 64 архитектуру,
даже хотя бы только под pentium 4,
никто твоей программой пользоваться не будет.

потому что у людей amd, pentium 3, и т.д.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-18 14:19 (ссылка)
ты что, надо мной издеваешься?
если ты компилишь в нативном компиляторе, он тебе по умолчанию выставляет максимальную совместимость

:))))
Про то, что компиляторы имеют настройки, ты не слышал?

даже хотя бы только под pentium 4,
никто твоей программой пользоваться не будет.
потому что у людей amd, pentium 3, и т.д.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-18 14:26 (ссылка)
> Про то, что компиляторы имеют настройки, ты не слышал?

нет блядь, не слышал

> Даже если так - почему автор программы не может предоставлять несколько бинарников (под разные процессоры, в данном случае - чистый 386, чистый пентиум, +SSE и т.п.)?

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

я не пойму, тебе что от меня надо?
1)попиздеть, 2)что-то узнать
или 3)задавить меня интеллектом?

зря пиздеть мне некогда

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-18 15:12 (ссылка)
эти бинарники генерирует автоматически джит-компилятор и создаёт из них native images, улавливаешь мысль?

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

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

(Ответить) (Уровень выше)


[info]polter
2007-01-18 06:06 (ссылка)
В теории. На практике с этим как-то не очень весело, хотя сказки про шибко умные JIT-компиляторы я слышу уже лет 10 минимум.

Я не знаю что и где вы слышали, но где звон, определенно не знаете.
Даже Java уже в общем по скорости давно от нативного кода не сильно отличима.
А вот LLVMM, цитирую: The JIT compiler is capable of optimising unnecessary static branches out of a program at runtime, and is therefore useful for cases where a program has many options, most of which can easily determined unnecessary in any environment. Because of this, it is used in the OpenGL pipeline of Mac OS X 10.5 ("Leopard") to provide support for missing hardware features.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-18 09:28 (ссылка)
Даже Java уже в общем по скорости давно от нативного кода не сильно отличима.
Только жабьих приложений, которые не тормозили бы там, где нативные летают, я еще не видел.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-18 09:41 (ссылка)
Ну, видимо, вы видели мало приложений на Java
К тому же, "тормозили" и "летают" - это субъективные характеристики.

вот здесь все более-менее объективно: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=java&lang2=gpp
В среднем отставание от С++ не больше, чем в 1,5 раза

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-18 14:20 (ссылка)
Хехе. Для какого-нибудь офисного пакета и 2 раза не катастрофа. А для графического редактора, или расчетной программы?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-18 14:38 (ссылка)
Вас по-моему куда-то не туда уже заносит. О чем речь вообще была - о JIT, а не о том для чего нужно и можно использовать Java.
А конкретно JIT используется для ускорения OpenGL в Mac OS X.

Аминь.

(Ответить) (Уровень выше)


[info]honeyman.livejournal.com
2007-01-17 22:41 (ссылка)
> нативный код, генерящийся существующими компиляторами,
> ориентирован на стандартную х86 архитектуру, то есть,
> он по определению не может использовать специализированные
> инструкции, типа SSE, MMX, 3DNow и т.д.,
> иначе код не сможет запускаться на х86 железе,
> не поддерживающим эти расширения

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

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-17 23:18 (ссылка)
>> платформонезависимый ассемблер + правильный JIT-компилятор может уделать нативный код, как деда внука
> Вам слова "emerge world" ни о чём случайно не говорят?

я Линукса не знаю, но я его люблю

(Ответить) (Уровень выше)


[info]honeyman.livejournal.com
2007-01-17 22:23 (ссылка)
> > как было б хорошо, если у нас были медленные компы
> Ага, как было бы хорошо физикам, архитекторам, фотографам и еще много, много кому.
Красноглазым линуксоидам, сидящем в tty-консольке в mutt-е.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-17 23:16 (ссылка)
>> ассемблеры есть не зависящие от железа
> Си и Си++, ага.
C, C++ - это языки высокого уровня, а не ассемблеры

в остальном ни хуя не понял
где утверждение в твоем тексте?
что говнокодеры существуют? это очевидно
что есть лучшие языки чем С++? я в курсе

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]honeyman.livejournal.com
2007-01-18 00:10 (ссылка)
> > Си и Си++, ага.
> C, C++ - это языки высокого уровня, а не ассемблеры

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

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

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

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

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

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

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-18 00:48 (ссылка)
> Язык, в котором перенос приложения с 32-битной системы на 64-битную занимает хрен-знает-дофига человекомесяцев вместо простейшей перекомпиляции, языком высокого уровня называться не достоин.

интересная дискриминация языков
я так понимаю, языков высокого уровня ещё нету в природе?

> Я понял, главные мысли надо будет выделять болдом, а то многа букав

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

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

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

> В век...

когда космические корабли бороздят сцену Большого Театра...
хм... я так понял, ты живёшь завтрашним днём, это замечательно
главное, помни, что сегодня достаточно устаревших средств для 90% задач

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]honeyman.livejournal.com
2007-01-18 01:33 (ссылка)
> я так понимаю, языков высокого уровня ещё нету в природе?
Ну почему же. Шелл-скрипты вполне одинаково работают на 32-битном и 64-битном линуксе. Надо ещё Perl и Python попробовать, но думаю, проблем не будет.

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

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

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

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

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

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-18 14:01 (ссылка)
> я так понимаю, языков высокого уровня ещё нету в природе?
> Ну почему же. Шелл-скрипты вполне одинаково работают на 32-битном и 64-битном линуксе.

ещё на Виндозе, угу
охуенная переносимость

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

что только? начал - договаривай

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

имелось в виду текстовое представление msil (microsoft intermediate language)
и платформонезависимые машинные коды тоже
на этот уровень спускаться иногда надо - например, тем, кто отлаживает компилятор
и этот уровень имеет смысл, иначе его бы вводить не стали
о времени работы компиляторов ты сморозил хуйню
ресурсы делятся на память и мегагерц, мегагерцы скоро закончатся, память будет расти
поэтому на второе можно положить хуй

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

это всё хуйня и грязь
автоматизация Макдональдсов и индустрия развлечений
в правильном программировании, как начали 50 лет назад решать опр. задачи
так они и решаются до сих пор, и те же проблемы стоят
вычислительная математика, теория графов, робототехника и т.д.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]honeyman.livejournal.com
2007-01-18 14:51 (ссылка)
> > Ну почему же. Шелл-скрипты вполне одинаково работают на 32-битном и 64-битном линуксе.
> ещё на Виндозе, угу охуенная переносимость
А что, ничего переносимость. На линуксах под пару десятков нехило различающихся платформ, да на десятке проприетарных юниксов, на которые портированы интерпретаторы шелла. Ну, и ещё на Windows. Куда уж больше...

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

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

(Ответить) (Уровень выше)


[info]polter
2007-01-18 05:55 (ссылка)
я так понимаю, языков высокого уровня ещё нету в природе?

Haskell, O'Caml, Java (с натяжкой)
на самом деле, их дохуя, конечно.


(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]phantom
2007-01-18 13:45 (ссылка)
это был стёб
тем, кто считает, что какие-то языки "достойны" называться высокоуровневыми
а другие - нет
тому надо прочесть определение на википедии

да и спорить об этой терминологии - всё равно что
семечки на лавочке лузгать

(Ответить) (Уровень выше)


[info]joppux.livejournal.com
2007-01-17 19:44 (ссылка)
Дык ЛИСП-машины как раз и умерли из-за развития стандартной архитектуры.
Джавский JIT генерит весьма хороший код, вот памяти жрет много конечно.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-17 22:33 (ссылка)
...а как становится весело, когда она кончается и просыпается сборщик мусора...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-18 05:57 (ссылка)
Как весело становится? Вы вообще в курсе как GC у той же явы работает?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-18 09:38 (ссылка)
Мне совершенно по барабану, как он работает внутри.
Мне так же по барабану, с какой скоростью бегают тесты.
Всякие угробища вроде Idea - тормозят, причем невооруженным глазом видно зависимость скорости работы от объема отожранной памяти.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-18 09:50 (ссылка)
GC-то тут при чем?
Зависимость скорости от объема занятой памяти существует из-за того, что часть памяти начинает скидываться на ЖД.
Совершенно любое приложение начнет тормозить.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mc6312.livejournal.com
2007-01-18 14:26 (ссылка)
"При чем" тут не сколько сам GC, сколько ублюдский подход к программированию, подразумевающий "бери памяти сколько хошь и не освобождай, пущай GC напрягается".
"Совершенно любое" нативное приложение обычно (если программист был не индус) освобождает отожранный кусок памяти сразу после того, как он уже не нужен.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-18 14:42 (ссылка)
сколько ублюдский подход к программированию, подразумевающий "бери памяти сколько хошь и не освобождай, пущай GC напрягается".

Чем он ублюдочный-то?
Ну кроме того, что отложенное освобождение памяти работает быстрее и вообще экономит ресурсы. Так же как и пакетная передача данных, конвеерное выполнение инструкций и т.п.
Вы бы почитали, что ли, что-нибудь по теме. Начинать можно отсюда: http://www.memorymanagement.org/

(Ответить) (Уровень выше)


[info]asox.livejournal.com
2007-01-18 12:22 (ссылка)
>>как было б хорошо, если у нас были медленные компы

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

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

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

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

фотографам

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

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

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

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-18 13:05 (ссылка)
> Ну, Бонбу сделали вообще без компьютеров

Неправда. В частности, Фейнман пишет такое:

Anyway we decided that the big problem—which was to figure out exactly what happened during the bomb’s implosion, so you can figure out exactly how much energy was released and so on—required much more calculating than we were capable of. A clever fellow by the name of Stanley Frankel realized that it could possibly he done on IBM machines. The IBM company had machines for business purposes, adding machines called tabulators for listing sums, and a multiplier that you put cards in and it would take two numbers from a card and multiply them. There were also collators and sorters and so on.
...
So Frankel figured out a nice program. If we got enough of these machines in a room, we could take the cards and put them through a cycle.


> зато за последние 10 лет, с расплодившимися кругом пнями - ни.уя никаких открытий нету.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kaledin
2007-01-19 01:41 (ссылка)
Genomy, ugu. A vot eshche mozhno perepisat' vsekh tadzhikov na strojakh i pereschitat' vse kamni s mosta Lejtenanta Shmidta. A nahuya?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-19 01:51 (ссылка)
Для последующей модификации?
производство лекарств, исправление дефектов, уничтожения сельского хозяйства.
Или в каком смысле нахуя?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kaledin
2007-01-19 02:00 (ссылка)
Chistoj vody p.r. project -- napravlen na vysasyvanie grantov, kak i vse v amerikanskoj nauke. Proizveli za kakim-to khrenom kuchu neuporyadochennoj informacii; kak interpretirovat', neponyatno. Nikakikh primenenij vrode by ne imeet.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-19 02:24 (ссылка)
Какой конкретно проект - человеческий геном?
Выяснили количество и расположение человеческих генов - что кодирует и для чего известно, разумеется, пока для небольшой части. Но, по крайней мере, теперь ясно что и где искать.
Да и эти данные много стоят, по крайней мере стало ясно насколько человек отличается от курицы и удава.
И человеческим геномом все не ограничиваются. С вирусами и бактериями та же фигня.
Да и проекты такие, кстати, в основном интернациональные - даже американцам такое полностью не осилить.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kaledin
2007-01-19 02:32 (ссылка)
Amerikancy platyat osnovnye babki, i potomu zadayut ton.

Gennaya karta cheloveka sushchestvuet let 30 kak; po krajnej mere, uchas' v srednej shkole, ya ee videl na stene v kabinete v kachestve naglyadnogo posobiya. V proekte genom vyyasnena posledovatel'nost' nukleotidov. Nahuya? Net otveta. Vy ponimate, ya nadeyus', chto 90% ehtogo dela ehto introny.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-19 02:41 (ссылка)
Так смысл всего этого дела в том и есть, чтобы выделить кодирующие последовательности из того мусора, что 90%. Чтобы потом узнать что они собственно кодируют.

Конспирология прямо какая-то...


(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kaledin
2007-01-19 02:45 (ссылка)
Vo-vo; puskaj vydelyayut. Khren vydelyat. Nafiga -- babki uzhe polucheny.

(Ответить) (Уровень выше)


[info]asox.livejournal.com
2007-01-24 08:35 (ссылка)
> Ну, Бонбу сделали вообще без компьютеров

Неправда.

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

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

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

[...]

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

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

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

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2007-01-24 09:36 (ссылка)
>> А па-русски этого текста нетути? Ну мне очень ломы переводить с инглиша.


Ну, в общем, мы все решили, что самая главная задача - понять точно,
что именно происходит во время взрыва бомбы, чтобы можно было точно указать,
сколько выделяется энергии и т.д., - требовала намного больше выкладок, чем
мы могли делать. Но один умный человек по имени Стэнли Френкель сообразил,
что вычисления, возможно, удастся сделать на машинах IBM. Компания IBM
выпускала машины для бизнеса - устройства для сложения, называемые
табуляторами, и машины для умножения - мультипликаторы, в которые можно было
закладывать карточки: машина считывала два числа с карточки и умножала их.
Были также устройства, которые сличали числа, сортировали их и т.д.
И вот Френкель придумал замечательную программу. Если бы мы собрали
довольно много таких машин в одной комнате, то мы смогли бы взять карточки и
запустить их по циклу.

http://www.lib.ru/ANEKDOTY/FEINMAN/feinman.txt

>> Сначала шёл разговор о физике, теперь плавно перешли к "геномам".

А что, научно-технический прогресс измеряется только физикой?
И биофизика, кстати, не физика?

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

Отличный физик. А период его активной деятельности как раз пришелся на расцвет выч. техники и информатики. И сам Мр. Фейнман был активным сторонником развития компьютеров, писал на эту тему книжки и даже придумал такую штуку, как квантовые компьютеры.

>> А в случае генома "понять" - это сказать "вот этот кусок текста означает, что у объекта будут кривые руки..."

Разумеется. И вот чтобы это понять, необходимы совершенно бешеные выч. ресурсы.
Ну и половина пути уже кстати пройдена благодаря им.

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

Смотря что с чем сравнивать. Пленке проигрывает 24 bit RGB, когда по 8 бит на канал. Фотоаппараты, по крайней мере профессиональные, снимают не в нем.
Это не считая всяких технологий типа HDR imaging.

(Ответить) (Уровень выше)


(Читать комментарии) -