The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Началось формирование 32-разрядных Linux-сборок браузера Vivaldi

17.02.2015 18:58

Представленный в прошлом месяце web-браузер Vivaldi, созданный под руководством бывшего руководителя Opera Software, теперь доступен и в 32-разрядных сборках для Linux. Изначально для Linux поставлялись только 64-разрядные сборки, но после многочисленных пожеланий разработчики приступили к формированию 32-разрядных пакетов DEB и RPM. Браузер построен с использованием web-движка Chromium и продолжает развитие идей классического браузера Opera, предоставляя широкий спектр возможностей и настроек.

  1. Главная ссылка к новости (http://www.webupd8.org/2015/02...)
  2. OpenNews: Основатель Opera Software представил новый web-браузер Vivaldi
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/41681-vivaldi
Ключевые слова: vivaldi, opera
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 19:30, 17/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Уже хорошо. Но проприетарщина все равно не нужна.
     
     
  • 2.2, th3m3 (ok), 19:35, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Кстати, да. Причём тут Опеннет и эта новость - непонятно.
     
     
  • 3.3, Аноним (-), 20:13, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Половина (если не больше) браузера открыта, модифицируй сколько хочется.
     
     
  • 4.20, Аноним (-), 00:26, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Нельзя быть слегка беременной, такие дела :)
     
  • 4.21, Tav (ok), 00:26, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Движок и без них был открытым, а вот вся остальная проприетарная надстройка (и следовательно вся программа в целом) доверия совершенно не заслуживает и противоречит этике и открытого, и свободного ПО.
     
  • 3.5, Абвгдеёж (?), 20:21, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы помнили.
     
  • 3.48, Аноним (-), 12:16, 22/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, как-то новости про обычный хром вместо изначального хромиума постят и ничё.
     

  • 1.4, soarin (?), 20:19, 17/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Пока этот браузер доведут до stable, из двух пользователей кому это надо было б, останется один, а второй уже перейдёт на 64 битную ОС.
     
     
  • 2.32, Анононо (?), 10:29, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я буду ждать, так что всё-таки два, а не один
     
     
  • 3.46, Аноним (-), 23:44, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А я не буду. Так что все-таки один.
     

  • 1.6, Аноним (-), 20:33, 17/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    32 бита в 2015 году. Но зачем?
     
     
  • 2.7, Омоним (?), 20:45, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Чтоб не тратить на указателях в два раза больше ОЗУ.
    Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.
     
     
  • 3.8, vlikhachev (ok), 21:09, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Чтоб не тратить на указателях в два раза больше ОЗУ.
    > Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.

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

     
  • 3.9, Аноним (-), 21:26, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего, что в 32-х битной версии теряем на отсутствии операций над "широкими" регистрами? А также теряем целую кучу новых инструкций, дающих процентов 15 производительности просто на пустом месте?
     
     
  • 4.11, Mihail Zenkov (ok), 22:05, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На аудио/видео кодеках и то если повезет.

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

    Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг ...

     
     
  • 5.13, да я же (?), 23:29, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Несколько спасает ситуацию большие количество регистров

    Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее количество регистров???

    Современный код это по большей части лазанья-код, где "everything happens somewhere else", а значительное количество функций состоит просто из вызовов других функций и минимальной логики. БОльшее количество регистров всё равно придётся сохранять в стеке а потом восстанавливать, как и в случае с небольшим числом регистров.

    Где я неправ?

     
     
  • 6.15, Mihail Zenkov (ok), 23:43, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее
    > количество регистров???

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

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

    Если функции действительно простые, то компилятор будет пытаться делать из них более сложные (inline) дабы экономить на переходах.

     
     
  • 7.18, да я же (?), 00:10, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Грубо говоря, каждой переменной в функции можно выделить свой регистр

    Это я понимаю.

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

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

     
     
  • 8.22, Mihail Zenkov (ok), 00:36, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Не совсем так - если рассматривать самый простой случай один поток, без прерыва... текст свёрнут, показать
     
     
  • 9.24, да я же (?), 01:25, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Возможно, вы меня не так поняли или я вас Я говорю не о передаче через регист... большой текст свёрнут, показать
     
     
  • 10.25, Mihail Zenkov (ok), 01:59, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ИМХО компилятор постарается хранить все переменные в разных регистрах - соответс... текст свёрнут, показать
     
     
  • 11.33, да я же (?), 10:30, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так в общем случае при компиляции g компилятор не может знать, какие регистры бу... текст свёрнут, показать
     
     
  • 12.43, Аноним (-), 16:52, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    поэтому использует имена абстрактных регистров, а когда ведет генерацию кода - п... текст свёрнут, показать
     
  • 5.28, tensor (?), 04:45, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг...

    Немного оффтоп, но не мог не ответить. Если разница в потреблении и достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут на десктопе? С одной стороны, если у вас забита память под завязку, а swappiness=0, то вам остаётся только лезть в tty и срочно дропать кэши/прибивать процессы - но зачем до такого доводить? С другой, лаги в 64-битной системе со свопом 3-5% от памяти вы, скорее всего, и не заметите.

    А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер), чем возвращаться к 32 битам и экономить на спичках.

     
     
  • 6.39, Аноним (-), 13:33, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А вообще, проще сменить ПО на более легковесное ( ... браузер ... )

    Браузер? Угу, удачи. Оксюморон

     
  • 6.40, Mihail Zenkov (ok), 13:48, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг...
    > Немного оффтоп, но не мог не ответить. Если разница в потреблении и
    > достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут
    > на десктопе?

    Не такие там и копейки - ссылка ниже.

    > А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер),

    Это верно - почти всегда его использовал.

    > чем возвращаться к 32 битам и экономить на спичках.

    Мне не нужно возвращаться, я их до сих пор использую. На машине 4GB, без свопа. Пока для всех моих задач более чем достаточно. Сейчас запущен FF (облегченный), более 50 вкладок, реально использовал за этот сеанс 10 из них - памяти занято 346 MB (вся система + FF).

    Будет нужно памяти 8GB или больше, тогда и перейду на 64 бита.

     
     
  • 7.49, count0krsk (ok), 17:24, 22/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вот-вот. Аналогично.
    Сейчас имею 6 Гб, и 32 бит хватает. С учетом того, что скоро и firefox/icecat будет многопроцессным, хватит ещё долго ))
    А любители модных молодёжных 64бит пусть и дальше плачут над багами дров.
     
  • 4.27, Прохожий (??), 04:02, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не совсем так. Так или иначе все упирается не в регистровую память, а различные вычислительные блоки CPU. Кеш:L1, L2, L3... Размеры огромны, а скорость впечатляет. Большинство кода умещается именно там и ограничивается вычислительными возможностями CPU. Большее их количество и разрядность не делает операции с ними в два раза быстрее. Большинство программ просто не получат никакого преемущества от этого, за исключением узкого круга специализированного софта.
     
  • 3.10, BratSinot (ok), 22:02, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя, как вы думаете, большая разница в потреблении памяти будет?

    Только вот в amd64 ABI в качестве FPU юзают SSE, а он, мягко говоря, быстрее работает, упоротого x87, плюс в два раза больше регистров общего назначения и XMM.
    Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать под i386 непонятно нафига.

     
     
  • 4.12, Mihail Zenkov (ok), 22:13, 17/02/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя,
    > как вы думаете, большая разница в потреблении памяти будет?

    Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.

    > Только вот в amd64 ABI в качестве FPU юзают SSE, а он,
    > мягко говоря, быстрее работает, упоротого x87,

    -mfpmath=sse

    > плюс в два раза больше
    > регистров общего назначения и XMM.

    Это да, существенный плюс.

    > Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать
    > под i386 непонятно нафига.

    Это только говорит об неадекватности собиравшнго. Или avx и прочие новинки будем использовать только после перехода на 128 бит?

     
     
  • 5.35, asdasd (?), 11:17, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.

    УМВРНЧЯДНТ?

    > -mfpmath=sse

    Не прокатит с системными либами.

     
     
  • 6.37, asdasd (?), 11:24, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не прокатит с системными либами.

    Забыл добавить, что возвращаемые значения все равно будут через x87.

     
  • 6.38, Mihail Zenkov (ok), 13:31, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.
    > УМВРНЧЯДНТ?

    http://askubuntu.com/questions/7034/what-are-the-differences-between-32-bit-a

    >> -mfpmath=sse
    > Не прокатит с системными либами.

    Это что за библиотеки такие? У меня так вся система (lfs) собрана.

     
  • 4.16, Прохожий (??), 00:01, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Зачем спорить. На хабре была статья на примере php в Ubuntu i386\x86_64. В i386 потребляет почти в 2 раза меньше памяти. Можешь там попробовать втирать свой дзен.
     
     
  • 5.36, asdasd (?), 11:20, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Во первых, ссылку пожалуйста, беглый поиск ничего не выдал.

    Во вторых, сравнивать сервер и десктоп глупо.

    На моей домашней машине любой дистрибутив не потребляет в два раза больше, пробовал Ubuntu, а пользуюсь Slackware. Собственно тот-же FireFox в i386 и amd64 редакции жрут одинакового дофига.

     
     
  • 6.47, Аноним (-), 01:16, 19/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Наверно, речь об этом: http://habrahabr.ru/post/161629/
    Gentoo forever! :D
     

  • 1.17, Прохожий (??), 00:04, 18/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Для 4GB и меньше - только i386. Сборка актуальна.
     
     
  • 2.31, нано анон (?), 06:14, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А если РАЕ?
     
     
  • 3.50, count0krsk (ok), 18:22, 22/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А если РАЕ?

    Вроде до 32 Гб можно не заморачиваться, или 64. В-общем лет на 10 хватит, а там уже дистры перестанут собирать под i686.

     

  • 1.19, Аноним (-), 00:22, 18/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Оно же не умеет fit-to-width?
     
  • 1.23, Аноним (-), 00:36, 18/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эм.. Оно только у меня в openSUSE хочет Qt3 или нет?
     
     
  • 2.26, milinsky (ok), 03:19, 18/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Наверное только у тебя. У меня поставилось без зависимостей.
     

  • 1.42, Typhoon (ok), 16:35, 18/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    "Подогнать по ширине" появилась?
     
  • 1.44, ANONYM (?), 22:00, 18/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они даже под винду делать не научились. Их устанощик последний раз работал только от администратора и ставился только в пользовательскую папку администратора и работал только от администратора. Такое ощущение что там и в линуксе все под рутом сидят.
     
  • 1.45, ANONYM (?), 22:16, 18/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Авторы такие наивные. Они всерьёз думают, что разрабы хромого будут тащить их код?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру