The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В рамках проекта Lwan развивается новый высокопроизводительн..., opennews (??), 24-Апр-16, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


21. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 24-Апр-16, 14:00 
А питон +500 мб. Нужно просто правильно инструмент выбирать.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

41. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 24-Апр-16, 16:21 
> А питон +500 мб. Нужно просто правильно инструмент выбирать.

Очередной "не слышал, не знаю, но мое мнение таково …"
Tinypy
> implementation of python in 64k of code

впрочем,  неясно, причем тут вообще питон …

Ответить | Правка | Наверх | Cообщить модератору

46. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +2 +/
Сообщение от Аноним (-), 24-Апр-16, 16:50 
>> implementation of python in 64k of code

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

Ответить | Правка | Наверх | Cообщить модератору

67. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –1 +/
Сообщение от Нимано (?), 24-Апр-16, 18:09 
> А он по славной питоновской традиции как обычно половину скриптов выполнять не
> сможет?

И че? Вам шашечки (выполнять любые скрипты) или ехать (конкретное приложение, т.е. в этом случае http)?

> А то что сможет - будет ползать с известной скоростью,

Анонимам не угодишь.

> Динамический язык вообще сложно скомпилить, только субсет.

Нет. Динамичный язык компилять не сложно. Сложно найти динамичный (не игрушечный) язык, который бы не компилялся как минимум в байткод.

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

> А если jit - годогенерация опять же тормозит и памяти много трескает.

Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят, память трескают, но исправно компиляют не только подмножество стремительных механизмов для подъема тяжестей? o_O.

Не, я понимаю, что одно упоминание питона вызывает у вас какие-то очень неприятные воспоминания и соответствующую реакцию, но все же – на счет питона, это вам все же в соседнюю ветку, в новость про пай-пай.

Ответить | Правка | Наверх | Cообщить модератору

89. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +1 +/
Сообщение от Аноним (-), 24-Апр-16, 23:24 
> И че? Вам шашечки (выполнять любые скрипты) или ехать
> (конкретное приложение, т.е. в этом случае http)?

Только скорость и потребление ресурсов будет раз в 50 хуже. До оптимизации системных вызовов как в lwan дело не дойдет. Какой смысл уменьшать количество системных вызовов, если большинство команд идущих в проц - логика интерпретатора, а не программы?

> Анонимам не угодишь.

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

> Нет. Динамичный язык компилять не сложно. Сложно найти динамичный (не игрушечный) язык,
> который бы не компилялся как минимум в байткод.

Байткод может быть и всего лишь более компактной заменой ключевых слов. Это не отменяет нужды его интерпретировать. Проблемы начинаются когда хочется сгенерить машинный код (посмотри в вике что это). Поскольку язык ДИНАМИЧЕСКИЙ, заранее все рассчитать становится очень нетривиально и вместо компилятора начинает требоваться AI, способный осознать что делает эта программа. В частности как она может менять типы во всех возможных случаях, а если там еще и что-то типа eval() есть - надо к программе еще и компилятор весь подшить, бонусом. Как максимум - или jit делают, со своими проблемами, или компилируют статичски типизированный субсет, где все сильно упрощается.

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

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

> Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят,
> память трескают, но исправно компиляют не только подмножество стремительных механизмов
> для подъема тяжестей? o_O.

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

> Не, я понимаю, что одно упоминание питона вызывает у вас какие-то очень
> неприятные воспоминания и соответствующую реакцию, но все же – на счет
> питона, это вам все же в соседнюю ветку, в новость про пай-пай.

Это вы тут с какими-то "приложениями" приперлись. При том что на питоне они заведомо не конкурент штуке где дошло дело до оптимизации системных вызовов.

Ответить | Правка | Наверх | Cообщить модератору

98. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –1 +/
Сообщение от Нимано (?), 25-Апр-16, 03:00 
Сами что-то придумали, сам опровергли – молодца! )

> Байткод может быть и всего лишь более компактной заменой ключевых слов. Это
> не отменяет нужды его интерпретировать.

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

> Проблемы начинаются когда хочется сгенерить машинный
> код (посмотри в вике что это).

Кстати, википедия в этом особо не поможет, тут желательно что-то типа
http://www.intel.com/content/www/us/en/architecture-and-tech...
ну, с поправкой на архитектуру. А то боюсь, что с помощью википедии вы много не нагенеруете.

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

А, классический Отвечатель  –  прочел кусочек, ответил. Прочел следующий, ответил. Это многое объясняет.

> Более того - даже когда это нативный код (JIT например)
> - ему придется делать множество проверок не изменился ли тип и
> что там еще.

Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, присылаемые из параллельной вселенной. А так все верно, да!

>> Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят,
> Jit делают достаточно сложный анализ в рантайме и кодогенерацию.

Т.е. до кое-кого так и не дошло, что Just In Time компилятор таки все же компилятор? Н-да.


> Это вы тут с какими-то "приложениями" приперлись. При том что на питоне
> они заведомо не конкурент штуке где дошло дело до оптимизации системных
> вызовов.

Хорошо наверное быть Отвечателем –  взял и придумал себе что-то, а потом и ответил, позорно посрамив всех неведомых врагов! )

Ответить | Правка | Наверх | Cообщить модератору

116. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +1 +/
Сообщение от Аноним (-), 25-Апр-16, 16:10 
> Сами что-то придумали, сам опровергли – молодца! )

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

> А может быть, вы определитесь – нельзя компилировать или все же генерировать
> "эффективный  машинный код"?

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

> такое, причем тут интерпретация и каким боком все это относится к "машинному").

Важно вот что: логика программы либо представляется в виде машинных команд, которые напрямую выполняются на CPU, не разбавленные побочными вещами - тогда быстро. Либо это не происходит, со всеми вытекающими.

> А то очень смахивает на попытку объяснить попадание пятой точки в лужу
> желанием принять грязевую ванну. )

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

> http://www.intel.com/content/www/us/en/architecture-and-tech.../

Читать на интеле про процессоры вообще - несколько однобоко. Так что попытка понта не удалась, иди охлаждай пятую точку в воде уже.

> ну, с поправкой на архитектуру. А то боюсь, что с помощью википедии
> вы много не нагенеруете.

Википедия даст общую идею. А конкретику реализации - это уже у производителя разумеется.

> А, классический Отвечатель

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

> Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, присылаемые из
> параллельной вселенной. А так все верно, да!

Тюринг доказал что одна программа (в нашем случае компилятор) не может проанализировать другую программу (в нашем случае то что програмер нагенерил) и вынести определенный вердикт (в нашем случае - о том изменится ли тип). С какими-то оговорками и ограничениями наверное можно попробовать проскочить, но это глюкоопасно, т.к. программер может делать все что угодно в пределах возможностей языка. И предусмотреть вообще все обычно невозможно. Поэтому jit обычно явно проверяет - не меняется ли тип. Это разбавляет код программы кучей проверок. А в машинном коде многие вещи могут быть и как логическая или арифметическая операция напрямую. Есть большая разница: сложить r1 и r2 в которых было 2 и 3 и получить 5 за 1 такт процессора, или потратить еще уйму тактов на проверки какие там типы у кого были и что должно получиться. Поэтому даже лучшие jit легко проигрывают нативному коду в 2.5-5 раз.

> Т.е. до кое-кого так и не дошло, что Just In Time компилятор
> таки все же компилятор? Н-да.

Обычно он компилятор только наполовину, с большими оговорками. Т.е. самые горячие куски перегоняются в машинный код, а остальное интерпретируется. К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию. Одно дело если компилятор будет 2 минуты оптимизировать код в compile time, и совсем другое - если jit встрянет на  2 минуты в run time. И даже так - из-за динамичности производительность оказывается ниже и к тому же не постоянная. Ну то-есть про реальное время, даже самое лажовенькое, можно сразу забыть.

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

> Хорошо наверное быть Отвечателем –  взял и придумал себе что-то, а
> потом и ответил, позорно посрамив всех неведомых врагов! )

Да зачем вас срамить? Вы сами гораздо лучше справляетесь.

Ответить | Правка | Наверх | Cообщить модератору

124. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –3 +/
Сообщение от Нимано (?), 25-Апр-16, 20:03 
> Тут было явно более одного анонима и думали они по разному, однако.

Ну да, писать из под анонима так удобно – если что, то "это не я сел в лужу! Это другой аноним!"
Только вот проблемка, пока что _каждый_ из этих анонимов, не исключая конретно вас, такого красивого, порол знатную чушь )

>> А может быть, вы определитесь – нельзя компилировать или все же генерировать
>> "эффективный  машинный код"?
> От "компиляции" в байткод нету толка - избавляет от неэффективного парсинга строк,
> но байткод все-равно интерпретируется.

Открою вам страшную тайну (вернее, повторю свой прервый постинг) – байткод совсем необязателен. Зайдите в  гугол и найдите всякие трансляторы питона в С++, Си и т.д. Там зачастую никаким байткодом и близко не пользовались.  А еще расскажите об отсутствие толка всяких промежуточных кодов гццшникам со шлагновщиками – а то они, болезные, не знают об этом. Ну да, куда им до анонимов опеннета! )

Просто особого профита от этого нет (разжевывать лень, но если вы хотя бы немного знаете тот же Си, подумайте на досуге, как можно поместить в один массив несколько различных типов данных, что для этого нужно и какие у такого подхода могут быть минусы), но никаких бредовых идей типа
> заранее все рассчитать становится очень нетривиально и вместо компилятора
> начинает требоваться AI, способный осознать что делает эта программа.

не требуется )


> Важно вот что: логика программы либо представляется в виде машинных команд, которые
> напрямую выполняются на CPU,

Очень точная формулировка! )
Хотя, чего я ожидал от анонимов.
У одного JIT компилятор вовсе и не компилятор.
У другого, генерированием машинных кодов для "динамических типов" должен заниматься ИИ,  иначе мол, все очень не тривиально (т.е. по сути оказывается в Си нельзя сделать массив с разными типами, особенно, если хранить там данные, введенные пользователем – ведь нельзя будет предсказать тип конкретного элемента, а значит нужен ИИ, способный осознать! Иначе низя! О как!).

Третий вообще умудрился Тюринга к выводу типов приткнуть и сделать какие-то свои, анонимные выводы. Правда, начисто проигнорировав ключевое слово "cторож"/guard. А уж компиляторы у него и половинчатые бывают *рукалицо*

> За километр видно питониста, выгораживающего фетиш.

О как, оказывается это я упорно несу бред, понтуясь набором "вумных слов" )

>> http://www.intel.com/content/www/us/en/architecture-and-tech.../
>> ну, с поправкой на архитектуру.
> Читать на интеле про процессоры вообще - несколько однобоко. Так что попытка
> понта не удалась, иди охлаждай пятую точку в воде уже.

Проигнорировать часть предложения даже для вас слишком уж жирно. Тоньше нужно быть, тоньше.
А если бы я захотел попонтоваться, то упомянул бы, что 4 томика "от интеля" у меня на книжной полке стоят. Так что мимо. )

> Ну ты то вообще классический бугуртовщик, да еще и гонщик к тому
> же.

Громче и чаще, авось кто поверит. Заодно и от лажи отвлечет =)

> Пытаешься сосватать байткод как эквивалент машинного кода.

Неа, читайте внимательнее! Я же не аноним, чтобы с умным видом нести чепуху.

>> Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, присылаемые из
>> параллельной вселенной. А так все верно, да!
> Тюринг доказал что одна программа (в нашем случае компилятор)

Умудриться приплести Тюринга к типам  – и при этом проигнорировать ключевое слово "сторож"/guard  – это сильно.
А я ведь специально "подставился", так как, если пытаться копать в сторону джитов чуть глубже википедии, то пройти мимо guard-ов очень сложно.
В общем, все ясно с вами – слышали где-то звон и решили понтанутся. Понт окончился очередной грязевой ванной )


> Есть большая разница: сложить r1 и
> r2 в которых было 2 и 3 и получить 5 за
> 1 такт процессора, или потратить еще уйму тактов на проверки какие
> там типы у кого были и что должно получиться.

Какой бред^W шедевр! И все это с умным и уверенным видом! Еще, пишите еще! )


> Обычно он компилятор только наполовину,

Ну да, а еще наверняка есть "половинная беременность" – это когда с большими оговорками …
Я так понимаю, копать и уточнять в эту сторону бесполезно, т.к. у анонимов свое, собственное понимание этого термина, да еще и меняющееся от случая к случаю.


> К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию.

А мусью в курсе, зачем компиляют в байткод и какие это дает возможности? А о разных "уровнях" оптимизации?
Хотя, откуда.
У одного анонима это вообще "замена ключевых слов", у  (конечно же) другого от оного "толка нет", просто "избавляет от неэффективного парсинга строк".
Ну анонимы опеннета у нас известные знатоки, которые еще и ребят из гцц или шланга компиляторы писать поучат! )

> И даже так - из-за динамичности производительность оказывается
> ниже и к тому же не постоянная. Ну то-есть про реальное
> время, даже самое лажовенькое, можно сразу забыть.

Еще один шедевр. YMMD! =)
Оказывается динамичность виновата, о как!
Значит glibc (и еще куча имплементаций cтандартной библиотеки) в общем и malloc/free в частности вполне подходит для использования в "реальном времени" ? Нормально.

> Да зачем вас срамить? Вы сами гораздо лучше справляетесь.

Пишите еще! Жду с нетерпением дальнейших "посрамлений" )

Ответить | Правка | Наверх | Cообщить модератору

135. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 26-Апр-16, 15:28 
> "это не я сел в лужу! Это другой аноним!"

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

> вас, такого красивого, порол знатную чушь )

В тред врывается Д'Артаньян! Как шаблонно, фи.

> Открою вам страшную тайну (вернее, повторю свой прервый постинг) – байткод совсем
> необязателен. Зайдите в  гугол и найдите всякие трансляторы питона в С++, Си и т.д.

И узнайте о том что они умеют сильно урезаный поддиалект? ;)

> Там зачастую никаким байткодом и близко не пользовались.

Обычно там делают ограничения и поддерживают только часть языка. Неудобно это - динамически типизированный язык в статически типизированный транслировать. Теоретически возможно, практически - надо реализовать проверки типов и прочее. Код густо разбавляется и чуда не происходит. Поэтому соревнуются с 1929 годом^W^W интерпретатором.

> А еще расскажите об отсутствие толка всяких промежуточных кодов
> гццшникам со шлагновщиками – а то они, болезные, не знают об этом.
> Ну да, куда им до анонимов опеннета! )

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

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

У современных процессоров операции регистр-регистр быстрые, за 1 такт даже несколько операций может произойти. А обращение к массиву - шанс нарваться на доступ в RAM и отдохнуть. У быстрых процессоров это до сотен тактов. Есть кэш, но будет ли это cache hit... если ты все будешь в массивы пхать - не будет! Если программа и рабочий набор уместилась в кэш, скорость работы может подскочить в РАЗЫ. На современных процах по этой причине unroll loop'ов может себя и не оправдать. Экономия на jmp в конце цикла может убиться усилением cache miss из-за разжирения кода. Быстрый код должен быть маленьким и работать с компактными наборами данных, иначе он будет выносить кэш и станет медленным.

> что для этого нужно и какие у такого подхода могут быть минусы), но никаких
> бредовых идей типа

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

> не требуется )

Ну это ты просто не видел как программа разгоняется разиков в 5 "на ровном месте", если ты в кэш смог уместиться. Вот и предлагаешь способы улучшения thrashing кэша.

> Очень точная формулировка! )
> Хотя, чего я ожидал от анонимов.

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

> У другого, генерированием машинных кодов для "динамических типов" должен заниматься ИИ,

Это был бы самый быстрый и эффективный способ. Я ж не ты, заведомо провальную канитель с массивами не посоветую.
{...спам...}
> элемента, а значит нужен ИИ, способный осознать! Иначе низя! О как!).

Советовать заведомо фэйловые решения типа бреда с массивами - твоя привилегия.

> анонимные выводы. Правда, начисто проигнорировав ключевое слово "cторож"/guard.

Да хоть горшком называй проверки изменений типов, на результат не влияет.

> О как, оказывается это я упорно несу бред, понтуясь набором "вумных слов" )

Не только. Ты еще слился на полном непонимании стомости операций у современных CPU, что такое кэш и все такое.

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

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

> А если бы я захотел попонтоваться, то упомянул бы, что 4 томика
> "от интеля" у меня на книжной полке стоят. Так что мимо. )

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

> Громче и чаще, авось кто поверит. Заодно и от лажи отвлечет =)

Ты так задорно зажигаешь что аудитория уже задолжала анонимам за билеты в цирк.

> Неа, читайте внимательнее! Я же не аноним, чтобы с умным видом нести чепуху.

Если ты так настаиваешь...  ок, теперь ты не аноним ;).

> Умудриться приплести Тюринга к типам  – и при этом проигнорировать ключевое
> слово "сторож"/guard  – это сильно.

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

> А я ведь специально "подставился",

Что-то слишком хорошо сыграл по части кэшей и прочих массивов. Не верю что ты настолько талантливый актер.

> Понт окончился очередной грязевой ванной )

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

> Ну да, а еще наверняка есть "половинная беременность" – это когда с
> большими оговорками …

А мир вообще не черно белый, бывают всякие гибридные подходы. Jit один из них.

>> К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию.
> А мусью в курсе, зачем компиляют в байткод и какие это дает возможности?

Да, однако в конечном итоге нас интересует качество машинного кода на энной платформе. Тяжелые оптимизации - ресурсоемкие, jit не может позволить себе стать полноценной билдфермой. С соответствующими последствиями для качества кода. Если хочется тяжелые оптимизации, AOT уместнее. Его реалтайм не жмет, потребление ресурсов менее критично т.к. еще не делится с работающей программой, а там где этого надо хорошо и много - может быть сделано другим компьютером, мощным и крутым, то что для смартфонного проца 10 минут, для мощного билдсервера - секунд 20. Но он и воздух греет в других объемах. Jit так не может.

> А о разных "уровнях" оптимизации?
> Хотя, откуда.

Да куда нам, анонимам, чай пить.

> У одного анонима это вообще "замена ключевых слов", у  (конечно же)
> другого от оного "толка нет", просто "избавляет от неэффективного парсинга строк".

У дефолтного питона оно как-то так вроде и реализовано - питон интерпретирует этот байткод, медленно и печально.

> гцц или шланга компиляторы писать поучат! )

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

> Еще один шедевр. YMMD! =)
> Оказывается динамичность виновата, о как!

Она такому состоянию дел дополнительно способствует. Добиться того чтобы конструкции языка транслировались в нечто простое, легкое и предсказуемое - не так то просто. И да, в сишечке я могу и посмотреть во что моя конструкция реально разложилась в виде машинного кода и я смогу довольно хорошо просчитать что будет и может быть. А что, сможешь так же круто заинструментировать jit? Ты кстати ничего не сказал про overcommit или latency, если уж мы про время.

> Значит glibc (и еще куча имплементаций cтандартной библиотеки) в общем и malloc/free
> в частности вполне подходит для использования в "реальном времени" ? Нормально.

В си можно работать и без libc, и без выделения памяти malloc'ом. Как тебе такой оборот? На си с полоборота пишут загрузчики и ядра, которые работают когда файловой системы, управления памятью и прочих malloc еще и в проекте нет. Зарубиться с таким инструментарием в вопросе предсказуемости операций - ну попробуй.

> Пишите еще! Жду с нетерпением дальнейших "посрамлений" )

Ну если ты так настаиваешь...

Ответить | Правка | Наверх | Cообщить модератору

137. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –2 +/
Сообщение от Нимано_ (?), 26-Апр-16, 20:19 
О, четвертый (или пятый?) "другой аноним!" подключился.

> А еще анонимы могут подключаться к дискуссии если у них есть возражения.

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

>> Зайдите в  гугол и найдите всякие трансляторы питона в С++, Си и т.д.
> И узнайте о том что они умеют сильно урезаный поддиалект? ;)

Т.е. та же nuitka умеет уже только сильно урезанный диалект? Ну окай. ЧуЙствуется очередной Эксперт.

> Неудобно это -  динамически типизированный язык в статически типизированный транслировать.
> Теоретически возможно, практически …

О, хоть один из анонимов соизволил наконец прочитать мое первое сообщение и пересказать его мне же, своими словами? Гениально! Так держать!

> Зачем у них промежуточные коды - еще можно понять. Но это внутренние
> сущности. Они мало кого интересуют кроме авторов компилятра.

Т.е. все же толк (о чем, как бы, и была речь) от них есть?

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

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

т.к. по мнению какого-то из анонимов, "динамичность" нельзя нормально скомпилировать и требуется ИИ.


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

Молодец, домашнее задание засчитываю (хотя у вас и слишком много отсебятины), минусы вы осознали хорошо, а теперь, главный вопрос: что насчет возможностей? Можно так делать в Си или нельзя? Ведь там нет ИИ!

> Вот и предлагаешь способы улучшения thrashing кэша.
> {много вумных слов}
> А ты предлагашь способы засорения
> кэша. Будет очень производительно, даже не сомневайся.
> Советовать заведомо фэйловые решения типа бреда с массивами - твоя привилегия.

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

>> анонимные выводы. Правда, начисто проигнорировав ключевое слово "cторож"/guard.
> Да хоть горшком называй проверки изменений типов, на результат не влияет.

Вообще, это был намек в сторону "появления новых типов". А то, если послушать анонимов, оные прям из ниоткуда берутся. Ну и заодно, простая и очевидная попытка подловить/проверка, наскольно анонимы "в теме" обсуждаемого – благо я тоже не первый раз на опеннет зашел.
И, как мы видим – вполне сработало, анонимы один за другим упорно лажались )

Разясняю:
Вот цитатка – в отличии от анонимов, у меня нет нужнды в подтасовках и бредовой отсебятины:

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

Нормальный человек, который хоть немного "в теме" –  или сразу ответил бы, что де, так он и писал. Или сперва глянул и уточнил, а потом ответил.
Благо, как уже упоминалось раннее, пройти мимо "guard"-ов  очень таки сложно.
А знающий аноним мог бы вообще замусолить тему …
Ну, или – вообще проигнорировать и не отвечать, даже если "в теме" – мало ли чему человек не придал значения, может ему влом перед очередным опеннетчкиком хлебные крошки метать. В общем, было бы вполне нормальное поведение.

Но увы, это не про Анонимов. Анонимы, ничтоже сумняшеся опять затянули свою песнь про  типы,  да еще и пытались Тюринга к выводу оных приплести. Эпично.

Т.е., как и подозревалось, нифига анонимы не знают, но пытаются пускать в глаза пыль умными словами. Вот и тут, у одного конкретного анонима guardы оказывается входят в более общее понятие "проверки типов".
Прям хоть *рукалицо.жпг* делай — анонимам походу все божья роса )

> Не только. Ты еще слился на полном непонимании стомости операций у современных
> CPU, что такое кэш и все такое.

...
> Зачем быть тонким с кадром, который не понимает основ кэширования но машет
> интеловским маном? Ты более тонко не заметишь с таким то умищем.

Что, анонимы совсем отчаялись и пытаются использовать любой призрачный шанс? =)
Хотя да, признаю, эпичная попытка перевода стрелок! Да и в фантазии вам не откажешь.
Кстати, а пруфец где? А то очень похоже на очередное "сам придумал, сам опроверг, сам доволен".

А так – только и остается задаться вопросом, как же у вас должно <эт-самое> пониже спины, чтобы так отчаянно пытаться высосать из домашнего задания для анонимов (для Отвечателей процитирую еще раз)
> разжевывать лень, но если вы хотя бы немного знаете тот же Си, подумайте на досуге,
> как можно поместить в один массив несколько различных типов данных, что для этого
> нужно и какие у такого подхода могут быть минусы

такую знатную и шикарную отсебятину )

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

> аудитория уже задолжала анонимам за билеты в цирк.

Не очень удивительно, коль анонимы с таким упорством строят из себя клоунов-Покорителей-Луж, знатно и по нескольку раз лажаясь в каждом ответе )

===========================

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

А вот мы и добрались до очередного перла^W шедевра! )

Во первых, "осознали" вы это только после жирного намека, а вернее, разжевывания.

И главное, во вторых:
включение в «более общее понятие 'проверки типов'» вообще-то отдает очередной, сугубо личной верованием^W терминологией очередного анонима.

Потому как у всех остальных, знакомых с темой не по википедии и собственным домыслам – проверка типов может входить в обязанность "сторожа". Но вот наоборот – ну никак нет.
До этого, в принципе, даже самому дотумкать не сложно, а уж упоминаний этого …
Но это же не про анонима, который мог  промолчать или быстренько уточнить – но предпочел <эт самое в лужу>. Зато с умным видом, да. Молодца!

Так что, увы, очередная попытка спрыгнуть не удалась и вы опять расслабляетесь в лечебной грязи =)


> Что-то слишком хорошо сыграл по части кэшей и прочих массивов. Не верю
> что ты настолько талантливый актер.

Давайте давайте, переводите стрелки, авось и получится разок )


>>> К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию.
>> А мусью в курсе, зачем компиляют в байткод и какие это дает возможности?
> Да, однако в конечном итоге нас интересует качество машинного кода на энной
> платформе.
> много вумных слов
> Jit так не может.

Т.е. мусью как минимум про возможности не в курсе, но продолжает делать умный вид. Ясно.
То, что конкретный jit чего-то не может, как бы вообще не показатель. Вон, те же разработчики жабоскрипто-ВМок например отнюдь не зря и по капризу левой пятки хотят "заиметь" байткод.

>> А о разных "уровнях" оптимизации?
>> Хотя, откуда.
> Да куда нам, анонимам, чай пить.

Ну вон, выше, анонимы были не в курсе преимуществ, которые может дать байтод (как раз из-за различных уровней/вариантов оптимизаций, причем львиная доля этих самых ресурсоемких оптимизаций особо от целевой машины не зависит) и исправно заладили про что-то, что якобы jit ну никак не может, ну и про нагрев воздуха не забыли – видимо наболело )

> В си можно работать и без libc, и без выделения памяти malloc'ом.
> Как тебе такой оборот?

Опять свинчивание с темы. Анонимы такие анонимы! А glibc у нас теперь на динамичном языке, да?
Или почему его нельзя использовать?

> Зарубиться с таким инструментарием в вопросе
> предсказуемости операций - ну попробуй.

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

> Ну если ты так настаиваешь...

Спасибо, Маэстро Луж, вы опять были неповторимы!

ЗЫ: молодца, взял и зарегистрировал ник.
> Участник:    Нимано
> ФИО:    Лох Педальный

Ну да – крутой аргумент, прям слов нет. Знатно у вас припекает )

Ответить | Правка | Наверх | Cообщить модератору

150. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 28-Апр-16, 10:48 
> Ну да, и знатно садиться в лужу. Все как всегда.

Посадить меня в лужу может какой-нибудь сильный сишник. Как тот разработчик нжинкса. Ты для этого хиловат.

> Вы бы хоть номерки добавляли, чтобы вас различать можно было.

Если тебе хочется веселить публику - зачем мешать?

> Т.е. та же nuitka умеет уже только сильно урезанный диалект?
> Ну окай. ЧуЙствуется очередной Эксперт.

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

> О, хоть один из анонимов соизволил наконец прочитать мое первое сообщение и
> пересказать его мне же, своими словами? Гениально! Так держать!

Да вы там всей толпой наспамили километр.

> Т.е. все же толк (о чем, как бы, и была речь) от них есть?

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

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

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

> вы осознали хорошо, а теперь, главный вопрос: что насчет возможностей? Можно
> так делать в Си или нельзя? Ведь там нет ИИ!

ИИ требуется для того чтобы привести динамические типы в статические без выполнения кучи проверок в рантайме (интерпретатор в качестве решения проблемы - еще тяжеловеснее).

Чтобы сложить 2 и 3 как эффективное "add r1, r2" - надо быть уверенным что r1 и r2 остаются именно integer'ами, и не превращаются, например, в строку. В этом месте Тюринг дает пендаль: чтобы получить эту уверенность путем предвычислений во время сборки, без кучи проверок в рантайме, надо быть AI. Сишникам с их типами (которые вообще фэйк) Тюринг тоже порой икается, по поводу чего есть "register", "volatile" и т.п..

> Все в лучших традициях анонима )

Да ты фигачь все массивами, посмотришь что получится.

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

Откуда бы они ни брались, это подразумевает ряд действий. В рантайме. Т.е. замедление этого куска кода по сравнению с тривиальным add r1, r2, априори в разы.

> И, как мы видим – вполне сработало, анонимы один за другим упорно лажались )

Ты тоже хорош, предложил какой-то дурацкий способ и доволен по уши.

> Благо, как уже упоминалось раннее, пройти мимо "guard"-ов  очень таки сложно.

Вот ежкин кот. Я сказал про проверки. Guard насколько я понимаю частный случай и есть. Тебя не смущает что это будут какие-то дополнительные действия, далекие от add r1, r2 для тех же integer'ов?

> Но увы, это не про Анонимов. Анонимы, ничтоже сумняшеся опять затянули свою
> песнь про  типы,  да еще и пытались Тюринга к выводу оных приплести. Эпично.

Так ты покажи где в этой логике промах?

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

По-моему я довольно фундаментальную проблему озвучил, какое-то следствие из Тюринга. Заранее просчитать в build time все варианты изменения типов в динамических ЯП невозможно. А рантайм-проверки - можно, но они замедляют выполнение, однако. С точки зрения оптимизации, предвычисление в build time гораздо лучше чем вычисления в run time.

> guardы оказывается входят в более общее понятие "проверки типов".

А что, не входят?

...
> Что, анонимы совсем отчаялись и пытаются использовать любой призрачный шанс? =)

Если оппонент затупляет - что ж поделать.

> какие могут у этого подхода быть минусы" кое-кто знатно профейлил. Когда
> советуют что-то, то обычно упоминают как минимум не только минусы,

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

> включение в «более общее понятие 'проверки типов'» вообще-то отдает очередной,
> сугубо личной верованием^W терминологией очередного анонима.

Не к чему докопаться - займись буквоедством? Можешь еще орфографические ошибки поискать, дарю идею.

> Так что, увы, очередная попытка спрыгнуть не удалась и вы опять расслабляетесь
> в лечебной грязи =)

Ты на этом так переклинен что это уже напоминает синдром утенка, чтоли.

> Давайте давайте, переводите стрелки, авось и получится разок )

Это ты так намекаешь, что если технические аргументы закончились - нужно провести персональную атаку на оппонента? У тебя и это плохо получается.

> То, что конкретный jit чего-то не может, как бы вообще не показатель.

Это не "конкретный jit" а некий constraint: чем более качественный код мы хотим получить, тем больше времени надо потратить на анализ. Не уверен что есть строгая теория доказывающая это, но на практике вот так. Хорошо видно на примере скорости компиляции clang по версиям ;).

> Вон, те же разработчики жабоскрипто-ВМок например отнюдь не зря и по
> капризу левой пятки хотят "заиметь" байткод.

Не той стороной, дядя Федор, бутерброд ешь. Они хотят заиметь нормальный IR. Не навязывающий динамическую типизацию, в отличие от JS, и позволяющий эффективную трансляцию в машинный код. Динамические типы гэ в плане оптимизации. Поверх низкоуровневго рантайма - можно сделать и динамические типы, если хочется. С оверхедом только у любителей динамических типов, без отравления жизни остальным. Это как раз нормальный шаг в сторону более вменяемого рантайма, не зависящего от ЯПов.

> Ну вон, выше, анонимы были не в курсе преимуществ, которые может дать
> байтод (как раз из-за различных уровней/вариантов оптимизаций,

Питону это как мертвому припарки. Те кто посообразительнее, и кто на деньги из-за тормозняков попадает - уже сделали выводы. У гугля есть go, дропбокс в который там уже раз переписывают. Что-то showcases производительности превратились в failboat.

> заладили про что-то, что якобы jit ну никак не может, ну
> и про нагрев воздуха не забыли – видимо наболело )

Ты прав, JIT и даже AOT на стороне юзера - больная тема. Сомневаешься? Посмотри сколько времени .NET в винде после установки генерит сборки в нативном коде из абстрактного. Всего полдня лагания компа - и готово.

>> В си можно работать и без libc, и без выделения памяти malloc'ом.
>> Как тебе такой оборот?
> Опять свинчивание с темы. Анонимы такие анонимы!

А в чем свинчивание? В том что кто-то смеет пользоваться возможностями ЯП и компилятора? Так си тем и хорош - хочешь, пользуешься либой. Не хочешь - не пользуешься. Модно самому себе свой libc написать, с шахматами и поэтессами. Если это зачем-то надо.

> А glibc у нас теперь на динамичном языке, да?

Glibc - всего лишь одна из реализаций libc, которая может использоваться а может и не использоваться, на усмотрение програмера.

> Или почему его нельзя использовать?

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

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

Это "увы" не ощущается. Увы.

> Спасибо, Маэстро Луж, вы опять были неповторимы!

Да не за что, меня эта дискуссия тоже поулыбала.

> ЗЫ: молодца, взял и зарегистрировал ник.
>> Участник:    Нимано
>> ФИО:    Лох Педальный
> Ну да – крутой аргумент, прям слов нет.

Ты так активно педалировал тему анонимов, что он стал НЕаноним :P.

>  Знатно у вас припекает )

Уверен что у меня? :) Впрочем, если тебе нужен этот ник - напиши какую-нибудь ненужную почту в ответе - я тебе пароль туда вышлю, пока не забыл. Мне этот ник не требуется.

Ответить | Правка | Наверх | Cообщить модератору

156. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Нимано_ (?), 28-Апр-16, 17:29 
>> сложно "втиснуть" динамичность в такие рамки, чтобы компиляция в "нативный код"  
>> стала действительно эффективной, а не просто эдаким "захардкоженным" аналогом интерпретатора.
> ИИ требуется для того чтобы привести динамические типы в статические без выполнения
> кучи проверок в рантайме (интерпретатор в качестве решения проблемы - еще
> тяжеловеснее).

Наконец-то хоть до одного из анонимов дошло. А то "компилировать нельзя, ИИ нужен!!".


> чтобы получить эту уверенность путем предвычислений во время сборки, без кучи проверок
> в рантайме, надо быть AI.

В общем случае возможно что-то эдакое можно и подвести. Но тут вылезает куча оговорок и все эти обобщения могут быстро оказаться "ни о чем".
Например, если не брать в расчет хитровывернутый код, то проследить "execution path" и вывести нужные типы – ну не совсем тривиально, но и далеко не проблема "божественного ИИ"-класса.

> Сишникам с их типами (которые вообще
> фэйк) Тюринг тоже порой икается, по поводу чего есть "register", "volatile"
> и т.п..

То, что в си слабая типизация, вроде как не тайна, не?

>> Вообще, это был намек в сторону "появления новых типов". А то, если
>> послушать анонимов, оные прям из ниоткуда берутся.
> Откуда бы они ни брались, это подразумевает ряд действий. В рантайме. Т.е.
> замедление этого куска кода по сравнению с тривиальным add r1, r2,
> априори в разы.

Еще раз: проследить "code execution path", вывести типы, генерировать код.
Т.к. сам по себе, внезапно, тип не изменится, то проверки при (нетривиальном) присвоении новых значений,  будет достаточно. Причем, часть из них [проверок] скорее всего можно будет опустить и уж тем более не нужно пихать их перед каждой операцией.

Этих самых "нетривиальных"  (т.е. не вида x += 42 или x = x + y, при том что тип y для именно этой ветки вычислений известен) присвоений на самом деле не так уж и много (и не надо кивать на хитровывернутый индусо-код).
Такой подход позволит разбить код на блоки, в идеале (ну или в зависимости от требований) с одной точкой входа и в котором типы переменных по определению не изменяются. Т.е. конкретно для этих блоков оптимизация будет вполне себе ничего. Опять же, совсем не обязательно, что на выходе такого блока будут нескольно типов, а это, опять же, позволит объединять/"инлайнить" блоки.
Хотя да, можно придумать пример попорукого кода, где все это не будет работать – но такой код далеко не тот показатель, на который стоит ориентироваться.


>> И, как мы видим – вполне сработало, анонимы один за другим упорно лажались )
> Ты тоже хорош, предложил какой-то дурацкий способ и доволен по уши.

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

> Вот ежкин кот. Я сказал про проверки. Guard насколько я понимаю частный
> случай и есть. Тебя не смущает что это будут какие-то дополнительные
> действия, далекие от add r1, r2 для тех же integer'ов?

Неа, ведь анонимов не смущает, что есть некая устоявшаяся терминология, переиначивать (а анонимов никто за язык^W пальцы не тянул) которую – как минимум чревато быть не понятым. Ну и заодно показать, что на самом деле познания – в лучшем случае общие, больше из разряда "а я вот считаю".
Что само по себе не является чем-то отрицательным, если конечно технически более-менее обоснованно. Но вот делать при этом умный и уверенный вид, предоставляя все в виде истины в последней инстанции …

>> Но увы, это не про Анонимов. Анонимы, ничтоже сумняшеся опять затянули свою
>> песнь про  типы,  да еще и пытались Тюринга к выводу оных приплести. Эпично.
> Так ты покажи где в этой логике промах?

Не-не. Дурных нема. Аноним пусть сам доказывает, что то, что он имел в виду — действительно применимо именно в этом конкретном случае )

>> guardы оказывается входят в более общее понятие "проверки типов".
> А что, не входят?

Ну, если пользоваться общепринятой терминологией тех же мозилловцев, пай-пайщиков и еще кучи людей, то нет. Максимум можно встретить [i]type guard[/i]


>> какие могут у этого подхода быть минусы" кое-кто знатно профейлил. Когда
>> советуют что-то, то обычно упоминают как минимум не только минусы,
> Не очень понятно о чем ты.

Очевидно же о "советовании" использования массивов. Аноним придумал в очередной раз что-то, блестяще опроверг, а вот на мелочах опять спалился )


>> включение в «более общее понятие 'проверки типов'» вообще-то отдает очередной,
>> сугубо личной верованием^W терминологией очередного анонима.
> Не к чему докопаться - займись буквоедством? Можешь еще орфографические ошибки поискать,
> дарю идею.

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


> Это ты так намекаешь, что если технические аргументы закончились - нужно провести
> персональную атаку на оппонента? У тебя и это плохо получается.

Не, я же не Аноним, мне это как бы не нунжно. Хотя обозвать инкриминирование "перевода стрелок" персональной атакой – это сильно )  
А что, нужно было написать от имени оппонента, что он "Лох Педальный" и ходить, раздуваясь от ЧСВ? Ну да, это стильно и аргументативно! )


>> То, что конкретный jit чего-то не может, как бы вообще не показатель.
> Это не "конкретный jit" а некий constraint: чем более качественный код мы
> хотим получить, тем больше времени надо потратить на анализ.

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

> Ты прав, JIT и даже AOT на стороне юзера - больная тема.
> Сомневаешься? Посмотри сколько времени .NET в винде после установки генерит сборки
> в нативном коде из абстрактного. Всего полдня лагания компа - и
> готово.

То же самое можно было сказать 200 лет назад о "самобеглых колясках" – шумны, вонючи, медленны и легко уделываются хорошей тройкой. Как и о первых пароходах.
В общем, аргумент весьма сомнительный.

>>> Участник:    Нимано
>>> ФИО:    Лох Педальный

Это почти из разряда "Написать на двери оппонента <такой-то – дурак>, навалять кучу под дверь и ходить гордым и довольным". Т.е. мне не понять.

> Ты так активно педалировал тему анонимов, что он стал НЕаноним :P.

Т.е. это уже я прятаться за безликим "Анонимом", активно каждый раз твердя "я другой Аноним!"? Ну окай, пусть будет так. Хорошо, что анонимы не в курсе моего реального адреса, а то боюсь, "доказательства превосходства" в виде надписей на двери и, возможно, кое-чего похуже и попахучее под оной, я бы не оценил.

>>  Знатно у вас припекает )
> Уверен что у меня? :)

Т.е. написать от "как-бы имени" оппонента, какой он "педальный лох" – признак адекватной реакции? Ой, да ладно вам сказки рассказывать )

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

Да не особо – "ним-Ано", не? Просто, чтобы не прятаться за безликим "Аноним", в отличие от.
Хотя, если совесть гложет, то пожалуйста:
nimano@you-spam.com

Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру