Что быстрее отнять и поделить или сразу поделить?
ИМХО, если размер чисел фиксирован, то вычитание не даст преимущества в скорости. Если нет - то зависит от ситуации.
если процессор за один такт выполняет нахождение остатков для лонгов, то второе будет быстрееверное предположение.
алгоритмически понятно что первое быстрее, там же меньше итераций в алгоритме евклида будетПроведи эксперимент. А вообще, учитывая как устроены современные процессоры и что какой там алгоритм деления ты не знаешь, твой вопрос бессмысленен. Бесмысленен он еще и по той причине, что подобные ухищрения нах не нужны.
но если процессор за один такт выполняет нахождение остатков для лонгов, то второе будет быстрее
верное предположение.С каких это пор? (простите, не мог пройти мимо)
Тем не менее, вариант без вычитания не будет медленнее. Алгоритм Евклида в процессорах не применяется, и без учёта вычитания, команд(а,ы) будут выполняться одинаково.
алгоритмически понятно что первое быстрее, там же меньше итераций в алгоритме евклида будеткакой нафиг евклид, если % делается как a - (a/b)*b
соответственно, второе будет быстрее, чем первое - так как операций на одну меньше
если % делается как a - (a/b)*bВ некоторых популярных архитектурах для % даже инструкция специальная есть
В некоторых популярных архитектурах для % даже инструкция специальная естьэто ты намекаешь, что я об этом не знаю?
в проце команда % все равно делается через деление, а не через евклида, и соответственно от размера операндов сложность не меняется
какой нафиг евклид, если % делается как a - (a/b)*bмдя
чото у меня совсем мозги набекрень...
понедельник день тяжелый
еще вот вопрос возник
как обнулить массив
не нашел в Java memset
memcpy есть через нативный System.arraycopy а вот Arrays.fill нифига ненативный
я всегда думал что memset это очень быстро, может я ошибался? если нет, то почему Sun на это двинуло?
в результе решил пользовать копированием заранее созданного массива с нуля
public class IntArrayZeroFiller {
private static int[] internal = new int[1];
public static void init(int length) {
if (internal.length < length) {
internal = new int[length];
}
}
public static void fill(int[] array, int offset, int length) {
System.arraycopy(internal, 0, array, offset, length);
}
}
как обнулить массивсоздать новый без всяких копирований, будет даже быстрее чем memset (при правильном framework-е)
Мля, чувак, если программируешь на джаве, забудь подобные вопросы в принципе.
создать новый без всяких копирований, будет даже быстрее чем memset (при правильном framework-е)да лан
один гарбадж коллектор чего стоит
Мля, чувак, если программируешь на джаве, забудь подобные вопросы в принципе.не нада ляля
А что, написать и проверить - руки отвалятся?
Тут не телепаты, никто не знает, какие у тебя язык/компилятор/целевая платформа.
Тут не телепаты, никто не знает, какие у тебя язык/компилятор/целевая платформа.
один гарбадж коллектор чего стоитgarbage collector будет потом, а чистая память выделится сейчас и быстро
за один такт
Да?
чистая память выделится сейчас и быстротолько если её кто-то очистил предварительно
только если её кто-то очистил предварительнотак именно этим, как минимум, занимается, и ОС, и framework
так именно этим, как минимум, занимается, и ОС, и frameworkобычно я так и делаю
но тут таких массивов 1000 штук
примерно каждую миллисекунду идет несоклько записей в енти массивы
и обнулять их надо раз в секунду
первая реализация была со списком а не массивом
она в кору очень быстро валилась изза нехватки памяти
щас вот на массивах получше стало
напрягать гц надо как можно меньше, т.к. когда он начинает работать, всё остальное отдыхает
задержки в секунду бывают - а это пипец как много
римерно каждую миллисекунду идет несоклько записей в енти массивыА java.util.Arrays.fill работает медленее, чем копирование?
и обнулять их надо раз в секунду
EDIT: имел ввиду намного медленнее?
только это не быстрее memset'а (на больших массивах)
потому как это он по сути и есть
потому как это он по сути и есть
Видел реализацию заполнения массива, когда сначала в цикле заполняются первые 16 элементов, а потом с помощью System.arraycopy количество заполненных элементов удваивается. Ну то есть первые 16 элементов копируются во вторые 16 элементов. Потом первые 32 во вторые 32 и т.д. Не знаю, насколько это эффективнее простого цикла.
какой нафиг евклид, если % делается как a - (a/b)*b% делается через деление столбиком (если операционная система 32-битная). Второе будет быстрее, но не при всех значениях операндов. Если порядок числа падает сильно, то будет быстрее первое. Но лично я бы на это не надеялся.
соответственно, второе будет быстрее, чем первое - так как операций на одну меньше
PS На ассемблере (x86) второе будет всегда быстрее, поскольку в нем есть деление long на int. А вообще топикстартеру возможно стоит использовать JNI (Java Native Interface если ему так сильно нужно выжать последний десяток процентов скорости...
% делается через деление столбиком (если операционная система 32-битная). Второе будет быстрее, но не при всех значениях операндов. Если порядок числа падает сильно, то будет быстрее первое.на целочисленное деление - сейчас сколько тактов процы тратят?
Int на int порядка одного. Но у автора деление long на long (который на самом деле int).
Но у автора деление long на long (который на самом деле int).на 64 битном - int64 на int64 тоже будет порядка одного такта?
Есть инструкция div r/m64, соответственно в 64битном режиме — да.
Оставить комментарий
pitrik2
или
все типы long
something - довольно маленькое
bigLongStartValue делится нацело на something
алгоритмически понятно что первое быстрее, там же меньше итераций в алгоритме евклида будет
но если процессор за один такт выполняет нахождение остатков для лонгов, то второе будет быстрее