Компилируемый язык вместо javascript

Во-первых, почему в си неявный расход памяти выше, чем у ассемблера?

ну попробуй сложить два 128и битных числа в C кусками по 64 бита. Попробуй перемножить два 64х битных числа больших 2^32 каждое на 64х битной платформе. Попробуй найти первый ненулевой бит целого числа. Много чего ещё есть... Например массив структур, у которых 64х битное поле и 32х битное, при выравнивании 8 байт...

Некорректное сравнение, поскольку вы всегда можете открыть фалик размером 1К и убедится, что дело не в редакторе.

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

От размера в пикселях зависит, от размера в пикселях на экране - не зависит.

ну открой чЁрный экран 32000х20000 в браузере (в смысле - jpg такой, а не цвет фона).

ну открой чЁрный экран 32000х20000

имеется ввиду, что браузер сам масштабирует картинку скажем 320х200 -> 32000х20000

Ты чего сказать то хотел?

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

Ты, походу, свою первоначальную мысль уже потерял.

Точнее не свою, но потерял.

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

ну попробуй сложить два 128и битных числа в C кусками по 64 бита. Попробуй перемножить два 64х битных числа больших 2^32 каждое на 64х битной платформе. Попробуй найти первый ненулевой бит целого числа. Много чего ещё есть... Например массив структур, у которых 64х битное поле и 32х битное, при выравнивании 8 байт...

С этим соглашусь. Хотя не совсем. Программы пишутся в основном одновременно и под 32 и под 64 битную платформу сейчас, поэтому от этого плюсов никаких не будет.

ну открой чЁрный экран 32000х20000 в браузере (в смысле - jpg такой, а не цвет фона).

Открыл 6400х4000 в хромом, занимат 110 мег памяти. По 4 байта на пиксель, плюс накладные расходы, не вижу ничего странного?

Я бы врятли ругал JS, если бы я на нем писал.

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

Ответил на твой вопрос.

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

Но не на лоре, и не так коряво.

И на ЛОРе и может даже коряво, если они не лингвисты, зато по делу говорят, а так, как ты.

Паскаль - это хорошо.

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

Программы пишутся в основном одновременно и под 32 и под 64 битную платформу сейчас, поэтому от этого плюсов никаких не будет.

ну 32/64 это как раз непроблема, проблема будет с испорченной на 9 жизней вперёд кармой быдлокодера. Когда его быдлокод будут переписывать под _другую_ архитектуру.

Но суть в том, что накладных расходов в асме действительно _можно_ избежать. Ценой переносимости. В сишешке с переносимостью получше, но придётся кодить на очень низком уровне. В плюсах всё хорошо с уровнем, но таки есть накладные расходы. Причём если скорость разработки на плюсах как у какой-нить явы, то и накладных расходов столько же.

Открыл 6400х4000 в хромом, занимат 110 мег памяти. По 4 байта на пиксель, плюс накладные расходы, не вижу ничего странного?

дык и я про то говорю. А теперь расскажи это тем господам, у которых «winxp+64mb летает». Я им объясняю, что она ЛЕТАЛА, когда-то. На SVGA 800x600 максимум, да ещё и с 16и битным цветом, да и с web 1.0. А сейчас уже другое столетие.

ну 32/64 это как раз непроблема, проблема будет с испорченной на 9 жизней вперёд кармой быдлокодера. Когда его быдлокод будут переписывать под _другую_ архитектуру.

Даже под 32/64 это проблема, потому что программа не получит никаких преимуществ от 64 бит и одни недостатки. В принципе путем всяких извращений накладных расходов можно избежать и на си я думаю, хотя на си это будет гораздо сложнее чем на ассемблере.

дык и я про то говорю. А теперь расскажи это тем господам, у которых «winxp+64mb летает». Я им объясняю, что она ЛЕТАЛА, когда-то. На SVGA 800x600 максимум, да ещё и с 16и битным цветом, да и с web 1.0. А сейчас уже другое столетие.

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

Даже под 32/64 это проблема, потому что программа не получит никаких преимуществ от 64 бит и одни недостатки.

это не так. Кроме 64х битных указателей, в новых CPU ещё Over9000 разных вкусностей. А 64 бита - это не главное, просто для 64х битных приложений надо значительно ломать ВСЁ ПО, а другие фишки можно вводить так, что юзер этого и не замечает (чем давно и невозбранно пользуются гентушники, достигая часто значительного прироста быстродействия, тупо пересобирая всё ПО под свой конкретный камень)

Другое дело, что эффект от любой низкоуровневой фичи будет заметен лишь тогда, когда это будут учитывать кодеры этих либ.

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

тут дело всё в том, что на ассемблере просто выхода другого и нет. А вот в С (и особенно в С++) всё в твоих руках. Есть в С поля и объединения, т.ч. можно всегда упаковать что угодно, и куда угодно.

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

я говорил о том, что многие картинки браузер самостоятельно масштабирует до нужного (быдлодизайнеру) размера. Потому картинка в 10х10 может быть растянута браузером до 100х100, и при этом будет занимать в 100 раз больше памяти. Т.ч. «размер в пикселях» может отличаться (и отличается) от того, который у картинки изначально. ЧСХ обычно в большую сторону. ИЧСХ, при десятикратном увеличении размер увеличивается в 100 раз. Я уж не говорю о том, что увеличение - процесс очень сложный, и ресурсоёмкий, и потому браузер жрёт не только сотни метров памяти, но и миллиарды тактов CPU.

я говорил о том, что многие картинки браузер самостоятельно масштабирует до нужного (быдлодизайнеру) размера. Потому картинка в 10х10 может быть растянута браузером до 100х100, и при этом будет занимать в 100 раз больше памяти. Т.ч. «размер в пикселях» может отличаться (и отличается) от того, который у картинки изначально. ЧСХ обычно в большую сторону. ИЧСХ, при десятикратном увеличении размер увеличивается в 100 раз. Я уж не говорю о том, что увеличение - процесс очень сложный, и ресурсоёмкий, и потому браузер жрёт не только сотни метров памяти, но и миллиарды тактов CPU.

Я не думаю, что браузер масштабирует их сам, скорее всего он масштабирует каждый раз при выводе, причем не сами, а внутри библиотек(для firefox например cairo), большинство из которых поддерживают аппаратное ускорение операций масштабирования.

Я не думаю, что браузер масштабирует их сам, скорее всего он масштабирует каждый раз при выводе, причем не сами, а внутри библиотек(для firefox например cairo), большинство из которых поддерживают аппаратное ускорение операций масштабирования.

ну это уже вопрос десятый. Важно то, что нужно сотни метров и миллиарды тактов на это. И нефиг ныть - кому не нравиться - man lynx.

В сишешке с переносимостью получше, но придётся кодить на очень низком уровне.

Хоть сам понял, что сказал? Если писать на низком уровне, то как раз никакой переносимости не будет, для этого и придумали стандартную библиотеку С

Хоть сам понял, что сказал? Если писать на низком уровне, то как раз никакой переносимости не будет, для этого и придумали стандартную библиотеку С

почему «не будет»? смотря как писать.

Компилируемый язык вместо javascript

JS давнооо уже умеет компилироваться. Более того, даже в машинный код может: http://ru.wikipedia.org/wiki/V8_(движок_JavaScript)

Если ты имел в виду язык С вообще, то он не настолько низкоуровневый, как многие его описывают. А для кроссплатформенности используются кросплатформенные функции и библиотеки (SDL, libc)

JS давнооо уже умеет компилироваться. Более того, даже в машинный код может

Компиляция исходного кода JavaScript непосредственно в собственный машинный код, минуя стадию промежуточного байт-кода.

ZX-Spectrum BASIC компилировался в точности также, если ты забыл. Там тоже каждая команда переводилась в машинный код. Мало того, он даже покруче JS был, там были зайчатки байткода: Дело в том, что в спеке, каждый оператор хранился как ОДИН байт, и интерпретатор не парсил операторы, а просто брал программу в кодах по нужному адресу. Потом решили (во времена 8086), что это не нужно на новых быстрых CPU, и стали каждый оператор парсить. Потом решили, что парсить таки один раз всё-таки лучше, и придумали java с байткодом. Теперь вот в гугле решили, что CPU сейчас опять быстрые, и байткод не нужен, потом... Ну ты понял.

Если ты имел в виду язык С вообще, то он не настолько низкоуровневый, как многие его описывают.

я читал K&R, они заблуждаются?

А для кроссплатформенности используются кросплатформенные функции и библиотеки (SDL, libc)

Задумайся, на чём пишут эти библиотеки?

Эти библиотеки платформозависимы, а обращаемся мы к ним на всех платформах одинаково

ZX-Spectrum BASIC компилировался в точности также, если ты забыл.
Там тоже каждая команда переводилась в машинный код

Sinclair BASIC был сложной с точки зрения классификации штукой. По архитектуре среды исполнения он был чистым интерпретатором. Но посимвольного разбора исходника не было, так как все операторы кодировались одним байтом прямо в исходнике. Это можно условно считать «компиляцией» по мере ввода. Правда, компиляция — «на уровне пользователя». Вводились операторы не побуквенно, а сразу целиком. Так что, наверное, это интерпретатор, но не ASCII, а специализированного алфавита.

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

Другое дело, что под Спекки были Бейсики загружаемые, которые в машинный код вполне себе компилировали. Скажем, ZX Basic Compiler. Но они были непопулярны. Жрали много памяти, а эффективность была относительно сомнительная.

Если ты имел в виду язык С вообще, то он не настолько низкоуровневый, как многие его описывают.

я читал K&R, они заблуждаются?

Во времена K&R Си считался языком высокоуровневым.

Эти библиотеки платформозависимы, а обращаемся мы к ним на всех платформах одинаково

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

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

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

ох... слово «зайчатки» не заметил? Какая разница, как это всё вводилось? Суть в том, что даже в далёких 80х годах прошлого века применялось не чистое интерпретирование чистого текста, а выполнение некой заготовки, которая plain-text'ом не была, а была бинарником, более близким к машинным командам (и потому - более быстрым). В JS мы наблюдаем противоположную тенденцию: браузер получает plain-text, который напрямую транслируется в машинный код. Что в IE, что в хроме. Потому твоя цитата годна только для маркетологов и википедиков. Реальность такова, что для повышения быстродействия и оптимизации ресурсов следует транслировать текст в бинарный вид. Как в JIT'е например.

Ну а что до ввода, дык это просто для удобства - длинный оператор проще ввести одной кнопкой, а не десятью. Особенно учитывая, что операторы всё равно нужно будет свернуть в один «символ».

Другое дело, что под Спекки были Бейсики загружаемые, которые в машинный код вполне себе компилировали. Скажем, ZX Basic Compiler. Но они были непопулярны. Жрали много памяти, а эффективность была относительно сомнительная.

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

Во времена K&R Си считался языком высокоуровневым.

он и сейчас высокоуровневый, если сравнивать с асмом. А тогда сравнивать было больше не с чем.

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

«на низком» по сравнению с чем? Я говорил о том, что даже низкоуровневые библиотеки на С можно писать переносимо. До определённой степени конечно.

Суть в том, что даже в далёких 80х годах прошлого века применялось не чистое интерпретирование чистого текста, а выполнение некой заготовки

Где как. Sinclair BASIC был достаточно передовым решением. И очень быстрым на фоне многих тогдашних решений.

Чистых интерпретаторов тогда много было.

В любом случае, значение терминов «интерпретация» и «компиляция» от этого не изменятся. Даже с учётом того, что интерпретаторов исходного кода сегодня почти не осталось.

По твоим словам выходит, что ты три разных смысла вложил в свое высказывание

Где как. Sinclair BASIC был достаточно передовым решением. И очень быстрым на фоне многих тогдашних решений.

ОМГ! Не о том речь, а о том, что «прямая интерпретация в машинный код» это регресс и тупик. Это _начали_ понимать ещё 30 лет назад, но до сих пор находятся некоторые интересные личности, которые этого не понимают.

В любом случае, значение терминов «интерпретация» и «компиляция» от этого не изменятся. Даже с учётом того, что интерпретаторов исходного кода сегодня почти не осталось.

да знаю я значение терминов, конечно бэйсик в ZX был интерпретатором, никто же не спорит... А самих интерпретаторов сегодня даже слишком много. Иные умудряются даже на C++ написать интерпретатор, а потом его успешно юзать в своих поделиях. Тут кто-то кричал, что программеры-сволочи пихают NOP'ы в код... Зачем? Есть более элегантные способы - вместо того, что-бы взять, и сделать, можно ведь скачать инструкцию на китайском (ибо быстрее), перевести на английский (ибо стандарт), а потом на русский(ибо другого не понимаем), а потом удивится тому, что получилось...

По твоим словам выходит, что ты три разных смысла вложил в свое высказывание

так и есть. А какой смысл вложил ты в этом посте?

Я сказал, что основные конструкции и функции библиотеки языка С не меняются на различных архитектурах, что говорит о высоком уровне языка

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

Я сказал, что основные конструкции и функции библиотеки языка С не меняются на различных архитектурах, что говорит о высоком уровне языка

основные конструкции и библиотеки в сишечке ничем не отличаются от php & javascript. Однако сишечка не такая высокоуровневая. Есть в сишечки указатели, которых нет в других ЯП, и нет в сишечке ненужных структур, которые есть во всех остальных. Эти ненужные структуры и требуется делать через указатели, прямо как в асме, и потому си - это очень низкоуровневый ЯП.