133 ответов в теме

[tes3]

ккригер основан на графических библиотеках directX, и его размер вовсе не показатель качества
с таким то расходом оперативы

[Ariru]

вау ты нас всех просвятил!

[DarkPhoenix]

Вот если бы я мог в пустую х86 машину вставить дискету, на которую записано 97кб, и поиграть в этот ккриегер - да, это было бы шикарно.

[z4gnom]

нормальный расход оперативы, там текстуры генерятся отнюдь не 256*256

ну это не повод оперативу засерать

[deadok]

Что слишком? Тебе привели уже один из примеров, где язык высокого уровня лучше чем асм за счёт распараллеливания.

простите, а что вы подразумеваете под распараллеливанием? видимо явно не разгрузку работы по тредам, оно то в асме делается столь-же тривиально, как и в любом другом языке программирования, а-ля ... call CreateThreadEx и тд

Нет, ну ты правда думаешь, что (пусть ты изучил бы там асм до конца под процессор) асилишь трансляцию с функцинального языка SQL в ассемблер? А не надорвёшься?

"изучение до конца" требуется для расчистки ботлнеков. e.g. если не знать о механизме работы процессора - разворачивание циклов может показаться сущим бредом.
и что энто еще за "трансляция с sql в асм"?
видимо ты имеешь ввиду написание самого сервера? таки парсинг sql запросов - это мелочь, а самое интересное там в построении эффективного механизма работы с базой и опять-таки расчистке узких мест.

[Pointer]

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

Ты не так понял.
SQL server это среда.
Я пишу в этой среде запрос на функциональном языке sql.
Этот запрос может быть простой на несколько строчек и на его написание мне потребуется несколько минут.
А может быть на несколько десятков или сотен строчек и я затрачу на него несколько часов.

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

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

Сейчас для домашних компов это не так актуально, а вот лет через 5, когда в процессоре будет не 2-4 ядра, а по сто ядер, тогда разговоров про быстрый ассемблер будет намного меньше.

Сообщение отредактировал Pointer: 15 January 2009 - 4:28

[deadok]

...

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

[Ariru]

хватит говорить умными словами!

[deadok]

иди куте ушки крути

[Pointer]

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

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

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

Хорошо, скажу проще.
Тем, что на асме ты пишешь под определенную железку. И если я завтра заменю процессор на новый, у которого будет в 10 раз больше ядер, но частота вдвое меньше, то программа на асме будет работать медленнее, а хорошо распараллеливаемый код на функциональном языке будет работать в 5 раз быстрее, т.к. среда выполнения сгенерирует новый процессорный код на его основе.
Почти не в тему, но зато простым языком и с примерами и про мой любимый жабаскрипт :
А ваш язык программирования так может?


зы: и да, sql сложно назвать чисто функциональным, тем более всякие tsql, plsql и т.д., это я для красного словца, не пинайте ногами.

Сообщение отредактировал Pointer: 15 January 2009 - 10:17

[deadok]

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

во первых схуали? или многопоточность - это прерогатива языков высокого уровня?
во вторых переносимость - это проблема кода/среды, а не языка, кто дал тебе гарантию, что на этой новой машине будет работать твой JIT compiler, или тот-же скуель. может завтра ваще микрософт с интелом загнутся, и прости-прощай весь MS-SQL.

кстате асм может все укзанное по ссылке

[Argonicus]

А на Си точно будет лучше, может, тебя обманули?

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

Что слишком? Тебе привели уже один из примеров, где язык высокого уровня лучше чем асм за счёт распараллеливания.

Нет, ну ты правда думаешь, что (пусть ты изучил бы там асм до конца под процессор) асилишь трансляцию с функцинального языка SQL в ассемблер? А не надорвёшься?

Поясняю, там где АСМ молча просчитает и не подвесит машину, SQL положит ось. Ибо убог по сути своей. Да там писать код удобно, просто, но работает криво. Мне как человеку который програмировал микроконтролеры (как в той истории про програмера однокристалок) языки высокого уровня унылое Г ибо закрывают доступ ко многим очень полезным вещам. Вввиду своей якобы самооптимизации. И напиши мне на SQL приложение реального времени, с макс задержкой в 3 мили секунды и я на тебя молиться буду...

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

Да согласен лучше я буду тратить сотни баксов ежегодно чем народ уволит мудаков неспособных писать грамотный код. Конечно, ты абсолютно прав. Зачем учить людей если можно тупо заткнуть ошибки мощностью железа. Ничего что мощность блоков питания приближается килоВату, что воет такой комп как не в себя и греет воздух вокруг себя. Но есть одно маленькое но, ОС и дрова тоже кривые, пишут-то их теже криворукие програмеры. И что в результате, у нас кривая ОС, в следствие чего лагают приложение, написанные грамотно и красиво, и все это понимая не вылизывают код, а лишь тупо патчат основные дыры...

[deadok]

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

C потенциально быстрее != однозначно быстрее. Ибо JIT в настоящее время есть только микрософтовскый, а писать оптимизацию под все варианты ядер - это сетки жопа полная.

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

[Pointer]

во первых схуали? или многопоточность - это прерогатива языков высокого уровня?

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

Поясняю, там где АСМ молча просчитает и не подвесит машину, SQL положит ось. Ибо убог по сути своей. Да там писать код удобно, просто, но работает криво. Мне как человеку который програмировал микроконтролеры (как в той истории про програмера однокристалок) языки высокого уровня унылое Г ибо закрывают доступ ко многим очень полезным вещам. Вввиду своей якобы самооптимизации. И напиши мне на SQL приложение реального времени, с макс задержкой в 3 мили секунды и я на тебя молиться буду...

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

И это я еще не работал с многотербабайтными базами с десятками тысяч одновременных клиентов. А есть и такие.

Гений, млин, сравнил, микроконтроллеры и промышленную или банковскую базу данных.

[Rainbow Hunter]

Когда то Билли сказал (дословно не помню): Никогда компьютеру не понадобиться более чем 640Кб памяти.
Может он был прав?

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

[Fandanguero]

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

[DeadMazay]

Кому боян, кому нет. Учитывая обьем инфы в инете или темпы ее увеличения, многие вещи не замечаешь.

Да и вообще тема пошла о современных тенденциях программирования.
Комент прикольный нашел:"Паскаль и Бейсик по-своему неплохие языки, только не пригодятся они при решении практических задач. Конечно, на Delphi (32-разрядная расширенная версия Паскаль) пишутся промышленные системы, но делается это программистами, которые так и не смогли избавиться от своих школьных привычек."

[deadok]

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

ты наверное удивишься, но распараллеливание это стандартная методика улучшения производительности даже на 1-процессорных машинах.
и проверить количество доступных ядер и запустить соотв-ее число потоков - тоже не рокет сайнс