Но, вот, чтобы реализовать например CLI(command line interface), не хуже, чем это сделано у Cisco, нам нужен плюсовик, чтобы не заморачиваться с ежесекундными сегфолгами, при построении дерева команд и при auto completion.
ты телефон свой включаешь, как было бы классно, что если бы он уже работал, когда ты клавишу отпустил только что, а у тебя уже вай-фай, загруженные фотки, ну и т.д.
«Single Entry, Single Exit» was written when most programming was done in assembly language, FORTRAN, or COBOL. It has been widely misinterpreted, because modern languages do not support the practices Dijkstra was warning against." (с) Чо-чо сказать-то хотел?
Жабо-питоно-руби-расто-проблемы приведенные к виду фич. Там же напихали других абстракций, которых в сишечке не было и никогда не будет. Теперь можно и покудахтать что гото не нужен.
В жопу иди. Я когда в *** работал уже тогда этот neon к bootloader'y применял, и на асме писал, а не интринсиксы использовал, но мейнтейнер сказал, что при переключении контекста, регистры неона не сохраняются в контексте задач, что бы performance был лучше, благо, на этапе загрузчика, там нет даже режима ядра, а вот в рейде это очень даже применяется.
Но, ведь ты же ни разу не осведомлен в вышесказанных словах...
в 99% случаев я пишу точно так же, как и в 1990-м году. особых отличий нет :) точнее, они есть, но они не в С, а в моей башке. опыта стало поболее, я изобретаю меньше велосипедов.
что касается статьи - ничего такого особого он там не открыл. всё это давно известно и сложностей в освоении не вызывает. из странного и принципиально нового в новых стандартах С появились разве что динамические массивы (и то это спорный вопрос, нужны они или нет). остальное - косметика, оптимизации, мелкие улучшения.
да фиг знает. приходилось писать CLI на C. есть же библиотеки и уже написанные готовые компоненты. не обязательно всё с нуля городить. библиотеки мелкие, компактные, в embedded всё компилится на ура. там плюсы как-то некуда особо пихать. не того масштаба задача.
это даже не столько проблема старых компилеров, сколько специфика самих архитектур. иногда просто невозможно реализовать некоторые вещи из-за особенностей железа. так что оптимизациями баловаться можно в основном на мейнстримовых железках, и то аккуратно. там тоже баги бывают. пару лет назад мне попались ксеоны, которые как-то неправильно синхронизировали кэш. я чуть мозг не вывихнула на отладке, а потом оказалось, что таки аппаратный баг. а в эмбеддеде всё куда сложнее. там багов больше и сюрпризы могут ожидать разработчика в самых неожиданных местах.
/me .oO( Неужели еще кто-то верит, что царь хоть что-то пишет )
я помню что он писал какие-то примеры числодробилок на ЛОР-е
но раз у него такой богатый опыт и знания (наверняка они без, собственно, кода, не появились из ниоткуда), пусть предоставит на обозрение публики
Если очень серьезно, то... За примеры я буду благодарен любому. Linux kernel - это отдельная парафия, я туда не суюсь. gnu coreutils - нечитабельный вырвиглазный ужас. Sqlite вроде неплох, но там чёрт ногу сломит...
ох ты ж ёперный ты театр!
я тут недавно хотела было немного оптимизировать одну утильку для тестирования, нарытую соратниками в интернетах. открыла код, а там почти такое же. плюс комментарии на китайском. мне стало грустно и желание оптимизировать куда-то исчезло.
пукан пригорел? асм и интринсиксы не имеют отношение к оптимизации компилятора - все по-прежднему делается ручками, разве что в последнем случае есть шанс что все заскедулется как надо, а не как фантазирует разработчик.
а вот к оптимизации можно отнести, например, автовекторизацию и гцц вполне её умеет для неона.
ну так о каких таких нереализованных оптимизациях simd идет речь?
ps
а так в этих ваших интернетах все эксперты и бьют себя пяткой в грудь, а на деле пшик... так что хз что ты там писал и писал ли вообще, больше смахивает на то что просто наслушался от старших товарищей, а теперь ретранслируешь...
эта прога сильно смахивает на брейнфак, без особой цели. а я чота опасаюсь переполнения кэша под вечер. завтра первый рабочий день после долгих выходных, как-никак. поэтому надо беречь психику. я лучше помедитирую на топик про потокобезопасность перед сном. там тоже простыня кода, но он более лучше перевариваемый.
не ты ли утверждал что компиляторы не поддерживают некоторые оптимизации (привидя впоследствии в качестве примера simd) для arm/mips даже если проц в него может?
если то general purpose архитектура, то зачастую с оптимизациями там не так уж плохо. если же специализированная, то тут, скорее всего, ничего круче вендорного компилятора нет.
вендоры частенько те ещё подлянщики. как-то пыталась собрать компилятор для недо-мипса китайского. и обычный gcc, покусанный на предмет нереализованных инструкций, упорно давал неоптимальную работу с памятью (программы жрали непомерно много), а проприетарный, закрытый, как-то пережёвывал всё и упаковывал с учётом особенностей того проца. и фиг из них вытрясешь эти особенности реализации. реверс-инжинирить компилятор мне точно не хотелось. но SDK с закрытым кодом меня раздражают.
дык, куда вендору эти компиляторы? без проца он один фиг не нужен никому даром. а на миллионы процессоров купят всего один компилятор. я вообще считаю, что софт для разработки под железо должен прилагаться бесплатно. покупатель заплатил за железки, он хочет писать софт. чем больше железок продано - тем выгоднее для вендора. а если к железяке нет доступных средств разработки, то кому она нужна? а внутри это один фиг gcc покусанный, скорее всего. ничего нового никто не изобретает. а если бы была поддержка в gcc, то рынок сбыта железок стал бы гораздо шире. всякие студенты бы начали железки изучать, они бы получили распространение. а так сидеть на закрытом рынке специфических корпоративных потребителей, которые ещё непонятно, купят или не купят продукт - это сомнительная выгода.
Когда-то на лоре какой-то пацан выкатил тему, где на на какой-то скул-фигне(вроде на скулайте) переделывает из номера телефона в ид оператора или как-то так.
Начался срач, там мне пацаны доказывали, что скул не тормазит и прочее - его пилят лучшие пацаны, ты говно - где код, запили лучше. В конечном итоге темка свелась к «портянка с ифами быстрее в сотни раз»(я уж не говорю о дка, тут форфан кешепроблема) - так и вышло. Это та портянка на миллион рпс. Именно за эту портянку снесли меня, а возможно даже тему.
Так было уже сотни раз, ведь именно по этой причине никакая обезьяна не попытается со мною посоревноваться в конкретной задаче.
Это функция, которая переводит номера вида «89125152318» - в ид оператора сс.
Давай. Вот тема: есть многослойный FITS-файл, скажем, с полутысячей (==M) изображений, снятых с КМОП-матрицы в недеструктивном режиме каждые N секунд во время экспозиции N*M. Формат кадра: 1024x1024 пикселя, 16 бит.
Задача: придумать оптимальную очистку изображения от шумов, чтобы методика работала на обычном компьютере (можно подключить CUDA) с 2-4ГБ оперативы, 2-4 ядра и >256 графических ядер с 1-2ГБ графической оперативы.
Задача: придумать оптимальную очистку изображения от шумов
Какое отношение это имеет к теме?
чтобы методика работала на обычном компьютере
Работала и запилена - это разные вещи. Я не собираюсь писать код, который ламерок сможет спастить. Я пишу под то, что интересно мне.
(можно подключить CUDA) с 2-4ГБ оперативы, 2-4 ядра и >256 графических ядер с 1-2ГБ графической оперативы.
Т.е. куда там будет с 2-мя гигами, а нормального камня нет.
Я не пишу гуйню для домохозяек.
В целом как всегда мы видим - адепт ставит условия не относящиеся к теме, странно что гуй не попросил - вернее пытается съехать на свою узкоспециализированную тему. С такой постановкой ты уже обделался.
Я пишу а) так, как хочу я. б) под то, что хочу я. в) я не собираюсь разбираться в твоих проблемах. Не тебе мне ставить условия.
Если ты хочешь, чтобы я что-то написал за тебя в какой-то узкой теме - я уже говорил как это делается. Консультируешь и оцениваешь мои изваяние на тему фильтров - ты, реализую я их под то, что интересно мне. Вся логика там останется - она универсальна(естественно линукс-онли - ифдефов под маздайку ты сам может натыкать), кроме filter() - он микроахитектурноспецифичный. Далее у тебя уже не возникнет проблем самому свести это к общему виду, либо попросить об этом меня. Либо попросить меня запилить фильтры под не интересные мне таргеты.
So, do NOT do this:
uintmax_t arrayLength = strtoumax(argv[1], NULL, 10);
void *array[];
array = malloc(sizeof(*array) * arrayLength);
/* remember to free(array) when you're done using it */
Do THIS instead:
uintmax_t arrayLength = strtoumax(argv[1], NULL, 10);
void *array[arrayLength];
/* no need to free array */