Как можно встроить скрипт внутрь браузера стандартными средствами браузера?
ЗЫ:
Теперь школота, прочитав статью, будет пытаться активно хакать Электронные журналы.)
Будет стимул изучать программирование и IT технологии, что в принципе неплохо.
Нативный код — нативный.
Особенно на языках типа C, C++, Delphi и т.п.
При компиляции этого кода хороший компилятор может производить оптимизацию под конкретное железо. Если задать ему соотв. ключи.
С другой стороны — вы правы, проги ведь распространяются обычно в собранном виде.
Если собирались для amd, а выполняются на intel'е, то вообще даже могут не выполниться.
Опрос железа и несколько вариантов сборок помогут. Костыль однако.
GC разрешает проблему циклических ссылок.
Реализовано примерно так:
В отдельном потоке крутится в цикле со спячками или без некий код, который проходит по графу зависимостей «ссылка-объект-ссылка» пытаясь найти те объекты, до которых он не может добраться.
Ну например, есть объект A, который держит объект B, который держит объект C, который держит объект B. Удаляем B из A (закончилась область действия A) — GC декрементирует счетчик и если счетчик не станет нулем, попытается в отдельном потоке добраться из корня графа до B, если не сможет или такого корня нет, то удалит B, а затем и C.
Как то так.
Политик управления можно множество придумать.
Ну и ничто же ведь не мешает написать фреймворк/библиотечку со смарт-поинтерами и запускающимся GC в отдельном потоке. (ну там и аллокатор памяти, разумеется). Три-в-одном.
Хочешь, подключай инклуд и пользуйся, хочешь подключай инклуд — не пользуйся этими смартами, — GC будет просто спать.
Ну не знаю.
Меня C++ вполне устраивает.
Ведь для него же есть Qt! Значит 3-30 кнопок я — одним махом!) С любой логикой)
Плюс огромная потенциальная мощь, которую я пользую 10%, но она есть!
Да GC нет, но он мне как то и не особо нужен, к тому же есть умные указатели, к тому же есть вроде как фреймворки с GC на борту. К тому же GC в плюсы грядет в 17 стандарте (или выше).
Не хочу я перескакивать на др. язык, тем более что 90% библиотек, фреймворков и т.д. написаны либо на C либо на плюсах.
Это std::mutex, — это еще ничего. Блокирующий объект синхронизации.
А если чуваки решили неблокирующие lock-free алгоритмы сделать на атомарных операциях?
Берут
en.cppreference.com/w/cpp/atomic/atomic/compare_exchange
нихрена это en.cppreference.com/w/cpp/atomic/memory_order не прочитали, да еще спецом изменили этот параметр и начинаются фокусы.
В стандартную библиотеку эти аргументы добавили видать для большей гибкости.
Если order аргумент в bool compare_exchange_strong( T& expected, T desired, std::memory_order order = td::memory_order_seq_cst ); не трогать, то по умолчанию будет memory_order_seq_cst.
Нехрен трогать этот параметр, если неискушен и не знаешь к чему это приведет.
Вот семейка методов
en.cppreference.com/w/cpp/atomic/atomic/compare_exchange
вот возможные параметры-энумы
en.cppreference.com/w/cpp/atomic/memory_order
Ипануться можно.
Читаешь спецификацию OpenGL — действительно depth test выполняется после fragment shader И управляется glEnable/glDisable (GL_DEPTH_TEST)
А Early вроде как автоматический и действительно не произойдет, если писать в gl_FragDepth или дискард.
Всё через жопу короче и ломает мне шаблоны напрочь. Абсолютное отсутствие логики, ппц.
Может, потому, что спецификация OpenGL очень древняя.
Ну ясно)
А какая разница что называть ядрами.
16 pixel pipes написано.
также написано 16 SIMDS для одной модели 4 SIMDS для другой
Также — 2560 threads как 64 threads x 10 waves x 4 SIMDs на один CU (компьют юнит наверно)
Короче — тоже вынос мозга)) Маркетинговые картинки, а на самом деле у них всего 4 процессора стоят и все, хаха))
Не раскрыта тема goto c неопределенным поведением как здесь например:
goto Label;
for (;;)
{
int p = 0;
Label:
p += 10;
}
Вы что то заикнулись, но ничего не сказали что говорит об этом стандарт.
А что будет здесь:
void f()
{
int i = 10;
int p = 1;
Label:
p = i;
}
main()
{
f();
goto Label;
}
Что будет?
А если вообще метка будет стоять в методе класса, ни одного объекта которого еще не инстанцировано?
А если инстанцирован?
Интересуют ограничения использования goto по стандарту.
интересует строгое изложение фактов, можно со ссылками на авторитетные источники, авторитетных спецов типа Майерса, Страуструпа и т.д.
А то что goto может быть полезен и сократить код и улучшить читаемость в этом нет никаких сомнений.
Понятно.
Ну может быть инженеры GPU в будущем выкинут рабочие группы или изобретут способ перераспределения рабочих групп на разных этапах конвейера, если в настоящее время этого еще нет.
"
perfectdaemon25 марта 2015 в 05:51#
Понимаю, что статья обучающая, но все же предупрежу новичков, что использование discard существенно замедляет работу фрагментного шейдера, как и ветвление ( if ). Это не значит, что нужно отказаться от discard и if, но следует быть осторожным.
kovalexius25 марта 2015 в 21:38#↵↑
Погоди, разве дискард не просто-напросто прерывает работу текущего шейдера, а следовательно
невидимые фрагменты выполняются только до проверки if(d2>r2), далее никаких вычислений и пиксель
просто не перекрашивается и всё? Следовательно, фрагмент с discard заканчивает свою работу быстрее,
чем фрагмент не попадающий в блок с дискардом.
"
Но даже несмотря на то что вы меня убедили насчет простаивания кода, всё равно discard может даже слегка увеличить скорость окрашивания всех фрагментов в пределах статистической погрешности выполнения одного и того же куска кода (тот что под else). Ибо один и тот же кусок кода запускаемый многократно слегка колеблется по времени выполнения. Например, у нас было N одновременно выполняющихся потоков с «кодом под else». Время выполнения всех потоков равно max времени выполнения из всех N. Если мы уменьшим N, возьмем M < N, то возникает вероятность что и max из всех M будет меньше чем max из N
но ведь можно не задавать этот вложенный функтор-делетер бустовскому shared_ptr'у.
К тому же туда третьим параметром передается НЕ ОБЪЕКТ, а АДРЕС ОПЕРАТОРА (), т.е. УКАЗАТЕЛЬ НА ФУНКЦИЮ вложенного класса deleter.
class deleter
{
public:
void operator()(X * p) { delete p; }
};
вот этот void operator()( бла-бла ) {бла-бла} — это описание метода по сути
поэтому здесь
shared_ptr px(new X, deleter());
третий параметр deleter() — это передача указателя на оператор-метод.
Здесь может возникнуть вопрос — почему не передается указатель на объект в котором находится operator(), т.е. deleter*, и перед этим даже не инстанцирован?
Я пока ответа не знаю, думаю, потому, что operator() как бы статический метод, потому что он не имеет права обращаться к полям класса deleter наверное. Надо покурить мануалы.
Что вы имеете в виду под аллокацией deleter'а?
У shared_ptr есть указатель на счетчик и указатель на объект, конструктор, деструктор, конструктор копирования и оператор присваивания, в которых и работает вся его логика. Какая необходимость в аллоцировании некоего deleter'а?
Стараюсь искать офисное.
Плюс еще, как Вы написали, жёны, дети.
ЗЫ:
Теперь школота, прочитав статью, будет пытаться активно хакать Электронные журналы.)
Будет стимул изучать программирование и IT технологии, что в принципе неплохо.
Особенно на языках типа C, C++, Delphi и т.п.
При компиляции этого кода хороший компилятор может производить оптимизацию под конкретное железо. Если задать ему соотв. ключи.
С другой стороны — вы правы, проги ведь распространяются обычно в собранном виде.
Если собирались для amd, а выполняются на intel'е, то вообще даже могут не выполниться.
Опрос железа и несколько вариантов сборок помогут. Костыль однако.
Реализовано примерно так:
В отдельном потоке крутится в цикле со спячками или без некий код, который проходит по графу зависимостей «ссылка-объект-ссылка» пытаясь найти те объекты, до которых он не может добраться.
Ну например, есть объект A, который держит объект B, который держит объект C, который держит объект B. Удаляем B из A (закончилась область действия A) — GC декрементирует счетчик и если счетчик не станет нулем, попытается в отдельном потоке добраться из корня графа до B, если не сможет или такого корня нет, то удалит B, а затем и C.
Как то так.
Политик управления можно множество придумать.
Ну и ничто же ведь не мешает написать фреймворк/библиотечку со смарт-поинтерами и запускающимся GC в отдельном потоке. (ну там и аллокатор памяти, разумеется). Три-в-одном.
Хочешь, подключай инклуд и пользуйся, хочешь подключай инклуд — не пользуйся этими смартами, — GC будет просто спать.
Меня C++ вполне устраивает.
Ведь для него же есть Qt! Значит 3-30 кнопок я — одним махом!) С любой логикой)
Плюс огромная потенциальная мощь, которую я пользую 10%, но она есть!
Да GC нет, но он мне как то и не особо нужен, к тому же есть умные указатели, к тому же есть вроде как фреймворки с GC на борту. К тому же GC в плюсы грядет в 17 стандарте (или выше).
Не хочу я перескакивать на др. язык, тем более что 90% библиотек, фреймворков и т.д. написаны либо на C либо на плюсах.
А если чуваки решили неблокирующие lock-free алгоритмы сделать на атомарных операциях?
Берут
en.cppreference.com/w/cpp/atomic/atomic/compare_exchange
нихрена это en.cppreference.com/w/cpp/atomic/memory_order не прочитали, да еще спецом изменили этот параметр и начинаются фокусы.
В стандартную библиотеку эти аргументы добавили видать для большей гибкости.
Если order аргумент в bool compare_exchange_strong( T& expected, T desired, std::memory_order order = td::memory_order_seq_cst ); не трогать, то по умолчанию будет memory_order_seq_cst.
Нехрен трогать этот параметр, если неискушен и не знаешь к чему это приведет.
Вот семейка методов
en.cppreference.com/w/cpp/atomic/atomic/compare_exchange
вот возможные параметры-энумы
en.cppreference.com/w/cpp/atomic/memory_order
openglinsights.com/pipeline.html
Читаешь спецификацию OpenGL — действительно depth test выполняется после fragment shader И управляется glEnable/glDisable (GL_DEPTH_TEST)
А Early вроде как автоматический и действительно не произойдет, если писать в gl_FragDepth или дискард.
Всё через жопу короче и ломает мне шаблоны напрочь. Абсолютное отсутствие логики, ппц.
Может, потому, что спецификация OpenGL очень древняя.
www.opengl.org/wiki/Early_Fragment_Test
www.opengl.org/wiki/Depth_Test
А какая разница что называть ядрами.
16 pixel pipes написано.
также написано 16 SIMDS для одной модели 4 SIMDS для другой
Также — 2560 threads как 64 threads x 10 waves x 4 SIMDs на один CU (компьют юнит наверно)
Короче — тоже вынос мозга)) Маркетинговые картинки, а на самом деле у них всего 4 процессора стоят и все, хаха))
goto Label;
for (;;)
{
int p = 0;
Label:
p += 10;
}
Вы что то заикнулись, но ничего не сказали что говорит об этом стандарт.
А что будет здесь:
void f()
{
int i = 10;
int p = 1;
Label:
p = i;
}
main()
{
f();
goto Label;
}
Что будет?
А если вообще метка будет стоять в методе класса, ни одного объекта которого еще не инстанцировано?
А если инстанцирован?
Интересуют ограничения использования goto по стандарту.
интересует строгое изложение фактов, можно со ссылками на авторитетные источники, авторитетных спецов типа Майерса, Страуструпа и т.д.
А то что goto может быть полезен и сократить код и улучшить читаемость в этом нет никаких сомнений.
Ну может быть инженеры GPU в будущем выкинут рабочие группы или изобретут способ перераспределения рабочих групп на разных этапах конвейера, если в настоящее время этого еще нет.
"
perfectdaemon25 марта 2015 в 05:51#
Понимаю, что статья обучающая, но все же предупрежу новичков, что использование discard существенно замедляет работу фрагментного шейдера, как и ветвление ( if ). Это не значит, что нужно отказаться от discard и if, но следует быть осторожным.
kovalexius25 марта 2015 в 21:38#↵↑
Погоди, разве дискард не просто-напросто прерывает работу текущего шейдера, а следовательно
невидимые фрагменты выполняются только до проверки if(d2>r2), далее никаких вычислений и пиксель
просто не перекрашивается и всё? Следовательно, фрагмент с discard заканчивает свою работу быстрее,
чем фрагмент не попадающий в блок с дискардом.
"
Но даже несмотря на то что вы меня убедили насчет простаивания кода, всё равно discard может даже слегка увеличить скорость окрашивания всех фрагментов в пределах статистической погрешности выполнения одного и того же куска кода (тот что под else). Ибо один и тот же кусок кода запускаемый многократно слегка колеблется по времени выполнения. Например, у нас было N одновременно выполняющихся потоков с «кодом под else». Время выполнения всех потоков равно max времени выполнения из всех N. Если мы уменьшим N, возьмем M < N, то возникает вероятность что и max из всех M будет меньше чем max из N
delete 'указатель_на_функцию';
Думаю, неопределенное поведение, seg_fault'ы и т.д.
К тому же туда третьим параметром передается НЕ ОБЪЕКТ, а АДРЕС ОПЕРАТОРА (), т.е. УКАЗАТЕЛЬ НА ФУНКЦИЮ вложенного класса deleter.
class deleter
{
public:
void operator()(X * p) { delete p; }
};
вот этот void operator()( бла-бла ) {бла-бла} — это описание метода по сути
поэтому здесь
shared_ptr px(new X, deleter());
третий параметр deleter() — это передача указателя на оператор-метод.
Здесь может возникнуть вопрос — почему не передается указатель на объект в котором находится operator(), т.е. deleter*, и перед этим даже не инстанцирован?
Я пока ответа не знаю, думаю, потому, что operator() как бы статический метод, потому что он не имеет права обращаться к полям класса deleter наверное. Надо покурить мануалы.
У shared_ptr есть указатель на счетчик и указатель на объект, конструктор, деструктор, конструктор копирования и оператор присваивания, в которых и работает вся его логика. Какая необходимость в аллоцировании некоего deleter'а?