Forwarded from 𝐅𝐎𝐗
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from OpenPCB
طبق گفته FFmpeg پچ جدید باعث شده یه تابع مهم تو پردازش ویدیو ۳.۴۶ برابر سریعتر بشه. ماجرا اینه که یکی از کانتریبیوترها به اسم mkver اومده تابع add_8x8basis_sse3 رو که قبلاً با C نوشته شده بود رو کاملا با اسمبلی x86 بازنویسی کرده و خروجی هم شده همین جهش سرعت جدی.
دلیلش اینه که کامپایلرهای GCC و Clang وقتی با فلگ O3 کد رو کامپایل میکنند، معمولاً یه سری حلقه هایی که اصلاً قرار نیست زیاد اجرا بشن رو باز میکنن و کد رو حجیمتر میکنن. اینجا هم اون فانکشن رو از ۱۷۶ بایت رسونده به ۱۴۰۶ بایت! تو این مدل پردازشها، چون دستورهای خاص و عجیبغریبی مثل pmulhrsw وجود داره، کامپایلر همیشه انتخابهای درستی نمیکنه. دولوپرهای FFmpeg هم میگن: «باشه، خودمون درستش میکنیم.» نکته مهم اینه که لزوماً کد C مشکل نداره! این رفتار کامپایلر تو مرحله بهینهسازیه که گاهی خودش دردسر درست میکنه.
این اولینبار نیست FFmpeg از اسمبلی برای گرفتن نهایت قدرت سختافزار استفاده میکنه واین همون بحث معروف چند وقت پیشه که چرا پلیر dav1d که چندتا آدم معمولی ساختنش، بعضی جاها از libgav1 گوگل بهتره. جواب همون همیشگیه: وقتی دقیق میدونی چی میخوای و خودت دستی کد اسمبلی رو مینویسی، خروجی معمولاً از نسخهی تولیدشده توسط کامپایلر بهتره.
یه سوال هم که همیشه مطرح میشه اینه که «چرا این مشکلات رو به سازندههای کامپایلر گزارش نمیکنن؟» گزارش میدن، ولی تا نسخه جدید کامپایلر بیاد مدتها طول میکشه. یعنی عملاً بهترین کار اینه که خودشون همزمان دست به آچار باشن و مشکل رو دور بزنن.
برای همین پروژههایی مثل FFmpeg اینقدر ارزشمندن. از یه طرف همیشه تو بهینهترین حالت ممکنه، از یه طرف دیگه همین مواردی که پیدا میکنن عملاً به کل کامیونیتی C و کامپایلرها سود میرسونه و باعث میشه ابزارهایی که همه استفاده میکنن، کمکم بهتر بشن.
📺Source
📡openpcb
دلیلش اینه که کامپایلرهای GCC و Clang وقتی با فلگ O3 کد رو کامپایل میکنند، معمولاً یه سری حلقه هایی که اصلاً قرار نیست زیاد اجرا بشن رو باز میکنن و کد رو حجیمتر میکنن. اینجا هم اون فانکشن رو از ۱۷۶ بایت رسونده به ۱۴۰۶ بایت! تو این مدل پردازشها، چون دستورهای خاص و عجیبغریبی مثل pmulhrsw وجود داره، کامپایلر همیشه انتخابهای درستی نمیکنه. دولوپرهای FFmpeg هم میگن: «باشه، خودمون درستش میکنیم.» نکته مهم اینه که لزوماً کد C مشکل نداره! این رفتار کامپایلر تو مرحله بهینهسازیه که گاهی خودش دردسر درست میکنه.
این اولینبار نیست FFmpeg از اسمبلی برای گرفتن نهایت قدرت سختافزار استفاده میکنه واین همون بحث معروف چند وقت پیشه که چرا پلیر dav1d که چندتا آدم معمولی ساختنش، بعضی جاها از libgav1 گوگل بهتره. جواب همون همیشگیه: وقتی دقیق میدونی چی میخوای و خودت دستی کد اسمبلی رو مینویسی، خروجی معمولاً از نسخهی تولیدشده توسط کامپایلر بهتره.
یه سوال هم که همیشه مطرح میشه اینه که «چرا این مشکلات رو به سازندههای کامپایلر گزارش نمیکنن؟» گزارش میدن، ولی تا نسخه جدید کامپایلر بیاد مدتها طول میکشه. یعنی عملاً بهترین کار اینه که خودشون همزمان دست به آچار باشن و مشکل رو دور بزنن.
برای همین پروژههایی مثل FFmpeg اینقدر ارزشمندن. از یه طرف همیشه تو بهینهترین حالت ممکنه، از یه طرف دیگه همین مواردی که پیدا میکنن عملاً به کل کامیونیتی C و کامپایلرها سود میرسونه و باعث میشه ابزارهایی که همه استفاده میکنن، کمکم بهتر بشن.
📺Source
📡openpcb
❤🔥2