Вышел free-classic-ng 0.0.2.

Можно указывать опции [-k|-m|-g|-t] для переключения между единицами.

Маловато опций, добавь все метрические префиксы от «кекто» до «кветта» :)

Рановато ещё. За 20 лет кол-во оперативки в моём системнике увеличилось всего в 128 раз. Такими темпами только через 40 лет до людей начнут доходить петабайты оперативки. Там и можно будет обновить скрипт.

62.7256851196289 GB

Это 64231.10156249999 MB

Это 65772647.99999999 kB

Это 67351191551.99999 B

Это 538809532415.99994 b (или как там биты обозначаются).

Отсюда вопрос: как назвать величину в 0.00006 бита?

Слишком длинное название и перл в зависимостях - не одобряю.

Отсюда вопрос: как назвать величину в 0.00006 бита?

60 микробит же.

только через 40 лет до людей начнут доходить петабайты оперативки

Но ведь уже сейчас, на предложения воспользоваться разными софтовыми улучшалками, типа zram, zswap, uksm и т.д. и т.п., звучат возгласы «просто добавь памяти», как будто у них там гуттаперчевые возможности железа под «петабайты оперативки». )

Здравствуйте, дорогие сторонники того, как free выводил кол-во используемой памяти до того, как в нём это поломали.

Хоть бы рассказал для тёмных, что там поломали.

на Perl 5

Фу! Не Паскаль.

Хоть бы рассказал для тёмных, что там поломали.

В другой теме рассказывал: Про изменение поведения free между procps 3 и procps 4 .

В двух словах:

Классическая арифметика free: used = total - free - cached - buffers.

Теперь free выводит другое ближе к total - free.

Ну а чего не libre-open-free-classic-ng-remaster?

Нет в тебе чувства прекрасного. Ну как может быть одновременно и classic и ng(next generation)? Ну и perl туда же. Нет бы python. А вообще classic версия должна быть на C, а ng на расте

Предлагаю переименовать в free-classic-ng-reborn-rs. Ну и переписать на русте.

Не всем нужен Perl, перепиши на awk

62.7256851196289

Прости, а откуда оно берёт лишние 0.6289 байт?

Рановато ещё. За 20 лет кол-во оперативки в моём системнике увеличилось всего в 128 раз.

Лох! В моём в 1024 (128m -> 128g).

...-game-of-the-year-edition

Погрешность вычислений при работе с числами с плавающей запятой же.

Оттуда же старый мем про

0.1 + 0.2 = 0.30000000000000004

Погрешность вычислений при работе с числами с плавающей запятой же.

Я в курсе. Вопрос в том, нахрена ты считаешь байты в IEEE754? Это ж эталонный говнобыдлокод просто!

Скрипт получает кол-во памяти из /proc/meminfo в килобайтах, а уже это кол-во пересчитывает в нужные юзеру величины (по дефолту - гигабайты) через деление.

а уже это кол-во пересчитывает в нужные юзеру величины (по дефолту - гигабайты) через деление.

Ага, и начинает брешить в процессе из-за ошибок округления. Как я уже писал, это просто эталонный говнобыдлокод. Не делай так, это плохо для кармы! Используй хотя бы целочисленное деление, а лучше fixed point числа.

целочисленное деление, а лучше fixed point числа

С точностью до байта даже ядро не скажет, поэтому погрешности меньше чем 1 никому тут не интересны.

С точностью до байта даже ядро не скажет

Как и с точностью до килобайта. Учёт памяти идёт по страницам.

поэтому погрешности меньше чем 1 никому тут не интересны.

Кто тебе сказал, что у тебя погрешность на уровне байтов, а не куда хуже? Ты проверял?

Но правда, хватит оправдывать свой говнобыдлокод. Просто сделай нормально.

Погрешность при делении float чисел есть, но она настолько незначительна, что все этим пользуются, и это нормально. Всё зависит от задачи. Утилитами типа free люди пользуются для оценки загруженности памяти. Эту оценку можно спокойно проводить и при такой погрешности.

saahriktu, ваши рассказы в разделе «Художественные произведения» на вашем сайте, это просто чума! Находка, надо же такое выдумывать!…

Согласен.

Один мужик шёл по одному городу. Кругом были дома, люди и машины. Дома из песка, а машины из прессованного
пепла. И они ездили по дорогам из стекла. Стёкла трескались, но их регулярно меняли. Потому, что стекло было
очень дешёвым. Из прессованного воздуха.
...

Погрешность при делении float чисел есть, но она настолько незначительна, что все этим пользуются, и это нормально.

Кто все? За счёт денег в IEEE754 бьют по щщам с ноги, например.

А тут не деньги, а RAM, причём не с точностью до байта, которой нет даже у ядра.

Вот взял и сделал версию с целочисленным делением. Теперь объясните мне: чем

Memory Total: 62 GB
Memory Used: 4 GB
Memory Free: 55 GB
Memory Cached: 3 GB
Memory Buffer: 0 GB

Memory Total: 62.7256851196289 GB
Memory Used: 3.40106964111328 GB
Memory Free: 55.8500022888184 GB
Memory Cached: 3.01894760131836 GB
Memory Buffer: 0.455665588378906 GB

На мой взгляд, второй вариант как раз таки точнее и больше подходит для оценки использования памяти.

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

Мне не обязательно. Просто чем точнее - тем лучше. И я как раз спорю с человеком, который как раз это и утверждает. Просто у нас разные представления о точности отображения данных о памяти.

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

Лучше в виде таблицы, например:

 085 $ free --mega
               total        used        free      shared  buff/cache   available
Mem:            8204        1230        5187         171        2272        6974
Swap:           4294           0        4294

 086 $ ./Desktop/free -m

Total   : 7824,016
Free    : 4197,98
Used    : 1414,46875
Cached  : 2013,406
Buffers : 198,1602
Units   : Mb

 087 $ ./Desktop/free -m | ft

  Total    Free    Used  Cached Buffers Units
  -----    ----    ----  ------ ------- -----
7824,02 4190,13 1416,24 2019,48  198,17 Mb

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

Во-во, читать это жутко неудобно, двух знаков после запятой хватит всем! 😄

Просто чем точнее - тем лучше

Исходные данные уже неточные, в целых KB.

А я подхожу с точки зрения математики, т.е. чем больше цифр после запятой точнее - тем лучше.

Объясни мне с точки зрения математики, что такое 0.6289 байта и откуда они взялись, если ты делил количество килобайт (целое число) на степень двойки (тоже целое число).

А все вот эти знаки после запятой нужны?

Просто чем точнее - тем лучше.

В ядерной физике - да, там «десятые знаки» влияют на то, получит ли теория Нобелевку или пойдет в стол. Но нет смысла считать биты, когда ОЗУ измеряется в десятках… или даже тысячах гигабайт.

Объясни мне с точки зрения математики, что такое 0.6289 байта

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

Т.е. спор про 15-ю цифру после запятой относительно точности менее важен чем про ряд цифр после запятой до неё, который эту точность увеличивает.

ряд правильных цифр после запятой увеличивает эту математическую точность

Так а с чего ты взял, что у тебя эти цифры правильные? У тебя, судя по всему, ересь начинается уже с третьего-четвёртого знака.

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

Не путай «верные цифры» и «значащие цифры»: ошибки вычислений ©.

Сделай чтоб изначально размер был в байтах, а при использовании опции -h включались приставки.

Проверил по

Memory Total: 62.7256851196289 GB

Как минимум, 9 цифр после запятой тут нужны, иначе при срезании цифр и переводе в байты (и округлении до целых, разумеется) данные начинают расходиться с «free -b».

Исходные данные уже неточные, в целых KB.

Суть в том, что округление до целых резко увеличивает эту неточность. А float point арифметика хоть и увеличивает погрешность, но не так как при срезании цифр после запятой.

Это как если погрешность от float point арифметики размером с хомячка, а погрешность от целочисленной арифметики размером с Годзиллу.

Это как если погрешность от float point арифметики размером с хомячка, а погрешность от целочисленной арифметики размером с Годзиллу.

38 попугаев: экспериментальная проверка :)

>>> 62.7256851196289 * (1024 ** 3)

67351191551.99999

Что именно ты тут проверил? В байтах получается полная лажа. Если тебе нужно округлять до целого вверх дальше, ты уже точность просрал. Просто считай в fixed point и не пиши быдлокод.

В байтах получается полная лажа.

Как раз таки нет. Результат вычисления должен быть примерно равен 67351191552. Чем он дальше от этого числа - тем больше погрешность.

Теперь начинаем срезать цифры и смотреть что получается:

67351191551
67351191541
67351191530
67351191423
67351186054
67351100155

67350455910
67345087201
67323612364
66571993088

Суть в том, что округление до целых резко увеличивает эту неточность

А точность важна в данном случае? Это же просто по своей сути отчет, а не данные для последующей обработки. Можно вообще в процентах.

PS. Странно, что free берет данные из /proc/meminfo, а не из более низкого уровня системы.

PSS. Так можно на любом скриптовом языке заменить этот самый free Глядя на вас, тоже захотелось

А точность важна в данном случае?

Так весь сыр-бор из-за того, что free теперь в used показывает на ~500-900 Мб больше чем раньше. Прежнее значение я считаю более точным и для увеличения этой точности сделал сабжевый скрипт.

Странно, что free берет данные из /proc/meminfo, а не из более низкого уровня системы.

Это данные от ядра. Точнее ни у кого нет.

Так весь сыр-бор из-за того, что free теперь в used показывает на ~500-900 Мб больше чем раньше.

Вопрос не про это, а про колличество цифр после десятичного разделителя в выводе скрипта.

Меж тем аккурат под католическое рождество вышел libre-classic-ng 0.0.1, форк полулярного free-classic-ng, в котором были решены две главные проблемы оригиналы:

• Нот инвентед хере (да её и на перле!)
• Ужасные ошибки округления

Собственно, сама программа:

#!/usr/bin/guile \
-e main -s
!#

(use-modules (ice-9 rdelim))
(use-modules (ice-9 format))

(define db "/proc/meminfo")
(define factors '((kb . 0)
                  (Mb . 10)
                  (Gb . 20)
                  (Tb . 30)))

(define (parse-meminfo line)
  (filter
   (lambda (s)
     (not (string-null? s)))
   (string-split line #\Space)))

(define (add-line new-line acc)
  (let* ((key-value (parse-meminfo new-line))
         (key (car key-value))
         (value-in-kb (string->number (cadr key-value))))
    (acons key value-in-kb acc)))

(define (file->mem-info . arg)
  (let ((acc (if (eq? '() arg) arg (car arg)))
        (new-line (read-line)))
    (if (eof-object? new-line) acc
        (file->mem-info (add-line new-line acc)))))

(define (read-mem-info db)
  (with-input-from-file db
    file->mem-info))

(define (get mem-info  key factor)
  (/ (assoc-ref mem-info key)
     (expt 2 (assq-ref factors factor))))

(define (print-statistics mem-info factor)
  (let* ((total (get mem-info "MemTotal:" factor))
         (free (get mem-info "MemFree:" factor))
         (cached (get mem-info "Cached:" factor))
         (buffers (get mem-info "Buffers:" factor))
         (used (- total free cached buffers)))
    (format #t "Memory Total ~s ~s~%" total factor )
    (format #t "Memory Used: ~s ~s~%" used factor)
    (format #t "Memory Free: ~s ~s~%" free factor)
    (format #t "Memory Cached: ~s ~s~%" cached factor)
    (format #t "Memory Buffer: ~s ~s~%" buffers factor)))

(define (pick-factor-from . args)
  (cond
   ((= 1 (length args)) 'Gb)
   ((string= arg "-k") 'kb)
   ((string= arg "-m") 'Mb)
   ((string= arg "-t") 'Tb)
   (else 'Gb)))


(define (main args)
  (let ((factor (pick-factor-from args))
        (mem-info (read-mem-info db)))
    (print-statistics mem-info factor)))

Пример использования:

./libre.scm -g                                                                                                                                                                                             
Memory Total 3061475/65536 Gb
Memory Used: 7467491/262144 Gb
Memory Free: 142543/131072 Gb
Memory Cached: 1895025/131072 Gb
Memory Buffer: 703273/262144 Gb

Как видите, показатели памяти выражены приятными глазу рациональными числами и при этом они абсолютно точны. Можно начинать радоваться. Много не пейте!

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

Это всё равно, что вас когда вас спросят: сколько до вашей дачи ехать, правильный ответ — полтора часа. А не один час, 32 минуты, 16 секунд, 200 микросекунд и 15 наносекунд. Хотя второй формально точнее.

можно запускать а отдельном окне и созерцать

$ watch ./free-classic-ng.pl -m