LINUX.ORG.RU

Corrode, проект транслятора из C в Rust, получил финансирование Mozilla

 , corrode, , ,


3

8

Джеймс Шарп (James Sharp), отметившийся ранее в проекте X.org, в начале мая 2016 начал разработку проекта Corrode, целью которого является трансляция программ, написанных на C, в исходный код на Rust. Corrode написан на Haskell и распространяется под GNU GPLv2.

На текущий момент проект обзавёлся сообществом, научился транслировать некоторые программы и обрёл первые ближайшие цели и ориентиры: трансляция неподдерживаемых программ на C в Rust. В качестве субъекта тестирования был выбран исходный код CVS — давно устаревшей, но ещё используемой, системы контроля версий. Разработка и поддержка CVS была остановлена в 2008 году, а первая до сих пор не закрытая remote-уязвимость была обнаружена в 2012 году.

Джеймс рад сообщить, что он получил финансовый патронаж Mozilla, и как минимум на ближайшие несколько месяцев он может сконцентрироваться на своём свободном проекте. Mozilla рассматривает Corrode не только в качестве полуавтоматического транслятора для устаревшего кода, но и как статический анализатор нового поколения для кода на C.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 6)

Ответ на: комментарий от tailgunner

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

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Единственные кто им размахивают - это хейтеры, которые приплетают его к месту и нет.

RazrFalcon ★★★★★
()
Ответ на: комментарий от eao197

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

Мозиле явно не хватает вашей экспертной оценки их работы.

RazrFalcon ★★★★★
()
Ответ на: комментарий от eao197

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

Прежде чем говорить об убийстве производительности, имеет смысл провести замеры.

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

Ну да, нить на кору - выбор Ъ-профессионалов.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Мозиле явно не хватает вашей экспертной оценки их работы.

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

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

Прежде чем говорить об убийстве производительности, имеет смысл провести замеры.

Да тут выше asaw как раз очередной замер и провел.

Ну да, нить на кору - выбор Ъ-профессионалов.

Не, нить на кору — старперство и провинциальность. А вот 100 нитей на кору — это модно и молодежно. Главное же что? Что язык хипстерский, а проект экспериментальный. Нахрен кому-то какие-то нормальные результаты.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

какой эксперт придумал

тю, в смысле, какой эксперт? да в какого «убивателя С++» не ткни.

У них же всех один и тот же набор претензий к С++, растущий из привычки писать на С++ как на жаве. Одной из фишек такого подхода является порождение охренительного количества потоков на каждый чих. тысячи потоков.

тут даже раст ни при чем. это идеология такая

i36_zubov
()
Ответ на: комментарий от i36_zubov

привычки писать на С++ как на жаве. Одной из фишек такого подхода является порождение охренительного количества потоков на каждый чих. тысячи потоков.

Я, конечно, не эксперт по Java-идиомам, но мне казалось, что там принято иметь ExecutorService и посылать ему задачи (а новомодный Stream API умеет в data-level параллелизм сам), а использовать в клиентском коде голые Thread-ы — дурной тон.

Softwayer ★★
()
Ответ на: комментарий от Softwayer

да есть такое но в том то все и дело что это НОВОЕ API.

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

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

i36_zubov
()
Ответ на: комментарий от i36_zubov

про жаву есть тыщи ссылок в гугле про java thousand threads.

c++ thousand threads

About 560,000 results

java thousand threads

About 361,000 results

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

...но я понимаю, откуда такой баттхерт

tailgunner ★★★★★
()
Ответ на: комментарий от mersinvald

я пишу про то что вижу сам. а я вижу абсолютно одинаковые завывания c++хейтеров.

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

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

i36_zubov
()
Ответ на: комментарий от tailgunner

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

i36_zubov
()
Ответ на: комментарий от i36_zubov

Ты главное будь уверен в своей правоте и в том, что твой C++ — идеален, и у меня всегда будут джоб-офферы на контрасте с подобными тебе личностями :)

mersinvald ★★★★★
()
Ответ на: комментарий от eao197

на Rust-е

Сомневаюсь что в близжайшие 5 лет раст отхватит достаточную долю рынка, чтобы появились rust-only вакансии. Сейчас знание раста «будет преимуществом» в паре Российских компаний, забугорные не мониторил.

на D

Сомневаюсь что когда-нибудь вообще на D будут вакансии.

Но я не про ЯП, я про гораздо более прозаичный аспект работы HR и интервьюверов. Я про адекватность и трезвый взгляд на мир.

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Я про адекватность и трезвый взгляд на мир.

Тогда у вас шансов больше, чем у 75% пишущих на LOR-е. Как минимум :)

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Прежде чем говорить об убийстве производительности, имеет смысл провести замеры.

Да тут выше asaw как раз очередной замер и провел.

Да, это был экспертный замер производительности.

Главное же что?

Очевидно же, что главное - это то, что ты назовешь главным.

tailgunner ★★★★★
()
Ответ на: комментарий от i36_zubov

я не удивлен, что жабнутые пишут на c++

Или сплюплюснутые пишут на жабе.

у жабистов так бомбит от языка программирования, который к ним не относится

Наверное, удобно считать жабистом каждого, кому не нравится Си++.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Или сплюплюснутые пишут на жабе.

С учетом того, сколько народу пришло в ИТ в последние 10 лет (т.е. когда C++ потеряли какую-либо популярность), это сильно вряд ли.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

337-ми потоках на загрузку 2-х сайтов

Дык зато как удобно на распределенном кластере запускать то будет!

ИМХО, Servo это не о «выкатить замену Gecko или Webkit», а об экспериментах и поле для исследований на тему высокопараллельных алгоритмов.
С ростом количества вычислительных ядер (а тенденция есть) это даст свои плоды, да и я не думаю что перенести всё это на гринтреды на манер Go и распихать их по малому количеству posix-нитей будет проблемой. Во всяком случае это намного меньшая проблема, нежели распараллеливание существующих браузерных движков.

Плюс это дает приятные бонусы вроде ускорения обработки CSS с помощью GPU, которые можно портировать в продакшн-продукты

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 3)
Ответ на: комментарий от mersinvald

Дык зато как удобно на распределенном кластере запускать то будет!

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

я не думаю что перенести всё это на гринтреды на манер Go и распихать их по малому количеству posix-нитей будет проблемой.

Блин, вы себе хотя бы отдаете отчет, что распределение задач по короутинам (коими и являются goroutines в Go) и распределение задач по полноценным OS threads с точки зрения максимальной производительности — это ну совершенно разные подходы? И что одно к другому ну не может просто так свестись?

Это только мне кажется, или степень вменяемости Rust-оманов по ходу дискуссии стремится к нулю?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Рендеринг страничек для браузера в кластере

Забыл, что без тега [sarcasm] у публики ЛОРа ломается парсер

Потоки:
- IPC через очереди и shared memory
- Системный шедулер

Корутины:
- IPC через очереди и, внезапно, shared memory
- Шедулер в рантайме бинарника

Огромная разница, да, прямо настолько, чтобы перенос кода был сложнее переписывания на параллельный манер движков с легаcи из 90х.

степень вменяемости Rust-оманов по ходу дискуссии стремится к нулю

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

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от mersinvald

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

- Системный шедулер
- Шедулер в рантайме бинарника
Огромная разница, да

Етить-колотить. Да разница огромная, да.

Если попытаться читать

Если пытаться читать дебидилетантов, то шансов вычитать там что-то разумное не прибавиться.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Нечего сказать @ Придерись к терминологии.
Я прекрасно знаю что такое IPC, как оно расшифровывается и где применяется.
Замени на слово синхронизация, если оно более общее и нравится тебе больше.

Если пытаться читать дебидилетантов

Нечего сказать @ Дави илитарностью и «прожитыми годами»

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Замени на слово синхронизация

Да, путать «синхронизацию» и «обмен информацией», а потом апеллировать к «дави илитарностью» — это мощно. «Нечего сказать» (с)

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Придраться к терминологии и не сказать ничего по теме, когда речь о параллельных алгоритмах, а не о способах обмена информации — это называется «слив».

mersinvald ★★★★★
()
Ответ на: комментарий от eao197

Да разница огромная, да.

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

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

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от mersinvald

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

Если он не отдает себе в этом отчет, то он запросто может заявить о сливе. Не о своем, естественно.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Опять придирки к терминам и давка авторитетом от нечего сказать? Это уже скучно, давай что-то новое

mersinvald ★★★★★
()
Ответ на: комментарий от i36_zubov

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

но не могу ибо..

Ибо хороший ЯП это паскаль, и поправить баг-другой в ПО на нём совсем не против, а вот если цэцэпэшная программа сильно сломалась - то всплакнём и проводим в последний путь.

Napilnik ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

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

Это в плюсах-то?..

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

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

Они не второсортные, но в их потребности остальным следует глубоко вникать если самих эта тема вдруг поджарит.

А грузить мозг, если речь идёт о изучении нового, дело совсем не лишнее.

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

Napilnik ★★★★★
()
Ответ на: комментарий от DarkEld3r

То есть, проблема в том, что язык из коробки не предлагает обёрток для всех системных функций?

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

А надо поменьше а не «все системные функции» системного использовать по умолчанию, тогда пореже будут случаться такие «приколы» когда программа созданная убунтологами никак не вкорячивается на федору. Те же кути, оставим на время тему падучести, как-то абстрагируются от винды, создают внутри программы посикс среду, которая нафиг не нужна ОС. Ну так желательно и от дистрибутивов линукса точно также отгородиться, всё равно ведь тяжёлые программы, особенно с графикой сейчас жрут много.

Ну тут ты противоречишь сам себе: или абстрагируем от всего чего можно - тогда «превращаемся в ОС» или «ужасы» использования системных функций напрямую.

Меня, как пользователя кед, совсем не радуют те революции на пустом месте, которые устраивают кутешники. Разрабам кутей просто некогда нормально доводить свою систему до ума если всё время надо всё ломать и показывать фокусы посторонней публике желающей каждый день свежего представления от одной и той же труппы клоунов. Их бы повар так удивлял: сегодня вы едите кухню французскую, завтра голанскую, потом папуасскую, а потом негуманоидных рас - каждый день всё свежее и новое, отказаться нельзя!

Есть ощущение, что вопрос не понимаю, но всё-таки: естественно, если из других библиотек торчат другие типы, то надо что-то делать. А линковка-то тут при чём?

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

Napilnik ★★★★★
()
Ответ на: комментарий от RazrFalcon

Именно поэтому на нём никто не пишет.

Так уж совсем никто - а скайп в винде на каком местном ЯП написан?

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Те же кути, оставим на время тему падучести, как-то абстрагируются от винды, создают внутри программы посикс среду, которая нафиг не нужна ОС.

ОМГ. Вам к доктору.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Уже давно на C#

В макоси, про винду у меня такой информации нет.

Napilnik ★★★★★
()
Ответ на: комментарий от RazrFalcon

Опять ты фонтанируешь бессвязными эмоциями, наверно перепутал лор с сериалом для домохозяек.

Napilnik ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

i36_zubov
()
Ответ на: комментарий от Sociopsih

Когда ты донейтишь, ты не продаешь, а покупаешь.

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

Я не путаю донейт с инвестициями.

dr_dobermann
()
Ответ на: комментарий от Napilnik

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

Такого я не говорил. Запоминать сигнатуры функций - тупо, но иметь общее представление о том какие инструменты имеются в наличии полезно. Это относится и к прочим «базовым вещам». Скажем, семантика перемещения в плюсах: нет смысла помнить в подробностях для каких классов она реализована, но иметь представление о механизме будет совсем не лишним. Тем более, что многие штуки не специфичны для какого-то конкретного языка.

DarkEld3r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.