пишут пишут много и эффективно. И на плюсах и на голом си. И смысл в этом есть иногда. Чтож.. очень жаль что вы не понимаете как на плюсах можно писать =).
1.5 киловатта звука НЕ_RMS в машину даже и не запихать. На стадионах по 12 киловатт звука ставят =). А если вы про RMS - то это вообще тут ни к селу ни к городу =)
однако это технически не так уж просто осуществить, ибо для того чтобы слепить 1 кадр, нужно иметь информацию мало того что о всём кадре в целом, так ещё и о 8 кадрах вперёд и назад (не говоря уже о общем битрейте всей ленты, но это фигня). Так вот и получается что эти конвееры должны будут между собой перекидывать СТОЛЬ большое количество информации, что становятся неэффективными.
Причём загвоздка не просто в том что кадру нужно знать какие будут следующие и какие были предыдущие - кадр ссылается на информацию в прошлых и следующих. А значит если кодируется кадр номер 15, потом доходим до 20-го, то впринципе может быть необходимость кадр номер 15 после этого изменить =).
Короче кодирование - это жопа ещё та. Легко разбить на потоки примитивное - mpeg2 или divx3, divx4 (mpeg4) уже сложнее, а вот с x264 совсем тухлятина =).
Кстати именно по этой же причине всё это безобразие распоковать - тоже тяжело, чтобы показать всего лишь 1 кадр, нужно его слепить из горы ссылок сзади/спереди. И именно поэтому x264 для проигрывания требует куда больше ресурсов.
1) порядок урлов важен всё же. Чтож теперь и вьюшки в спец. порядке располагать?
2) если вам в руки попадёт даже маленький проект с такими штуками - замучаетесь искать нужную вьюшку
3) если я не торможу - у вас в urlpatterns при каждом запросе что ли всё добавляется? Эт же в теле with_url надобно делать.
4) ...
ну в общем идея, чтобы уж сразу получить по заднице - надобно в листе рассылок джанги постить =).
да не спор это. Просто разговариваем, я вот с умилением вспоминаю старые добрые времена когда над си с линейками сидел =).
Подытожив, скажу - когда опускаетесь в плюсах в си для оптимизации - вы ведь отдельные штуки уже на "си" пишете, а не на "плюсах"? =) Стало быть в си вы опускаетесь как раз чтобы побыстрее всё сделать =).
Как язык C++ - хорош, разве что в критичных к скорости выполнения местах игнорировать возможности Си - явно не стоит. Вот и всё.
я имел ввиду - сознательно не думают, а не "не знают" =).
вы поймите, я же не доказываю того что плюсы дерьмо. Или наоборот =).
если есть голова на плечах, и ты ТОЧНО знаешь размер строки которую нужно записать в память, ты просто не будешь постоянно (только в данном конкретном случае) следить за длиной строки как делает stdlib. Равно как и не будешь искать в памяти нулевого байта как конца строки. Ты уже будешь знать. И в данном случае сможешь сделать совсем крохотное ускорение.
Плюсы почти всегда можно допилить до си. Это да. Как минимум до такого уровня чтобы разница была не существенна. Вот только фактически много вещей будет написана на си при этом =).
да, вот про эту разницу кешгринда я и говорил. VTune я тоже прогонял, но мельком и сейчас не вспомню что там было толком.
То что в си это всё сложнее писать - это факт, который не оспариваем-с =).
Я правда вообще без всяких обёрток делал. Неудобно - да. Можно легко накосячить случайно и заполучить чудовищно коварный баг - да. Но быстрее.
Моё мнение (в целом не меняющееся) если писать всё на си, иногда запариваясь сильно (там где это ценно), иногда не очень - то в целом программа будет быстрее чем на плюсах. Другое дело что иногда вообще запариваться не хочется в совсем не критичных к скорости выполнения участках - тут бы возможности плюсов были бы очень даже кстати. Вот так и получается что пишем на плюсах, но часто опускаясь в си. Я теперь и вовсе часто поднимаюсь в питон =). Благо, цепляется он к си на раз-два.
давайте будем слушать друг друга =). Я про "ООП возможности" и их влияние и не говорил - слишком тяжело это объективно сравнить. А вы меня путаете с кем-то другим.
Я так же и не говорил что на си нужно заворачивать свой функционал куда-то в функции. Как раз экономия 1 вызова функции там где она вызывается миллионы раз и делает своё дело, хоть и писать это приходится тысячу раз.
на си всегда следишь за тем, когда что-то в память записываешь и стараешься это как можно меньше дергать. Вместо копирования кусков данных - ссылаешься на начало и конец данных в памяти.
На плюсах обычно люди вообще не думают об этом.
Отсюда и складывается общая разница в скорости. И то что очевидно вам, вовсе не значит что очевидно всем. С++ стиль работы со строками это именно std::string.
Да и работа со строками и с данными - это всё таки очень частая задача, разве нет? Я вот частенько писал http-сервера, так там вообще после того как запрос в память попадает - всё время работы над ним (парсинг заголовков и тому подобный хлам) - эти байтики на тех же местах памяти и лежали. Это была версия сервера номер тысяча =). Первые варианты на плюсах были намнооооого медлительнее.
сейчас же скажу
а) кол-во тактов не пропорционально времени выполнения (а о времени выполнения я ни в одном комментарии и не говорил).
б) прогоните через cachegrind и покажите чего там буит (если есть время конечно, вечером я это и сам сделаю)
в) двухкратное превышение в скорости - это уже затыкает ребят наверху кто о плюсах слишком лестно высказывался (не вы)
д) в пять раз очень вряд ли - но вот ускорить, хороший урок =) Попробую.
говоря x264 я и имел ввиду hdvideo, хотя толком разницы нету. Cell - ну фиг знает, чего о нём болтать если пока достать нереально =). Может и круто, а может и не очень. Дури в нём много, но она вся "тупая".
Да и сонька хвасталась, что cell может _проигрывать_ много hdtv одновременно. Если конечно мне не изменяет память =). Интересно а сколько hd1080p потяент core2quad?
вы ещё скажите, что архитектура машин в кластере будет разной =)
тем не менее - тот же dnetc - вон вам кластер из миллиона машин и работает =). Я правда не уверен что можно раскопать исходники серверной части. Но зато в клиентской там даже асм присутсвует =))
Проблема только в алгоритме. Ну и ещё в том что не каждую задачу можно распараллелить. Например кодирование видео - не так уж просто разбить на кластер, ибо там кодирование каждого блока (обычно 16x16) связано с каждым соседним и ещё и все блоки в каждом кадре связаны между собой (косвенно). Ещё и кадры ссылаются друг на друга на 10-12 в каждую сторону (x264). Попробуйте расспараллелить такое =). 2-3 потока сейчас и то даются огого какой ценой (качество кодирования ХУЖЕ). Даже если взять ролик 60 минут, разбить его на два по 30мин, скдоировать на разных машинках, а потом склеить - качество будет снова хуже =). Особенно если динамика сцен в начале и в конце сильно разная.
Кстати по сабжу. Проблемы все же решать по мере поступления. Думаю если интел слепит 32-ядерник. И если это полезет на десктоп - уж явно будет придумана какая-либо технология для виртуализации всей этой многоядерной мощи на низком уровне. Им ведь вовсе не обязательно инструкции выполнять всегда на одном кристалле - кеш L2 с инструкциями-то общий.
Ибо то же кодирование разбить на 32 потока - это ж ппц. Это ВОЗМОЖНО, если потоки будут как сумасшедшие друг с другом общаться. Но выигрыш в скорости будет крайне сомнителен, имхо. Ситуация будет как с GIL в питоне. Все орут - а если отключить, то все становится в 2 раза медленнее =)
1.5 киловатта звука НЕ_RMS в машину даже и не запихать. На стадионах по 12 киловатт звука ставят =). А если вы про RMS - то это вообще тут ни к селу ни к городу =)
однако это технически не так уж просто осуществить, ибо для того чтобы слепить 1 кадр, нужно иметь информацию мало того что о всём кадре в целом, так ещё и о 8 кадрах вперёд и назад (не говоря уже о общем битрейте всей ленты, но это фигня). Так вот и получается что эти конвееры должны будут между собой перекидывать СТОЛЬ большое количество информации, что становятся неэффективными.
Причём загвоздка не просто в том что кадру нужно знать какие будут следующие и какие были предыдущие - кадр ссылается на информацию в прошлых и следующих. А значит если кодируется кадр номер 15, потом доходим до 20-го, то впринципе может быть необходимость кадр номер 15 после этого изменить =).
Короче кодирование - это жопа ещё та. Легко разбить на потоки примитивное - mpeg2 или divx3, divx4 (mpeg4) уже сложнее, а вот с x264 совсем тухлятина =).
Кстати именно по этой же причине всё это безобразие распоковать - тоже тяжело, чтобы показать всего лишь 1 кадр, нужно его слепить из горы ссылок сзади/спереди. И именно поэтому x264 для проигрывания требует куда больше ресурсов.
1) порядок урлов важен всё же. Чтож теперь и вьюшки в спец. порядке располагать?
2) если вам в руки попадёт даже маленький проект с такими штуками - замучаетесь искать нужную вьюшку
3) если я не торможу - у вас в urlpatterns при каждом запросе что ли всё добавляется? Эт же в теле with_url надобно делать.
4) ...
ну в общем идея, чтобы уж сразу получить по заднице - надобно в листе рассылок джанги постить =).
вы же уже ответили в продолжение нашей с тов. karayrov-эм беседы.
Подытожив, скажу - когда опускаетесь в плюсах в си для оптимизации - вы ведь отдельные штуки уже на "си" пишете, а не на "плюсах"? =) Стало быть в си вы опускаетесь как раз чтобы побыстрее всё сделать =).
Как язык C++ - хорош, разве что в критичных к скорости выполнения местах игнорировать возможности Си - явно не стоит. Вот и всё.
Peace! )
вы поймите, я же не доказываю того что плюсы дерьмо. Или наоборот =).
если есть голова на плечах, и ты ТОЧНО знаешь размер строки которую нужно записать в память, ты просто не будешь постоянно (только в данном конкретном случае) следить за длиной строки как делает stdlib. Равно как и не будешь искать в памяти нулевого байта как конца строки. Ты уже будешь знать. И в данном случае сможешь сделать совсем крохотное ускорение.
Плюсы почти всегда можно допилить до си. Это да. Как минимум до такого уровня чтобы разница была не существенна. Вот только фактически много вещей будет написана на си при этом =).
То что в си это всё сложнее писать - это факт, который не оспариваем-с =).
Я правда вообще без всяких обёрток делал. Неудобно - да. Можно легко накосячить случайно и заполучить чудовищно коварный баг - да. Но быстрее.
Моё мнение (в целом не меняющееся) если писать всё на си, иногда запариваясь сильно (там где это ценно), иногда не очень - то в целом программа будет быстрее чем на плюсах. Другое дело что иногда вообще запариваться не хочется в совсем не критичных к скорости выполнения участках - тут бы возможности плюсов были бы очень даже кстати. Вот так и получается что пишем на плюсах, но часто опускаясь в си. Я теперь и вовсе часто поднимаюсь в питон =). Благо, цепляется он к си на раз-два.
Я так же и не говорил что на си нужно заворачивать свой функционал куда-то в функции. Как раз экономия 1 вызова функции там где она вызывается миллионы раз и делает своё дело, хоть и писать это приходится тысячу раз.
на си всегда следишь за тем, когда что-то в память записываешь и стараешься это как можно меньше дергать. Вместо копирования кусков данных - ссылаешься на начало и конец данных в памяти.
На плюсах обычно люди вообще не думают об этом.
Отсюда и складывается общая разница в скорости. И то что очевидно вам, вовсе не значит что очевидно всем. С++ стиль работы со строками это именно std::string.
Да и работа со строками и с данными - это всё таки очень частая задача, разве нет? Я вот частенько писал http-сервера, так там вообще после того как запрос в память попадает - всё время работы над ним (парсинг заголовков и тому подобный хлам) - эти байтики на тех же местах памяти и лежали. Это была версия сервера номер тысяча =). Первые варианты на плюсах были намнооооого медлительнее.
сейчас же скажу
а) кол-во тактов не пропорционально времени выполнения (а о времени выполнения я ни в одном комментарии и не говорил).
б) прогоните через cachegrind и покажите чего там буит (если есть время конечно, вечером я это и сам сделаю)
в) двухкратное превышение в скорости - это уже затыкает ребят наверху кто о плюсах слишком лестно высказывался (не вы)
д) в пять раз очень вряд ли - но вот ускорить, хороший урок =) Попробую.
Да и сонька хвасталась, что cell может _проигрывать_ много hdtv одновременно. Если конечно мне не изменяет память =). Интересно а сколько hd1080p потяент core2quad?
тем не менее - тот же dnetc - вон вам кластер из миллиона машин и работает =). Я правда не уверен что можно раскопать исходники серверной части. Но зато в клиентской там даже асм присутсвует =))
Проблема только в алгоритме. Ну и ещё в том что не каждую задачу можно распараллелить. Например кодирование видео - не так уж просто разбить на кластер, ибо там кодирование каждого блока (обычно 16x16) связано с каждым соседним и ещё и все блоки в каждом кадре связаны между собой (косвенно). Ещё и кадры ссылаются друг на друга на 10-12 в каждую сторону (x264). Попробуйте расспараллелить такое =). 2-3 потока сейчас и то даются огого какой ценой (качество кодирования ХУЖЕ). Даже если взять ролик 60 минут, разбить его на два по 30мин, скдоировать на разных машинках, а потом склеить - качество будет снова хуже =). Особенно если динамика сцен в начале и в конце сильно разная.
Кстати по сабжу. Проблемы все же решать по мере поступления. Думаю если интел слепит 32-ядерник. И если это полезет на десктоп - уж явно будет придумана какая-либо технология для виртуализации всей этой многоядерной мощи на низком уровне. Им ведь вовсе не обязательно инструкции выполнять всегда на одном кристалле - кеш L2 с инструкциями-то общий.
Ибо то же кодирование разбить на 32 потока - это ж ппц. Это ВОЗМОЖНО, если потоки будут как сумасшедшие друг с другом общаться. Но выигрыш в скорости будет крайне сомнителен, имхо. Ситуация будет как с GIL в питоне. Все орут - а если отключить, то все становится в 2 раза медленнее =)