Теоретик.

Алгоритм для решения задачи аллокации регистров (register allocation) в студию. Такой, чтобы был полиномиальным и выдавал оптимальный результат.

Оптимальность генерируемого кода компиляторами не достигнута. Алгоритмы нужно улучшать.

Алгоритм для решения задачи аллокации регистров (register allocation) в студию.

Их десятки разных эвристик существует. Что характерно, все крайне простые.

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

Такого не существует. И не надо.

Оптимальность генерируемого кода компиляторами не достигнута.

И кому нужны лишние 3% производительности? Никому. Этой задачей никто не занимается, да и нет тут ничего такого наукоемкого. Банальная бухгалтерия, поиск баланса между стоимостью компиляции и оптимальностью результата.

Алгоритмы нужно улучшать.

Последние лет 20 не улучшают. Ничего нового давно уже никто не придумывает.

И в случае чего, никто не запрещает запускать с LD_LIBRARY_PATH=/path/to/new/gtk/lib:$LD_LBRARY_PATH google-chrome

буханка.джпг

Напоминаю, что для этого придётся подтянуть весь gtk+ стек (glib+atk+gdkpixbuf+pixman+cairo+pango+сам gtk). Плюс мало ли какие ещё проблемы возникнут с бинарным блобом на неподдерживаемой ОС. Возьмут например и подцепятся на новые libc/stdc++. Они же теперь не связаны по рукам и ногам ABI стабильных систем, лишь бы на свежей убунте и федоре работало. Рантаймы си и сипласпласа-11 тоже в префикс сам подтягивать будешь? А сипласплас-11 нового компилятора потребует. И т.д. Не много ли работы берёт на себя юзер, в конце концов далеко не единственной в своём роде программы?

Их десятки разных эвристик существует. Что характерно, все крайне простые.

И неоптимальные.

Такого не существует. И не надо.

Не существует. Но ничто не мешает стремиться к нему.

И кому нужны лишние 3% производительности?

Далеко не 3. Одно только правильное раскладывание локалов на регистры в горячих местах — это 10-20 процентов, например.

Последние лет 20 не улучшают. Ничего нового давно уже никто не придумывает.

Регулярно пишутся новые научные работы с поразительными результатами, и их поток не иссякнет ещё долгое время. Тот факт, что в GCC-шное болото ничего из этого не пришло, не говорит о том, что этого нет.

Имхо, прочитав почти все (ну может многие) посты, понял что большинство народу даже и не знает что такое «стабильный дистрибутив» и говорят о том о чём не знают.

1. Отсутсвие флеш это никакой не - это даже огромный + 2. Отсутсвие хрома так же как и отсутсвие пылинки на дисплее. 3. Вы ощущаете нехватку броузеровФФ в linux или unix ??? - я нет

И неоптимальные.

Они ДОСТАТОЧНО оптимальные для того, чтобы не напрягаться.

Не существует. Но ничто не мешает стремиться к нему.

Мешает ненужность.

Далеко не 3. Одно только правильное раскладывание локалов на регистры в горячих местах — это 10-20 процентов, например.

В очень редких случаях.

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

Ну ну. Ссылку на хотя бы три существенно новых результата за последние двадцать лет. Все публикации - пережевывание старого и давно известного.

Ян Вильдебор (Jan Wildeboer, место работы: Red Hat) опубликовал в своем блоге запись: «Почему Google подвергает пользователей RHEL опасности, не предоставляя обновления для Chrome? И почему продолжает предоставлять обновления для Windows XP?»

А конечный пользователь-то причем? Он покупает у RedHat, а не у каких-то там Google.

Просто гугл не зафиксировал ни одного запуска хрома на этих ОС.

А вот это мощная шутка! :D [учитывая, что вроде как все еще идут терки по поводу того, что и куда браузер отправляет]

У меня много раз было такое, что поставляемый с хромом флеш глючит больше чем установленный в системе и мне его приходилось вырубать в chrome://plugins. Так что не всегда ваша теория верна :)

Сейчас активно пилят SSA. Пруфы в гугле.

Раз уж Опера решила заюзать вебкит, перейду на неё, а дальше видно будет, но с дебиана не слезу.

SSA - конец 80х, ничего нового тут нет.

А разные плюшки, которые оно даёт, посвежее будут.

Нет. Все из 80х. И adce, и code motion, и loop invariant analysis, и SSA-специфичные эвристики register allocation. Нового не придумали ничего.

LD_LIBRARY_PATH=/path/to/new/gtk/lib:$LD_LBRARY_PATH google->chrome

Вот так, с помощью нехитрых приспособлений... саппорта-то не будет.

RH может самостоятельно собирать пакеты Chromium более новой версией gcc, если хочет, никаких технических препятствий для этого нет. /thread

Как это эпично.

Власть - это наркотик. Вот и Гуглю хочется всё больше власти.

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

> Это проблемы редхэта, что они решили до двадцатого года поддержку осуществлять. Когда фаерфокс перелезет на gtk3, то у них тоже будут спрашивать «сфигали»?

Они сами у себя будут спрашивать? Порт Mozilla на GTK+ и Firefox на GTK+ 2 делали в Red Hat.

Какой компилятор пилишь?

Поддержка Windows XP Service Pack 3 завершается 8 апреля 2014 года.

не надо ныть надо работать а то носятся со своим дебианом как дурак с торбой

Вот она настоящая сила опенсорса. Или дистростроители сами портируют программу на свое говномамонта, или ноют в бложиках. Что будет когда под линуксом будет больше закрытых программ? А, да, стим и так не работает на редхете и дебиане.

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

Гуглю хочется всё больше власти

гуглю хочется всё больше C++11, вот наглецы

Каждый этап компиляции прост и самодостаточен, и потому сложность всей системы не превышает сложности самой сложной составляющей (и не является суммой сложностей составляющих).

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

В последнем C++11, кстати добавили возможность использовать «>>» для шаблонов. Без взаимосвязи между уровнями этого сделать невозможно.

Доверять google может только очень наивный человек.

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

Спасение - в зоопарке браузеров.

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

В учебниках как раз об этом и не пишут. В учебниках пишут чушь, особенно в распиаренном идиотском dragon book.

Без взаимосвязи между уровнями этого сделать невозможно.

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

За мою практику мне не приходилось еще ни с одним языком строить сложные костыли.

GLR в этом отношении рулит

В gcc что используется?

Не дождусь ответа.

Поэтому сам себе и отвечу :) gcc использует метод рекурсивного спуска. И перешло gcc на него с GLR. Туда легче хаки встраивать.

Ку-ку? Головка бо-бо? В gcc убогом никогда не было GLR.

GCC started out using Bison, but switched to a hand-written recursive-descent parser for C++ in 2004 (version 3.4),[8] and for C and Objective-C in 2006 (version 4.1);[9]

Bison by default generates LALR parsers but can also create GLR parsers.

У кого головка бобо?

У тебя, лохохо, головка бо-бо. Бизон тогда еще не умел glr, да и по сей день по хорошему не умеет. Если честно, никогда не видел ни одного идиота, кто пытался бы быдлобизон для glr употребить. С тем же elkhound это убогое поделие и рядом не лежало.

3.14здоболов вроде тебя надо носом в говно тыкать. GLR в bison уже в 2002 году был. А твой искрометный помет из уст этих фактов не изменит.

Повторяю для тупых, bison никогда не умел полноценного glr, а чисто так, для галочки. Без лексера он работать не может, например.

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

Повторяю для тупых, bison никогда не умел полноценного glr, а чисто так, для галочки. Без лексера он работать не может, например.

Твой устный понос факта не изменит.

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

Тупицо тут ты. Вот и не рассуждай. Приведи действия которые необходимы для переключения на glr у bison'а.

Твой устный понос факта не изменит.

Отродье свиньи, факт объективен - это говно, а не GLR. Настоящий GLR - это Elkhound. Попробуй, говно убогое, написать на сучьем бизоне хоть одну сложную GLR-грамматику.

Тупицо тут ты.

Нет, ламо, тупицо тут только ты и твоя аморальная мамашка.

Вот и не рассуждай. Приведи действия которые необходимы для переключения на glr у bison'а.

Ты идиот, да? Сама грамматика, да-да, те самые .y файлы, что были в gcc - LALR, а не glr. Ты вообще, похоже, не знаешь, что такое GLR.

Отродье свиньи, факт объективен - это говно, а не GLR. Настоящий GLR - это Elkhound. Попробуй, говно убогое, написать на сучьем бизоне хоть одну сложную GLR-грамматику.

Факт что есть GLR. А твой словесный понос говрит о том кто ты.

Ты идиот, да? Сама грамматика, да-да, те самые .y файлы, что были в gcc - LALR, а не glr. Ты вообще, похоже, не знаешь, что такое GLR.

В очередной раз ткну носом в дерьмо. Ибо для начала использования включаешь для LALR граматики режим генерации GLR и все. Потом можешь дополнительно наварачивать для решения своих проблем, но включается влегкую.

Если же ты не понимаешь, что GLR непригодно для хаков, поэтому его и выбросили, то ты тупица. Что, впринципе, было видно с самого начала.