Адаптация seeker (утилита замеряющая среднее время поиска) для Mac OS X

Исходная утилита seeker описана тут: http://www.linuxinsight.com/how_fast_is_your_disk.html, но под Mac OS она не компилируется. Ниже представлена небольшая модификация исправляющая сей недочет.

seeker.c

#define _LARGEFILE64_SOURCE

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <errno.h>

#include <time.h>

#include <signal.h>

#include <sys/fcntl.h>

#include <sys/ioctl.h>

#ifdef __APPLE__

#include <sys/disk.h>

#define off64_t off_t

#define lseek64 lseek

#define BLKGETSIZE DKIOCGETBLOCKCOUNT

#else

#include <linux/fs.h>

#endif

#define BLOCKSIZE 512

#define TIMEOUT 30

int count;

time_t start;

void done()

{

time_t end;

    

time(&end);

    

if (end < start + TIMEOUT) {

printf(".");

alarm(1);

return;

}

    

if (count) {

        printf(".\nResults: %d seeks/second, %.2f ms random access time\n",

               count / TIMEOUT, 1000.0 * TIMEOUT / count);

}

exit(EXIT_SUCCESS);

}

void handle(const char *string, int error)

{

if (error) {

perror(string);

exit(EXIT_FAILURE);

}

}

int main(int argc, char **argv)

{

char buffer[BLOCKSIZE];

int fd, retval;

unsigned long numblocks;

off64_t offset;

    

setvbuf(stdout, NULL, _IONBF, 0);

    

printf("Seeker v2.0, 2007-01-15, "

      "http://www.linuxinsight.com/how_fast_is_your_disk.html\n");

    

if (argc != 2) {

printf("Usage: seeker <raw disk device>\n");

exit(EXIT_SUCCESS);

}

    

fd = open(argv[1], O_RDONLY);

handle("open", fd < 0);

    

retval = ioctl(fd, BLKGETSIZE, &numblocks);

handle("ioctl", retval == -1);

printf("Benchmarking %s [%luMB], wait %d seconds",

      argv[1], numblocks / 2048, TIMEOUT);

    

time(&start);

srand(start);

signal(SIGALRM, &done);

alarm(1);

    

for (;;) {

offset = (off64_t) numblocks * random() / RAND_MAX;

retval = lseek64(fd, BLOCKSIZE * offset, SEEK_SET);

handle("lseek64", retval == (off64_t) -1);

retval = read(fd, buffer, BLOCKSIZE);

handle("read", retval < 0);

count++;

}

/* notreached */

}

Изменения: off64_t и lseek64 под BSD не нужны, off_t и так уже 64 битный,  плюс другой заголовочный файл и другое имя константы

ARM vs Intel Atom (часть 1)

С давних пор ARM и x86 шли разными путями, решения ARM использовался в основном в embedded решениях (терминалы, маршрутизаторы, КПК, телефоны), а x86 - в ПК и ноутбуках. ARM отличается энергоэффективностью, но ценой уменьшения производительности, а x86 - большей производительностью, но гораздо меньшей энергоэффективностью.

Но с недавних пор, компания Intel стала активнее интересоваться мобильным рынком и выпустила процессоры Atom, при проектировании которых во главу угла ставилась энергоэффективность, точек соприкосновения стало больше. В тоже время процессоры ARM становятся с каждым годом все производительнее. Сейчас ARM активно используется в смартфонах и планшетах (на различных "мобильных" операционных системах, как-то: iOS, Android, WinCE и т.д.), Atom - в нетбуках и планшетах (в основном на базе Windows 7, реже Android).

Вот почему мне стало интересно сравнить производительность современных ARM и Atom. Но как можно сравнить производительность различных архитектур? Можно было бы найти программы, работающие по одному и тому же алгоритму под обе платформы, в идеале код должен быть одинаковым, что усложняет задачу. Или написать такой тестовый набор самому, что я и решил сделать :).

Чтобы не писать совсем уж искусственные тесты, я решил использовать известные алгоритмы. Для начала мой выбор пал на алгоритм сжатия данных, для его осуществления выбрал известную кроссплатформенную библиотеку zlib. Эта библиотека часто используется разработчиками и написана на чистом Си, без специфических оптимизаций под какую-либо платформу.

Для тестирования использовал имеющиеся в наличии устройства.

ARM: Apple iPad 2, работающий на процессоре A5 (двухядерный Cortex A9) на частоте 1 ГГц, операционная система iOS.

Atom: домашний минисервер на базе материнской платы Intel D510MO c процессором D510 (два ядра + hyper-threading) на частоте 1.66 ГГц, операционная система Ubuntu 10.04.2 LTS 32-бит.

В основе программы - функция, использующая zlib:

void compress_file(const char *fname_in, const char *fname_out)

{

    FILE *f_in = fopen(fname_in, "rb");

    gzFile fz_out = gzopen(fname_out, "wb9"); //используем максимальную степень сжатия - 9

    

    char buf[8*1024];

    

    size_t byte_read;

    while ((byte_read = fread(buf, 1, sizeof(buf), f_in)) > 0)

    {

        gzwrite(fz_out, buf, byte_read);

    }

    

    fclose(f_in);

    gzclose(fz_out);

}

Программа однопоточная, задействуется только одно ядро.

Время работы под iOS замерялось с помощью [NSDate timeIntervalSinceReferenceDate], а на Ubuntu - с помощью функции time.

На iOS применялся стандартный компилятор для XCode 4 - gcc 4.2 с опциями -O2 -mtune=cortex-a8 -march=armv7-a (но mtune и march особого влияния не оказали, настройки по умолчанию armv7 видимо достаточно), на Ubuntu - gcc 4.4 с -O2 -mtune=native -march=native.

Осуществлялась обработка 300Мб текстового файла, на выходе получился 70Мб файл.

Результаты:
Atom D510 ~290 сек
A5 ~440 сек

D510 быстрее A5 в 1,5 раза. Но учитывая что тактовая частота D510 больше в 1.66 раз, производительность же на единицу частоты у A5 получается несколько выше. Интересные результаты, не так ли? :]