- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
void ** __attribute__((noinline)) findVoidSortMap(void ** list,void *key)
{
if (!list) return 0;
if (!*list) return 0;
unsigned int count= **(unsigned int**)list;
char *p=(char*)*list;
p+=4;
Element *b=(Element *)p;
long long skey=(long long)key;
while (count>0) {
void** kt=(void**)&b[count>>1];
long long rkey=(long long)kt[0];
if (skey==rkey) return (void**)&kt[1];
if (skey>rkey) {b+=(count>>1)+1;count--;}
count=count>>1;
}
return (void**)-1;
}
Follow us!
В 2015 году. Круто.
А автору сего предложения не помешала бы практика языка "русский".
16я строка намекает на какую-то структуру данных.
Указатель на указатель пустоты, минус один, это же очевидно!
Есть какие голые цифры?
На 90-100х?
>В среднм как интел вдвое большей частоты
А за счёт чего получается такой большой IPC? И там же джва режима - один нативный, другой эмуляция x86.
>но очень зауисит от теста гдето лучше гдето хуже
Практически весь софт в той или иной мере годами точился под интел (80% рынка не хухры-мухры). Ассемблерные вставки и прочие специфичные тюны пройдут мимо эльбруса.
Надо делать на это скидку. Вообще думал будет много хуже. А так 65нм, миллиард транзисторов, неплохое энергопотребление и очень неплохой как для отечественной разработки (пусть и спижженой) пирфоманс.
Его под векторизацию затачивали. Там даже DSP можно программировать на подмножестве крестов :) Где-то на сайте МЦСТ есть методички "как помочь компилятору векторизировать код", которая и близко не похоже на код в посте.
> В среднм как интел вдвое большей частоты
Вот это я читал больше года назад и с тех пор ничего конкретнее.
> 70 тыс.р.
Ясно
Откуда цифра?
>и анальную смазку на остаток средств
Мсьё знает толк...
Тарасу предложи, пока у него бабло не кончилось. Пусть свои поделия попортирует.
Оффтоп: удивительно, насколько паршиво в STL сделан поиск по ключу в сортированных векторах.
P.S. lower_bound() и upper_bound()?
по моей шкале отвратительности - NaN
А теперь предположим, что вектор структур отсортирован по полю (имя/ид/дата/етц), у меня есть значение поля, и я хочу найти соответствующую структуру...
equal_range с кастомным компаратором?
Если ключи не уникальны - equals_range() с тем же компаратором (или lower_bound() + upper_bound()). А тут чего плохого?
Т.е. либо писать разные компараторы, либо писать в одном три унылых bool operator() в одном компараторе.
А недавно нужно было отсортировать массив индексов другого массива, содержащего числа...
В общем, линз вроде пистоньего key=f определённо не хватает.
Всем стоять-бояться, LINQ for C++ спешит на помощь!
Что линзы то делают?
Стоп, ты предлагаешь в язык ввести синтаксический сахарок только из-за одной неправильнонаписанной функции? круто бро. функцию исправленную просто надо добавить
Ты с дуба упал?
Я говорю не о синтаксическом сахаре, а об организации API.
В пистоне функция сортировки опционально берёт на вход функцию, отображающую множество элементов массива на произвольное упорядоченное множество. Linq-овский OrderBy работает так же. Такое апи позволило бы иметь один компаратор на sort, upper_bound, lower_bound, equal_range.
Как-то так, наверное:
P.S. Хотя вроде бы нашлась какая-то реализация function_traits.
P.S. Хотя... борланд же мёртв.
Да, это фейл. Тут только цель руками указывать остается... comparator.for_lower_bound(), comparator.for_sort() и т.п. Жопа.