Вся правда о целочисленных типах в C

size_t — единственный правильный тип индексов.

Вся правда о целочисленных типах в C

Таким образом, вполне законны ситуации типа sizeof(char)>sizeof(long).

Не бывает так.

n1570, 6.2.5p8:

For any two integer types with the same signedness and different integer conversion rank
(see 6.3.1.1), the range of values of the type with smaller integer conversion rank is a
subrange of the values of the other type.

6.3.1.1p1:

The rank of long long int shall be greater than the rank of long int, which
shall be greater than the rank of int, which shall be greater than the rank of short
int, which shall be greater than the rank of signed char.

Вся правда о целочисленных типах в C

Стандарт — один из основных документов, которым я руководствуюсь в своей деятельности.

Меня всегда удивляет как «чтение стандарта вслух» вызывает восторженные и удивлённые возгласы «да вы что?», «не может быть!» даже у senior программистов Си.

Вся правда о целочисленных типах в C

Не раскрыт вопрос про size_t, ptrdiff_t, intptr_t, uintptr_t.

Зонд Atlas RIPE

А ещё Atlas выполняет множество других измерений для различных экспериментов. Например, Atlas был одним из ключевых в измерении доступности сайтов в IPv6 Day.

Демонстрация сбоев программы при отсутствии барьеров памяти

Если в процессоре обойтись без «этих оптимизаций» то вы получите Intel386 с соответствующей производительностью.

Демонстрация сбоев программы при отсутствии барьеров памяти

В x86 реализован total store ordering, поэтому проблемы там совсем не так ярко выражены как на других платформах.

А out-of-order execution не совсем к месту. Процессор может быть OOO, но с различными store buffer, которые всё поставит в «правильном» порядке с точки зрения программиста.

Makefile для самых маленьких

Если изменятся заголовочные файлы, ваш мейкфайл ничего не пересоберёт.

Шаблоны на C. Да! На чистом С. Не С++

1. Boost.Preprocessor
2. Уж лучше наверное на m4 или на python сгенерировать всё что нужно…

Интересная логика Random access итераторов в STL контейнерах

RandomAccessIterator — это по духу указатель. Поэтому вычитание даёт расстояние.

Интересная логика Random access итераторов в STL контейнерах

В такой формулировке — соглашусь. И я никогда не говорил что checked STL — плохая вещь как концепция.

Просто меня задела фраза:
> На дебаг режим это не распространяется.
Которая подразумевает что для дебаг-режима есть какие-то особые требования conformance.

Интересная логика Random access итераторов в STL контейнерах

> Но для < > <= и >= нет.
И снова нет! Он определён в случае если два указателя указывают в один и тот же объект. [expr.rel]

Но это не важно, вы-то говорили про строгое равенство:
> Они могут оказаться равными даже если указывают на разные области памяти.

Интересная логика Random access итераторов в STL контейнерах

Требования стандарта не делятся на требования семантики, эффективности и ещё какие-то. Они все равноправны с точки зрения conformance. И если дебаг-проверки превращают мой nlogn алгоритм, использующий lower_bound в нереальный n^2, который не завершится в ближайший час даже на тестовых данных — то это баг реализации.

Интересная логика Random access итераторов в STL контейнерах

> А если стандарт почитать?

Мне почему-то кажется что я его читал побольше вашего…

[expr.eq]p1:

Two pointers of the same type compare equal if and only if they are both null, both point to the same function, or both represent the same address (3.9.2).

[basic.compound]p3:

A valid value of an object pointer type represents either the address of a byte in memory (1.7) or a null pointer (4.10).

[intro.memory]p1:

Every byte has a unique address.

> Какого размера указатель на x86? Старом x86, 16 битном, с сегментными регистрами. Чтобы полностью адресовать дынные нужно хранить и значение регистра и смещение от начала сегмента.

Исходя из цитат, приведённых выше, этот подход не соответствует стандарту. Каждый байт должен иметь уникальный адрес, который хранится в указателе. Полноценным указателем может считаться только far pointer.

Интересная логика Random access итераторов в STL контейнерах

Пункт стандарта в студию.

Hint: его нет. В стандарте вообще нет термина «дебаг режим».

Интересная логика Random access итераторов в STL контейнерах

> Они могут оказаться равными даже если указывают на разные области памяти

Так быть не может никогда.

А вот что может быть: malloc() и realloc() по стандарту возвращает указатель на новый объект, который отличается от остальных указателей. Поэтому компилятор может во время оптимизации считать что все области памяти не алиасятся и спокойно делать store forwarding как в этом примере:

$ cat /tmp/zzz.c
#include <stdio.h>
#include <stdlib.h>
 
int main() {
  int *p = (int*)malloc(sizeof(int));
  int *q = (int*)realloc(p, sizeof(int));
  *p = 1;
  *q = 2;
  if (p == q)
    printf("%d %d\n", *p, *q);
}
$ ./Release/bin/clang -O3 /tmp/zzz.c
$ ./a.out 
1 2

— blog.regehr.org/archives/767

Интересная логика Random access итераторов в STL контейнерах

Не логично. O(N) проверка в lower_bound не соответствует требованиям сложности, указанным в стандарте.

Интересная логика Random access итераторов в STL контейнерах

Совет на миллион: почитайте, наконец, стандарт C++ (про итераторы, контейнеры и undefined behavior) и перестаньте удивляться задокументированному и логичному поведению языка (при условии что вы знаете правила игры, описанные в стандарте). Если вы находитесь на уровне «написать аналог std::vector» то ни Хабр, ни Вивипедия, при всём уважении, не могут быть авторитетными источниками.

ARM NEON скининг

Я и не обещал идеального результата. Но ведь просто подобрать нужные опции — это не неделя работы.

ARM NEON скининг

Latest clang:
pastebin.com/U2eEhcjY

Только первая функция (достаточно чтобы увидеть результат). Изменения исходного кода — добавил квалификатор restrict:

void transformPointNormal4x3Weight_NoW(const Matrix44f * __restrict__ pmat, const Vec4f * __restrict__ pVerticiesNormals, PN *__restrict__ poutPN)
{
  const Matrix44f& mat = *pmat;
  PN &outPN = *poutPN;

Команды:

./Release/bin/clang -cc1 -triple armv7-apple-darwin9 -target-abi aapcs  -emit-llvm -O3 /tmp/aaa.cc
./Release/bin/opt -O3 -tbaa -vectorize -bb-vectorize -bb-vectorize-req-chain-depth=3 /tmp/aaa.ll -S | ./Release/bin/llc -O3