KingMaximax, неправильно, нельзя "обойти виртуальную машину", код в любом случае на ней выполняется. Это главное отличие C# от нативных C\C++, но речь в статье вообще не об этом.
Есть понятие управляемого и неуправляемого кода. Так вот шарп по-умолчанию использует управляемый код, это когда все данные жестко контролируются средой, ты не управляешь памятью напрямую и не можешь критически накосячить, а ненужные данные удаляются автоматически (то есть утечки памяти практически невозможны).
Но существует и возможность работать с неуправляемым кодом, использовать прямой доуступ к памяти, о чем собственно статья. Это считается небезопасным (отсюда и ключевое слово unsafe), потому что работоспособность, стабильность и защищенность программы начинает на 100% зависеть от уровня криворукости программиста.

Hanabishi, т.е. он пытался обойти виртуальную машину, если я правильно понял. Это как внутренняя система безопасности проверки жизненности цикла программы, что-то наподобие в этом роде. Она добавляет 100+ лишних килобайт. Но её вроде отключать можно, но лучше не надо, иначе есть риск поменять ОЗУ. Мой продвинутый друг в программировании занимался подобным, но потом перешёл на ассемблер из-за паранойности C++\C#, врать не буду, но это не совсем точные сведения. Или я снова туплю?

KingMaximax, какой-то странный вопрос. Синтаксически C# происходит от C, что вроде очевидно. Соответсвенно и форма записи указателей взята оттуда.
Но несмотря на внешнюю схожесть, внутри C# работает абсолютно по-другому. Даже в небезопасном контексте с прямым доступом к памяти, код все равно выполняется на виртуальной машине.

Мне кажется или это похоже на C++ в C#?
Не знаю, я пользуюсь mem alloc'ом в некоторых своих подопытных детишках по C++ только...
У меня свои шаманства с бубном, короче.

uranus, быстрее чем функции стандартной библиотеки можно добиться и не прибегая к небезопасному коду (написать собственную реализацию), тут о другом речь.

Hanabishi:

Если не ошибаюсь, на хабре доказывали, что таким способом можно добиться большей скорости, чем у аналогичных функций стандартной библиотеки. Только не кидайте камнями, может, я не так понял просто.

Или foreach, вообще внутри всё запаковано

Msey, плохой случай. Надо писать так, чтобы проверки границ в сейф коде убирались оптимизатором.
То есть допустим в случае

//a - некоторый массив
for(int i = 0; i < a.Length; i++)

проверки границ не будет. И разницы производительности с небезопасным вариантом тоже. Потому что оптимизатор умный.
Лезть ради этого в небезопасный контекст - крайне сомнительное занятие, нужно просто правильно писать в безопасном.

Забыл написать для чего это вообще надо. Для начала использования небезопасного кода нужно стараться избегать (помните что 95% дырок безопасности в истории это вина программиста, прозевавшего проверки в неуправляемом коде). Реально же практическое применение я вижу в двух вариантах:

1. Если в проекте используется неуправляемая библиотека. И то очень специфически, если у вас структуры данных прибиты гвоздями. В большинстве же случаев можно обойтись маршалингом в безопасным контексте.
2. Вы кулхацкер, который по каким-то причинам захотел использовать именно шарп. Тогда думаю вы в этой статье и не нуждаетесь. Хотя кстати я могу привести личные примеры такого применения )