Цитируем с одного специфического сайта:

"На PPlain и PMMX при обращении к невыравненным данным будет теряться по меньшей мере 3 такта, если пересечена граница в 4 байта. Потери будут выше при пересечении границы кэша.

На PPro, PII и PIII невыравненные данные будут стоить вам 6-12 дополнительных тактов, если пересечена граница кэша."

>На современных PC платформах, выравнивание не даёт _НИЧЕГО_. Ну вообще ничего

Уже по личному опыту: 10% на простом цикле в RLE-кодере

> Конечно же при сборке ядра и софта ситуация будет совершенно иной - конфиги будут самостоятельно переписываться после каждой сборки новой версии софтины.

Я пересобираю только ядро для поддержки нового железа и устранения багов. Зачем мне пересобирать софт, если он отконфигурирован, отлажен и работает без нареканий много лет ?

>Нормальные люди выбирают
>А пионеры продолжают
>иметь поддержку
>в своем детсаде.
>Пионеры, а вы в курсе, что с тем же mysql вас хоть завтра вендор может официально послать на три буквы, сменив лицензию, прекратив выкладывать сорсы и прекратив поддержку и выпуск патчей?
>anonymous

Cлишком много понтов от глупого анонимуса, который даже неврубается, что такое GPL.

-falign-functon
-falign-jumps
-falign-labels
-falign-loops
И ешё непонятно для чего, в но коде для x86 почему-то встречается 0x90... :)

frame. У-у-у, как всё запущено. Ещё один пацан. Это про кеш, дружочек. Про кеш, понимаешь ? Кеш, а не оперативная память. В кеше невыровненные данные действительно вызывают большите накладные расходы. Но они в кеш ещё должны попасть и произойти к ним обращение. Но в таком случае никакой компилятор не поможет. Никакие оптимимизационные флаги. Что касается памяти - цитирую умную книгу "На П3 запись невыровненных данных выполняется всего лишь на 3(три)% медленне, а на AMD Athlon даже на 35% быстрее. Нет, это не ошибка. В силу конструктивных особенностей контроллера памяти запись невыровненных данных действительно осуществляется значительно быстрее".

>Но они в кеш ещё должны попасть и произойти к ним обращение. Но в таком случае никакой компилятор не поможет. Никакие оптимимизационные флаги.

Советую для _наглядности_ скомпилировать bzip2 и проверить на скорости архивирования. Спорить с "взрослым дядей" тяжело :-D

> Советую для _наглядности_ скомпилировать bzip2 и проверить на скорости архивирования. Спорить с "взрослым дядей" тяжело :-D


Надо же быть настолько уверненным в своём невежестве. Даже интресно стало.

первый вариант -o1, второй -o1 -falign-functions -falign-jumps -falign-loops -falign-labels

первый
time ./bzip2.o1 bxe6lin.tar.gz

real 0m25.799s
user 0m25.458s
sys 0m0.190s

второй
time ./bzip2.o2 bxe6lin.tar.gz

real 0m25.817s
user 0m25.439s
sys 0m0.190s

И ?

Это касается выравнивания кода. Как получить невыровненные данные, не корёжа кода, мне не известно.

Мы проводили эксперименты с выравниванием данных на наших программах - никакой разницы в скорости на PC. Ряд платформ, таких, как Sparc и M68k, с невыровненными данными вообще не работают. Там как только встречается невыровненный операнд - исключение и падение программы. Есть платформы, где выравнивание не обязательно, но крайне желательно. Это Alpha, к примеру. Она даже гадит в лог, если встречает невыровненные данные, но работает. А PC пофик. Она всеядна.

> ЕСЛИ бОльшую часть аргументов функций мы передаем через регистры, то реальная производительность системы "процессор-кеш-память" сразу вырастает в разы

Чудак.

1. Те страницы памяти, где сидит стек, куда пишутся аргументы по PUSH, с вероятностью 90% и так сидят в кэше, посему выигрыш игрушечный

2. Выигрыш от замены PUSH на MOV в момент вызова функции на фоне времени обращения к устройствам вообще пренебрежимо мал

А с учетом того, что а) 80% работы ядра в том, чтобы сказать девайсу "сделай вот это, данные вон там, и чтобы через DMA" б) переключения контекстов все равно не ускоришь в) практически весь код сложных частей типа VFS построен на указателях на функции и простых циклах, ты не получаешь значимого выигрыша.

Но ты можешь получить выигрышь за счет изменения конфигурации ядра - включения/выключения всяких аудитов, selinux, различных механизмов которыми пользуются драйверы, играми с таймером и preemptible и так далее... Но это уже оптимизации другого уровня.

P.S.: я сам импользую на федоре пересобранную ваниллу. Но отнюдь не ради оптимизации под процессор. И cairo я апдейтил собирая srpm'ку на своем компе - но опять же, для того чтобы задействовать то, что не было включено дистрибутостроителем - а не ради того чтобы ввести флаг -O99

> Cлишком много понтов от глупого анонимуса, который даже неврубается, что такое GPL.

GPL это такая лицензия, которая гарантирует, что когда Mysql AB сменит лицензию на MySQL, то админам останется не просто хер с маслом, а остенется выбор или самим сопровождать этот код и закрывать дырки, либо покупать платную mysql следующей версии с поддержкой и с не-GPL лицензией(они запросто могут сменить лицензию на следующую версию, тк весь код их собственный). Съел да?

А какие флаги лучше?

env |grep FLAGS
CFLAGS=-O3 -ffast-math -fomit-frame-pointer -pipe -march=k8 -mtune=k8 -s
LDFLAGS=-s -Wl,-O1,-zdynsoft,-hashval -Bdirect
...
CXXFLAGS=CFLAGS

x86_64

> О как! И прямо-таки оно не грузит сдуру MD-RAID, кучу SATA/IDE контроллеров и прочего?
Звук и сеть - фиг с ними, можно и через autoloader. А вот с дисковыми контроллерами чуть сложнее.

Что, серьезно? С initrd уже облажались, с использованием XMM в ядре в качестве РОНов - тоже, с INITRD-дисками, занимающими по 8 мегабайд каждый - тоже, теперь настала пора облажаться с лишними модулями md-raid, SATA/IDE дисковых контроллеров и т.д. (на примере неиспользующейся reiserfs3):

title Debian GNU/Linux, kernel 2.6.8-2-686
root (hd0,0)
kernel /vmlinuz-2.6.8-2-686 root=/dev/hda3 ro
initrd /initrd.img-2.6.8-2-686
savedefault
boot

$ uname -sr
Linux 2.6.8-2-686
$ lsmod|grep ide
ide_cd 42656 0
cdrom 40732 1 ide_cd
ide_generic 1408 0
ide_disk 19296 4
ide_core 139940 4 ide_cd,ide_generic,piix,ide_disk
$ modinfo sata_nv
filename: /lib/modules/2.6.8-2-686/kernel/drivers/scsi/sata_nv.ko
author: NVIDIA
description: low-level driver for NVIDIA nForce SATA controller
license: GPL
vermagic: 2.6.8-2-686 preempt 686 gcc-3.3
depends: libata
alias: pci:v000010DEd0000008Esv*sd*bc*sc*i*
alias: pci:v000010DEd000000E3sv*sd*bc*sc*i*
alias: pci:v000010DEd000000EEsv*sd*bc*sc*i*
alias: pci:v000010DEd00000054sv*sd*bc*sc*i*
alias: pci:v000010DEd00000055sv*sd*bc*sc*i*
alias: pci:v000010DEd00000036sv*sd*bc*sc*i*
alias: pci:v000010DEd0000003Esv*sd*bc*sc*i*
$ lsmod|grep sata
$ lsmod|grep sis
$ lsmod|grep via
$ lsmod|grep raid
$ lsmod|grep amd
$ modinfo reiserfs
filename: /lib/modules/2.6.8-2-686/kernel/fs/reiserfs/reiserfs.ko
description: ReiserFS journaled filesystem
author: Hans Reiser <reiser@namesys.com>
license: GPL
vermagic: 2.6.8-2-686 preempt 686 gcc-3.3
depends:
$ lsmod|grep reis
$ lsmod|grep ext
ext3 127240 2
jbd 62616 1 ext3
mbcache 9348 1 ext3
$

а можно узнать про оптимизации которые дали 30% роста в MySQL? Не ради флейма, а что б у себя проверить.

> а можно узнать про оптимизации которые дали 30% роста в MySQL?

Отключение отладки, selinux, security models, kernel preemption, audit, включение DMA для винтов?! :-)

"-O3 -ffast-math -fomit-frame-pointer"

man gcc
Уберите "-ffast-math"! Генерируемый gcc код "-ffast-math" с любыми "-O" может приводить к неправильным результатам вычислений.
Рекомендую для вашего случая использовать вместо "-ffast-math" что-то типа "-m3dnow -mfpmath=sse". Будет и быстрее и стабильнее.
"-fomit-frame-pointer" можно вообще убрать: оно по дефолту включено еще в "-O2".

Ну и включение оптимизаций. Типа "-O3 -march=prescott -mfpmath=sse -msse3 -pipe -s" в ядре и мускле.
Опять же, правка configure от MySQL на предмет "убрать -O2 и -g".

Все с вами понятно. Классический для LORа случай: "'man gcc' не читал, но осуждаю".

Дальнейшее общение с вами действительно бессмысленно.

Да, на моём athlon-xp сдесь копейки:
GCC 4.1-20070108
file: test.tar (233Mb linux 2.6.18.6)
-O2 -march=i686:              bzip -9 test.tar 2:25s
-O2 -march=i686 -faling-*=32: bzip -9 test.tar 2:21s
Больше зависит от архитектуры:
-O2 -march=i686: 2:25s
-O2 -march=i486: 2:39s
На этом я и остановил внимание.
И ещё странности: -march=i686 иногда (в lame,imagemagick к примеру) оказывается немного быстрее, чем -march=athlon-xp

1. Возможно. Но в лучшем случае, в L2. В регистрах проца несколько быстрее. :-)

2. Никто не спорит. И ведь я же писал, что оптимизации влияют только на связку "процессор-кеш-память".

а) Процессор во время ожидания ответа от девайса не простаивает и может выполнять вычислительные задачи. Тем более при работе с девайсом через DMA.
б) Это так.
в) Тут как раз помогают оптимизации по выравниванию кода.

>Но ты можешь получить выигрышь за счет изменения конфигурации ядра - включения/выключения всяких аудитов, selinux, различных механизмов которыми пользуются драйверы, играми с таймером и preemptible и так далее... Но это уже оптимизации другого уровня.

Естественно. :-) Еще ты забыл про включение многопроцессорности (в том числе - multicore и hyperthreading), а так же про игры с шедулерами.

Попробуйте
-O3 -m3dnow -mfpmath=sse -march=k8 -mtune=k8 -s

> -O2 -march=i686: bzip -9 test.tar 2:25s
> -O2 -march=i686 -faling-*=32: bzip -9 test.tar 2:21s

Ничем не должно отличаться "-faling-*=32" сходит в -O2. Разница по времени, скорее всего, вызвана иными причинами (прерывания, работа параллельно выполняющихся задач и т. п.).

> -O3 -m3dnow -mfpmath=sse -march=k8 -mtune=k8 -s

Сорри
-O3 -m3dnow -mfpmath=sse -march=k8 -s
конечно же

frame, какие -O2 -march=i686 ? Вы не отличаете выравнивание от -o2 ? Нда. Вот чем симптом отличается от синдрома, знаете ? Синдром - это совокупность симптомов. Так вот, -O2 и -march=i686 - это совокупность ключей, из которых я оспаривал только касающиеся выравнивания. И то только на PC. Ага ?

>С initrd уже облажались, с использованием XMM в ядре в качестве РОНов - тоже, с INITRD-дисками, занимающими по 8 мегабайд каждый - тоже, теперь настала пора облажаться с лишними модулями md-raid, SATA/IDE дисковых контроллеров

Уууу... А вы вообще читать умеете? Или только писать?

Касательно остального... Зачем было это делать? Достаточно полный вывод dmesg'а и lsmod.

> Все очень просто:

Да все уже поняли, что они м*даки, один ты весь в белом.

> Можете рассказать. Я не знаю. Да и вообще поделками Шапки не > интересуюсь.

Не интересуешься? Т.е. ядро linux не юзаешь? 80% кода всего ядра Linux написано программистами RedHat. Остальное - SUSE и вольные сеятели.

AGPGART DRIVER P: Dave Jones

CPU FREQUENCY DRIVERS P: Dave Jones

i386 SETUP CODE / CPU ERRATA WORKAROUNDS P: Dave Jones

block/elevator.c: * 20082000 Dave Jones

drivers/scsi/advansys.c: Dave Jones

drivers/net/sis900.c: Rev 1.07.09 Feb. 9 2001 Dave Jones

drivers/char/agp/backend.c: * Copyright (C) 2002-2003 Dave Jones

drivers/char/agp/generic.c: * Copyright (C) 2002-2005 Dave Jones

drivers/char/agp/amd64-agp.c:MODULE_AUTHOR("Dave Jones <davej@codemonkey.org.uk>, Andi Kleen");

drivers/char/agp/via-agp.c:MODULE_AUTHOR("Dave Jones <davej@codemonkey.org.uk>");

drivers/char/agp/intel-agp.c:MODULE_AUTHOR("Dave Jones <davej@codemonkey.org.uk>");

drivers/char/agp/nvidia-agp.c: * to work in 2.5 by Dave Jones <davej@codemonkey.org.uk>

drivers/char/agp/ati-agp.c:MODULE_AUTHOR("Dave Jones <davej@codemonkey.org.uk>");

drivers/char/agp/agp.h: * Copyright (C) 2002-2004 Dave Jones

drivers/char/agp/frontend.c: * Copyright (C) 2002-2003 Dave Jones

fs/affs/Changes:- Converted to use 2.3.x page cache [Dave Jones]

arch/x86_64/kernel/setup.c: * Nov 2001 Dave Jones

arch/i386/kernel/smpboot.c: * Dave Jones

/arch/i386/kernel/cpu/cpufreq/powernow-k7.c:MODULE_AUTHOR ("Dave Jones")

arch/i386/kernel/cpu/cpufreq/speedstep-ich.c:MODULE_AUTHOR ("Dave Jones")

arch/i386/kernel/cpu/cpufreq/powernow-k6.c: * (C) 2000-2003 Dave Jones, Arjan van de Ven (arjan@redhat.com)

arch/i386/kernel/cpu/cpufreq/longhaul.h: * (C) 2003 Dave Jones.

arch/i386/kernel/cpu/cpufreq/powernow-k8.c: * Based on the powernow-k7.c module written by Dave Jones.

arch/i386/kernel/cpu/cpufreq/powernow-k7.h: * (C) 2003 Dave Jones.

arch/i386/kernel/cpu/cpufreq/longhaul.c: * (C) 2001-2004 Dave Jones.

arch/i386/kernel/cpu/mcheck/k7.c: * (C) Copyright 2002 Dave Jones

arch/i386/kernel/cpu/mcheck/mce.c: * (c) 2002 Alan Cox <alan@redhat.com>, Dave Jones <davej@redhat.com>

arch/i386/kernel/cpu/mcheck/non-fatal.c: * (C) Copyright 2002 Dave Jones.

Так что не свисти, что RedHat ты не юзаешь. Юзаешь, каждый день и в ОГРОМНЫХ количествах :-)

Как я понял - выравнивание включается при O>=2 c параметрами для заданной архитектуры и которые можно явно задать через -falign-*, так?

>-march=k8

сомневаюсь, что это запустится на моём x86 =)

Эээ... Эт че? Книга? Брошюрка какая-то. Ну посмотрел я её, чувак даже про NUMA не упомянул. Доколе!? Граждане, я вас спрашиваю! В наших рядах будут появляться старые пердуны-проффесора, которые собрали воедино всю шнягу, которую они только нарыли в Гугле за пять минут. Доколе, честной люд, они будут осмеливаться нам же эту каку рукоблудную и впаривать. :x Я взбешён, нах..

> Их _может_ может занимать один и тот же человек но это не является

> правилом.

Я не говорил, что это правило. Я сказал, что в RedHat EL и Fedora ядра собираются теми людьми, которые написали бОльшую часть всего ядра linux. Это есть факт, я привел доказательство. И верх идиотизма считать, что маразматики с ЛОР могут собрать ядро лучше, чем это делают программисты RedHat, которые, повторюсь, бОльшую часть всего ядра и написали.

Ну тогда может быть
"-O3 -march=athlon-xp -m3dnow -mfpmath=sse -pipe -s"

> Как я понял - выравнивание включается при O>=2 c параметрами для заданной архитектуры и которые можно явно задать через -falign-*, так?

Выравнивание данных включается всегда. Даже при -О0 и -g. Выравнивание кода - при -O2. Но на платформе PC оно не даёт _ничего_.

Да прибудет с тобой Дух Патрика, сестра!

Половина ответа есть в твоем вопросе...

Не учите людей плохому! ... или сразу расскажите про возможные проблемы сборки с -j2. Сколько раз было(не с ядром конечно) что сборка обламывалась из-за того, что линковка началась до того как все необходимые объектники были скомпилированы.

>Эээ... Эт че? Книга? Брошюрка какая-то. Ну посмотрел я её, чувак даже про NUMA не упомянул. Доколе!? Граждане, я вас спрашиваю! В наших рядах будут появляться старые пердуны-проффесора, которые собрали воедино всю шнягу, которую они только нарыли в Гугле за пять минут. Доколе, честной люд, они будут осмеливаться нам же эту каку рукоблудную и впаривать. :x Я взбешён, нах..

Доколе?! Доколе анонизмусы будут пускать газы вместо того, чтобы писать программы, патчи, багрепорты, статьи и книги?! Доколе они будут обсирать других людей, которые не только едят, спят, выгуливают своих детей(если есть) и живность, ходят на работу, читают книжки, но и пишут для них(анонизмусов) программы, патчи, багрепорты, статьи и книги ЗАДАРОМ?!

http://en.wikipedia.org/wiki/Greg_Kroah-Hartman

> .. или сразу расскажите про возможные проблемы сборки с -j2. Сколько раз было(не с ядром конечно) что сборка обламывалась из-за того, что линковка началась до того как все необходимые объектники были скомпилированы.

Это ППЦ. Диспансеризация. Постельный режим. Покой.

>В наших рядах будут появляться старые пердуны-проффесора, которые собрали воедино всю шнягу, которую они только нарыли в Гугле за пять минут.

Ты облажался, пердун анонимус, книгу написал один из разработчиков ядра. Теперь ты в гугле можешь нарыть то, что он напиcал.

>чувак даже про NUMA не упомянул. Доколе!?

у тебя нумы нету, доколе будешь хотеть описание конфигурации того, чего не имеешь и не собираешься иметь ?

>Я не говорил, что это правило. Я сказал, что в RedHat EL и Fedora ядра собираются теми людьми, которые написали бОльшую часть всего ядра linux.

Это Ваше личное заблуждение ;)

Приведённый вами пример это как раз это доказывает ;) Загляните в исходники ядра и посмотрите копирайты ;)

maintainer != developer загляните в словарь ;)

Грубо говоря это разные отделы компании (особенно если компания занимается крупными проектами)

PS: Я как то уже приводил пример скрипта, который ищет в исходниках ядра ссылки на копирайты и подсчитывает сколько раз процитировано redhat.com, suse.com etc. Абсолютные рекордсмены зюзоиды а вовсе не RH/FC ;)

Речь разумеется о ванильном ядре.

Разумеется приятно быть среди http://people.redhat.com/ однако это ни разу не означает что все они являются аффтарами исходного кода тех rpm-ок которые там лежат ;)

>GPL это такая лицензия, которая гарантирует, что когда Mysql AB сменит лицензию на MySQL, то админам останется не просто хер с маслом, а остенется выбор или самим сопровождать этот код и закрывать дырки, либо покупать платную mysql следующей версии с поддержкой и с не-GPL лицензией(они запросто могут сменить лицензию на следующую версию, тк весь код их собственный). Съел да?

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

Или ты хотел чтобы кто-то обязался тебя нахаляву всю жизнь поддерживать ? Может тебе еще денег дать впридачу анонимус ?

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

>остенется выбор или самим сопровождать этот код и закрывать дырки, либо покупать платную mysql следующей версии

ты упустил выбор покупки поддержки от любых сторонних организаций. Это уже тебе незачет.

Выравнивание данных и структур можно задать в исходниках через #pragma pack(). Зачем вообще включается выравнивание кода (если оно ничего не даёт) - ведь это только ведёт к увеличению его размера и времени загрузки?

> Выравнивание данных и структур можно задать в исходниках через #pragma pack()

Угу. С риском потерять работоспособность программы.

> . Зачем вообще включается выравнивание кода (если оно ничего не даёт) - ведь это только ведёт к увеличению его размера и времени загрузки?

Для архитектур, отличных от современных x86.

при одинаковой производительности:
-O2 -march=i686:             libbz.so.1.0.4 - 66444 байта
-O2 -march=i686 -falign-*=1: libbz.so.1.0.4 - 62348 байт
какой смысл по умолчанию для i686 это (align) включать - мне непонятно :\

Знаешь что любопытно?
Этот странный субъект wa, подписывающийся именем прогера Glukalka'и, не соизволил даже man gcc прочитать...

Тут 2 варианта: либо человек подписывается чужим именем (соответственно, это болезнь...), либо (этой мысли я еще сильнее страшусь) этот господин действительно автор глюкалки.
Смешно. Эмулятор Спектрумов нарисовал, а man gcc прочесть не соизволил...

>Нормальные люди выбирают такие системы как RHEL, SLES

Ню-ню. А кого ты называешь нормальными людьми? Я не использую. Люди анаконду и up2date до у ума не могут довести, чем тут гордиться? Софт древнющий, ядро древнющее, просто супер система. Кстати, скачать DVD нельзя, тока на 5 cd. Очень весело прыгать вокруг сервера, сначала первый диск, потом все остальные, потом снова первый... И не дай бог сервер без иксов поставишь, оракл потом не встанет, ему иксы нужны.

Ничего удобного в RHN не нашел, дурацкая система, еще и глючила.

Кстати, я им писал-писал письма в их маркетинговый отдел, а они молчат. Видимо клиенты их не интересуют.

В топку такое, уж лучше fedora core какое-нить.

????
Я никогда не был поклонником шапки и шапкоподобных дистров. Видимо, вы меня с кем-то перепутали.

>Выравнивание данных и структур можно задать в исходниках через #pragma pack(). Зачем вообще включается выравнивание кода (если оно ничего не даёт) - ведь это только ведёт к увеличению его размера и времени загрузки?

Вот, http://forum.sources.ru/index.php?showtopic=110906, почитайте...

А вообще, гугл - ваш друг, я надеюсь...

И +512М памяти.

>Я никогда не был поклонником шапки и шапкоподобных дистров. Видимо, >вы меня с кем-то перепутали.

Прости, не тебе отвечал :).

Заодно скажу что если rh делает коммиты в ядро и glibc то это не значит что и все остальное оно делает на таком же уровне. Я вижу единственный плюс в них это вменяемый selinux из коробки.

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

К сказанному выше предлагаю следующее:

- надо создать курсы для доярок по обучению их, доярок, починке электродоилок;

- каждая женщина должна досконально знать каждую деталь машины, на которой она ездит;

- вы пользуетесь утюгом, но не знаете как он устроен? вы представляете, какая была бы экономия электроэнергии при замене провода питания на такой же провод, но с изоляцией, имеющий меньший показатель диэлектрической проницаемости? а укоротив его, можно добится еще большего!!! а что уж говорить про совершенствование устройства (сложнейшего) утюга?

- и т.д. (ой, еще бы пива, так бы можно было всю ночь писАть)...

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