>> существует 2 вида объектов: value types и reference types,
А вот unsafe pointer — он value-type или reference-type? Он ведь не обычный указатель, по типу того, что используется в Си, так, и не обычная объектная ссылка? Так сколько он байт занимает?
Не, он не передаёт ссылку. Он передаёт уже поля объекта, а не сам объект — так называемые dehydrated entity. Это сделано для того, чтобы не хранить объекты (т.к. кеш второго уровня может быть и не в вашем адресном пространстве приложения), а так же для того, чтобы испытывать меньше проблем с рассинхронизацией данных между БД, кешем и разными сессиями Hibernate
Немного непонятно. Форт-машина — это же не только иллюзорный автомобиль (VM), это ведь ещё и компилятор/интерпретатор, так?
Вот J1 — он на лету умеет транслировать, или программу для него надо кросс-компилятором собирать, чтобы на выходе исключительно маш.код получился? Как сам процесс разработки под него выглядит, вы не в курсе случайно?
Просто нереально охренительно, если честно. Читал на одном дыхании, как повесть про шпионов. Не верится, что у нас занимаются такими увлекательными вещами.
А про «Beep» в ПФП тоже ведь вы писали, да?
Свой вариант, описываемый вот таким монологом: "- You want this? Sorry, can't do it. Flash is dead. Not possible in HTML yet. Design something else or wait a few years please"
Прямо здесь? Окей. Не секрет, что SSE4.x предназначается для ускорения процедур криптографии и обработки видеопотоков.
Скажем, есть задача нахождения двумерной разницы между двумя соседними кадрами (прямоугольные массивы), умноженных на некоторый коэффициент. Или задача размытия изображения.
Можете привести пример кода, который будет успешно свекторизован в SSE 4.1/4.2 компилятором Intel? Желательно указать использованные хинты, если они есть.
Скажите, а на вебинаре будет затронута тема про SSE4.Х, или вы планируете ограничиться примерами SSE2, по которым, собственно, вопросов и нету?
Не смог найти этого на сайте
SSE2 — это, конечно, здорово; и хорошо, что компиляторы подобрались вплотную к автоматической векторизации.
Но вот в чём вопрос — счас широко распространён такой девайс, Intel Core iX (3, 5,7), неважно. У него внутри свой хорошо оптимизированный под векторные инструкции RISC-агрегат. У этого агрегата есть ассемблер, называется SSE4.X + AVX. То, что этот девайс умеет ещё и x86 код «исполнять» (ну, как «исполнять», эмулировать в микрокодах) — это такое legacy, мало связанное с тем, что он хорошо умеет на самом деле. Intel рады бы отказаться от legacy, да пока не могут.
Так вот, суть вопроса: когда же хотя бы родные Intel-компиляторы смогут воспользоваться этими преимуществами? Счас кроме как раскладывать вручную алгоритм в базис из псевдофункций intrinsics, которые транслируются в этот самый SSE-ассемблер, путей нету никаких.
Эээ… Так ComVisible и использование tlb — это уже обращение к COM-маршаллеру, так что обойтись без COM не удалось.
Насчёт проблем с освобождением ресурсов — могу посоветовать их решить ручным управлением ресурсами в unmanaged dll (синий блок) и запуском COM-подсистемы в режиме out-of-process.
Конечно, то, что вы привели, это CISC-команда. Которая процессором транслируется в набор RISC-команд. Погуглите, что такое микрокод, и как обновляются прошивки процессоров — даже Pentium такое умеет
Отличный сайт, душевный очень. Не слушайте разговоров про «жесть дизайн» и про «это надо очень любить сайт, чтобы пользоваться этим [....]».
Главное то, что сайт даёт людям всё, что от него ждут: атмосферу раз, возможность поделиться ощущениями два, свести вируальную встречу к реальной три, и ещё много-много чего.
Отдельного внимания заслуживает классификация + теги, ещё и доступные через url.
Мне очень понравился. Долгой жизни вашему проекту!
Нет, конечно, с чего вы взяли про научную дискуссию?
Просто пичалька, что такие статьи выпускаются, не пройдя корректуру со стороны технических экспертов, которые знают, что, например, x86 внутри уже давно RISC-процессор, а x86-команды эмулирует, и могли бы развеять хотя бы те мифы, что:
* Android это OpenSource
* OpenSource это то же, что и FreeSource
* RISC это то же самое, что ARM
* Программы для многоядерных процессоров нельзя запускать на одноядерном
* Все обязаны делать, как эппл — одна программа в один момент времени
* Android не сможет адекватно загрузить более чем одно ядро
… можно продолжать и продолжать
Верно. Даже разные потоки способны исполняться на разных ядрах (если, конечно, не выставлена привязка к конкретному ядру).
А вот в исходной статье рассуждения на уровне обывательских мифов про ARM, процессоры, многоядерность, opensource и т.п.
>> В Виндовс как ОС такого нет, у нее закрытый код, поскольку она является интеллектуальной собственностью Майкрософт.
А в андроиде открытый, да? А покажите
>> Многие скажут, что есть Windows 7
Многие скажут, что есть Windows 8
>> Надо либо делать программу, в которой указывать, что вот эти команды идут тут, на этом ядре, а эти – на этом. Либо тогда просто все команды идут одно ядро. Тогда частота двухъядерного процессора будет равняться частоте одного ядра, и работать он будет как одноядерный.
>> RISC — это укороченные команды последовательные, одна команда идет за другой.
Извините, но я в шоке от ваших познаний. Вы бы почитали какую-нибудь теорию по процессорам, что ли. Фантазируете, а базы никакой под этим нет. В итоге получается типа того: Я джва года хочу такую игру..
Думаю, что лучше бы Mono в браузер вогнали как стандарт. По совокупности причин: языки — какие угодно — хоть типизированные, хоть нет, рантайм бегает и стреляет, тулинг в виде IDE уже есть, уже полно разработчиков
А вот unsafe pointer — он value-type или reference-type? Он ведь не обычный указатель, по типу того, что используется в Си, так, и не обычная объектная ссылка? Так сколько он байт занимает?
Вот J1 — он на лету умеет транслировать, или программу для него надо кросс-компилятором собирать, чтобы на выходе исключительно маш.код получился? Как сам процесс разработки под него выглядит, вы не в курсе случайно?
А про «Beep» в ПФП тоже ведь вы писали, да?
Есть ещё такая шутка: "- Что такое кодревью? — Ну так: сидишь, читаешь код, ревёшь"
Скажем, есть задача нахождения двумерной разницы между двумя соседними кадрами (прямоугольные массивы), умноженных на некоторый коэффициент. Или задача размытия изображения.
Можете привести пример кода, который будет успешно свекторизован в SSE 4.1/4.2 компилятором Intel? Желательно указать использованные хинты, если они есть.
Не смог найти этого на сайте
Но вот в чём вопрос — счас широко распространён такой девайс, Intel Core iX (3, 5,7), неважно. У него внутри свой хорошо оптимизированный под векторные инструкции RISC-агрегат. У этого агрегата есть ассемблер, называется SSE4.X + AVX. То, что этот девайс умеет ещё и x86 код «исполнять» (ну, как «исполнять», эмулировать в микрокодах) — это такое legacy, мало связанное с тем, что он хорошо умеет на самом деле. Intel рады бы отказаться от legacy, да пока не могут.
Так вот, суть вопроса: когда же хотя бы родные Intel-компиляторы смогут воспользоваться этими преимуществами? Счас кроме как раскладывать вручную алгоритм в базис из псевдофункций intrinsics, которые транслируются в этот самый SSE-ассемблер, путей нету никаких.
Непорядок, не находите?
Насчёт проблем с освобождением ресурсов — могу посоветовать их решить ручным управлением ресурсами в unmanaged dll (синий блок) и запуском COM-подсистемы в режиме out-of-process.
Можно же просто в желтом квадрате, который «managed dll» объявить кокласс-переходник, и его инстанциировать в native dll (синий квадрат)?
Главное то, что сайт даёт людям всё, что от него ждут: атмосферу раз, возможность поделиться ощущениями два, свести вируальную встречу к реальной три, и ещё много-много чего.
Отдельного внимания заслуживает классификация + теги, ещё и доступные через url.
Мне очень понравился. Долгой жизни вашему проекту!
Просто пичалька, что такие статьи выпускаются, не пройдя корректуру со стороны технических экспертов, которые знают, что, например, x86 внутри уже давно RISC-процессор, а x86-команды эмулирует, и могли бы развеять хотя бы те мифы, что:
* Android это OpenSource
* OpenSource это то же, что и FreeSource
* RISC это то же самое, что ARM
* Программы для многоядерных процессоров нельзя запускать на одноядерном
* Все обязаны делать, как эппл — одна программа в один момент времени
* Android не сможет адекватно загрузить более чем одно ядро
… можно продолжать и продолжать
А вот в исходной статье рассуждения на уровне обывательских мифов про ARM, процессоры, многоядерность, opensource и т.п.
А в андроиде открытый, да? А покажите
>> Многие скажут, что есть Windows 7
Многие скажут, что есть Windows 8
>> Надо либо делать программу, в которой указывать, что вот эти команды идут тут, на этом ядре, а эти – на этом. Либо тогда просто все команды идут одно ядро. Тогда частота двухъядерного процессора будет равняться частоте одного ядра, и работать он будет как одноядерный.
>> RISC — это укороченные команды последовательные, одна команда идет за другой.
Извините, но я в шоке от ваших познаний. Вы бы почитали какую-нибудь теорию по процессорам, что ли. Фантазируете, а базы никакой под этим нет. В итоге получается типа того: Я джва года хочу такую игру..