LINUX.ORG.RU

Не лагающие рабочие окружение

 


0

1

У меня есть ноутбук Asus x102ba. Характеристики:проц Amd a4-1200 temash 1 гигагерц,RAM 4 GB DDDR3 впаянная в материнку,HDD 320GB TOSHIBA,Экран 10,1 дюйма сенсорный TFT,UEFI.И у меня лагают окружение любое даже openbox.



Последнее исправление: dem_0 (всего исправлений: 2)
Ответ на: комментарий от tempuser003

Я не могу работать без злобы на железке, которая показывает в этом тесте 500 баллов на ядро

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

твердотельный накопитель

eMMC там стоит, 101% измученный подкачкой винды, т.к. планшет б/у, да и сам очень долго там оффтоп использовал.

Да и в целом адекватнее всего zram оказался в плане быстродействия, но может ещё тесты проведу с zswap.

whbex ★★
()
Ответ на: комментарий от dem_0

А тебе - качать и пробовать на старом дебиане. Самый верный способ проверки безнадёжности железа.

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от whbex

Очень странно, ведь атом D525 быстрее или примерно равен пи4 (проверено лично), амд е-350 быстрее любого атома 2 поколения, а амд А4-1200 быстрее Е-350

Кстати даже так, 4гб рамы это всё её 4гб рамы, а цпу будет где то на уровне Пи3. Т.е. предсказуемо медленно, но не настолько чтобы лагал xfce 4.10 или fluxbox/icewm.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от tempuser003

Это Пи5 с разгоном до 2400Мгц. Там какой то маньяк её гнал, причём пределом было 3000Мгц и 800 с чем то баллов.

У меня во первых Пи4, а во вторых не 1500 а только 1200 и соответственно 210/500 баллов. А с тепловым лимитом и без турбины - ещё меньше.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Не знаю о каком разгоне речь.

Вот default в GB6: https://pimylifeup.com/raspberry-pi-5-benchmark/

Результаты GB6/GB5 различаются примерно на 30%.

Т.е. GB5, исходя из этого обзора, будет показывать ~581 балл.

tempuser003
()
Ответ на: комментарий от anonymous

Забавно, но GB5 (не 6й, он какашка [1]) достаточно точно соответствует производительности в море других задач [2].

А вы ваше имхо можете засунуть туда, куда не светит.

В отличие от фанатиков и верующих, я доверяю solid research with reproducible test cases.

References:

[1] https://forums.anandtech.com/threads/geekbench-6-released-and-calibrated-against-core-i7-12700.2610597/

[2] https://medium.com/silicon-reimagined/performance-delivered-a-new-way-part-2-geekbench-versus-spec-4ddac45dcf03

tempuser003
()
Ответ на: комментарий от tempuser003

На тему почему GB6 MT не тест, а дно:

With regards to multi-core, GeekBench have explicitly stated that their design goal was to mimic multi-core scaling in an undisclosed set of client applications and that those apps exhibited limited to negative scaling past 4 cores (GB is a little annoying in that they insist on using the word «core» interchangeably with «thread» much too often). The technical way they in which they achieved this was two-fold:

#1. They switched from «discrete tasks» to «shared tasks». This means all threads now work on the same task until that task is complete before proceeding to the next task. Compared to the previous method, this increases the benefit of caches closer to the core, eliminates most of the downsides to shared caches, and also absolutely trashes high core-count scaling, especially if multiple groups of cores (e.g. AMD’s core complexes) are used. It should be noted that this switch appears to have been done on all subtasks, even those where «real world» would never see a «shared task» approach.

#2. They changed the weights of each subtask to achieve the scaling that was observed in their aforementioned (undisclosed) set of client applications. There are no public weights, since this would imply considering one subtest more important than another, so instead they modified the workload for each test as a proxy. Obviously, this means they cannot have the same workload for the single-core and multi-core version of the same subtest (and indeed they don’t).

As a side note, this is a fairly fragile way of setting up a benchmark if your goal is to have it keep tracking a fixed set of client applications and it, unsurprisingly, promptly broke, forcing them to issue updates.

In any event, if you want to know about the internals of GB6, they have published some details. If you do look at those, it is very easy to criticize the subtests, but since these are all chosen simply as a proxy for an entirely different set of applications, it does not really matter much what the individual subtests actually are.

For those that are more interested in what GB6 actually measures, it is quite easy to take a look in their database and isolate a single line of similar processors and watch how they scale. I have not performed a rigorous analysis of Geekbench 6 and the results in their database are very noisy, so this approach obviously comes with some caveats. It would be relatively easy to perform some consistent tests across a variety of simple platforms, varying as few parameters as possible at a time, but I have not seen such an analysis.

If you looked at AMD’s Dragon Range of mobile processors, you would notice that for the single-core score, the only variable with a significant correlation is boost frequency. Base frequency (range[2.5;4.0 GHz]) and L3 cache (range[32;128]) do not appear to affect the score much at all. For multi-core it is a bit harder to separate the variables, but core count does appear to the biggest factor, along with base frequency - although the latter is likely a proxy for max power. Again, L3 cache does not appear to be a major contributor.

Overall, judging by the actual scores, GB6 seems to care very little for L3 cache. It is somewhat counter-intuitive that a big 3D v-cache has almost no effect on either single-core or multi-core, despite the rather huge effect it has on many workloads (including games). The relatively small effect of L3 cache, but large effect of bandwidth to memory, appears to reflect a mix of fairly small datasets and very large datasets, with very little in between. This limit, particularly when coupled with the «shared task» approach that mitigates downsides to shared caches, really skews the results quite heavily in favor of Apple-style caches, as opposed to AMD’s (or even Intel’s P-cores).

I have not performed a rigorous analysis of Geekbench 6 and the results in their database are very noisy. It would be relatively easy to perform some consistent tests across a variety of simple platforms, varying as few parameters as possible at a time.

Inserting my opinion on this, specifically as it pertains to multi-core performance, I have trouble finding anything in my daily usage that reflects GB6’s vision of what multi-core is. When I have dozens of tabs open all chugging away with their BS javascript and moronic h264 video ads, that type of workload is not reflected by GB6 scores. When I apply a filter to a photo or encode a small video to send to my family, that also is not reflected by GB6 scores. If I played a game (I rarely find time to), or if I analyze a chess position (blitz chess I do have time for), or if I do something that stresses the computer for more than a few seconds (minutes at best), or if I compile something in the background while continuing to actually use my computer, then those things too are not reflected by GB6 scores.

So, yes, the next time I open a single Word document or a single web page in a browser with no other active tabs, then I will be sure to think just how well GB6 reflects Real World multi-core scaling.

Source: https://forums.anandtech.com/threads/zen-5-discussion-epyc-turin-and-strix-point-granite-ridge-ryzen-8000.2607350/post-41124003

tempuser003
()
Ответ на: комментарий от tempuser003

Щас бы доказывать с серьёзным лицом, что Geekbench говно. Достаточно просто сказать: «Geekbench — говно». Любой версии. Не такая шиза, как Userbenchmark, но он кривой как минимум очень давно.

anonymous
()
Ответ на: комментарий от dem_0

в идеале да. можно попробовать собирать кастом под это железо, но даже в этом случае быстро это работать не будет. оно никогда быстро не работало, а мороки много. Я вот тем же самым занимаюсь, но мне повезло несколько больше у меня sandy bridge. И в свое время работало это быстро. Как и с сокет а, на генту. Проблема этих платформ не в низкой производительности а в том что завезли новые технологии на базе которых организовали новые возможности, чего старые платформы не умеют. Все валится в режим совместимости и начинает лагать. Идея состоит в том что бы завести на старых платформах новый необходимый функционал, используя технологии того времени. А у тебя железка именно с низкой производительностью, т.е даже если откатится в 14 год, все равно по тем временам это мало, если откатится еще в 8, то там просто не будет поддержки твоего железа впринципе.

antech
()
Последнее исправление: antech (всего исправлений: 1)
Ответ на: комментарий от dem_0

а современый софт накатывать на такое железо бесмыслено. Его пилят под современые цп, ты их видел? они вполне могут написать какой нибудь жирный навороченый менеджер потоков очередей и выделить ему целое ядро плюс сделают поддержку какого нибудь аппаратного модуля с ИИ для современых 24 поточных профит будет несопостовимо больше чем затраты. А для твоего 2 ядра 2 гига этот шедулер половина всей вычислительной мощности, и эмуляции ии сожрет все что осталось. что бы что? равномерно размазывать нагрузку по одному ядру плодя кучу процессов и выделя под это дополнительные гигобайты озу? опять таки для современых платформ где старт ОТ 8г это вообще не проблема. А для твоего где ДО 8г это сразу в своп. Опять таки для современого pci5 со скоростями как у твоего озу своп вообще не проблема, а вот хдд на твоей платформе от бесконечного свопа просто рассыпется. ну итд в том же духе.

antech
()
Последнее исправление: antech (всего исправлений: 1)
Ответ на: комментарий от MoldAndLimeHoney

У тебя невероятно устаревший компьютер, его надо обновить.

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

hbars ★★★★★
()