• Utilize Multicore CPU


    Running antergos on 6-core CPU. I found that CPU-heavy tasks (such as audio conversion) take a very similar time to complete like on my old 2-core CPU (which was running Windows). So I started looking for a cause…

    If I start KSysGuard and look at System Load during conversion, I see that only 1 core is used (100% load), and 5 remaining cores are not used (0% load). Is it program’s fault or do I need to adjust some settings in OS?

    I’m asking because I thought Arch/antergos utilizes all the cores by default, but it looks I was wrong. For example, if user wants to make packages faster, he needs to manually enable extra cores - https://wiki.archlinux.org/index.php/Makepkg#Utilizing_multiple_cores_on_compression

    So maybe it’s the same for other tasks too, and user needs to manually enable extra cores for individual tasks? The program I use now is http://soundconverter.org/ and it claims - Thanks to its multithreaded design, it will use as many cores as possible to speed up the conversion.

    Sure, such a claim might be a lie, so I downloaded more converters that claim supporting multiple cores, and result was the same - only one core is used. Strange enough, all converters use core #2, which makes me think it’s related to OS somehow. Because I don’t think all converters are somehow programmed to select #2 core if there are multiples cores available.

  • i do not see this here, soundconverter is using all cores at my Antergos install.
    But if you are using KDE why not taking soundKonverter ?
    https://github.com/dfaust/soundkonverter/wiki

  • @toxpal Entirely depends if the software in question is multi-threaded and / or has been compiled with multi-thread support.

    Which program did use for your “audio conversion”? You didn’t drop a name.

    As an example:

    7-zip (create/extract) uses all cores
    rar (I’m using the RarLabs version) also uses all cores (although not to 100%)

    lame (wav --> mp3) only runs on one core
    flac (wav --> flac) only runs on one core

    So… yea… there are programs which run on only one core because they are either not multi-threaded or have not been compiled to support multi-thread.

    That being said, stuff like ffmpeg or handbrake (video encode/transcode) do make use of multiple cores.

    Though, it remains a matter of question if you would actually see any performance gain … “lame” takes 12 seconds to encode a 6:48 long track (Chris Rea - Road To Hell [Long Version]), and “flac” is even faster though it also runs on just one core.

  • @toxpal said in Utilize Multicore CPU:

    http://soundconverter.org/ and it claims - Thanks to its multithreaded design, it will use as many cores as possible to speed up the conversion.

  • @phunk-n-further, I tried SoundConverter, fre:ac and some other (can’t remember the name).

    I usually convert only one file at a time, but I believe multiple cores should be used for any number of files?

  • @joekamprad I tried SoundKonverter too, but didn’t like it. If I remember correctly, it asks to select conversion settings (like bitrate, etc) every time I start converting. While other tools allow to set default profile and automatically use it every time.

  • As it do use all fired on my system, issue is may related to your CPU and current Kernel.
    Do you try to boot on LTS kernel?

  • @toxpal said in Utilize Multicore CPU:

    @phunk-n-further, I tried SoundConverter, fre:ac and some other (can’t remember the name).

    I usually convert only one file at a time, but I believe multiple cores should be used for any number of files?

    Well, if the GUIs you tested so far are just graphical front-ends to things like “lame” (MP3 encoder) or “flac” (FLAC de-/encoder) then all I can tell you is that you won’t see multi-threading going on simply because the very command-line utility the GUI is relying upon is single-threaded - and I’m referring to the versions out of Antergos’ repository.

    If you know that, for example, lame should be able to run multi-threaded given it got compiled that way … well … the only option would be to resort to the Arch Wiki and compile the package(s) in question to include support for multi-threading.

    Another way would be to cobble up a bash script and run several encoder instances in parallel, each encoding a file (by launching it, for example, via “parallel” - a very nifty command-line tool). They should actually spawn across cores and not get pinned to the very same core. This is what I’ve done (bash script) as I’m currently re-encoding all my audio CDs into FLAC.

    As for your question about “multiple cores should be used for any number of files” … well … it depends on the type of workload on how you best approach multi-threading.

    Doing stuff like encoding video, applying a filter to a image (GIMP), ray-tracing a scene (Blender) can only be chopped up into chunks… all of the cores are working on just a segment - making them work on several different files wouldn’t make sense.

    As for encoding audio … multi-threading the encode may make sense, and net some performance gain, on very large pieces of audio (i.e. a podcast audio that is several hours long). For short pieces I think the performance is good enough … I mean, a twelve second encode time for a WAV that is almost seven minutes long isn’t that shabby. This was “lame” encoding the ripped WAV into a 320Kbps CBR MP3, it takes 8 seconds to turn it into a FLAC (on Threadripper 1950X). In short, I’m not sure if you would see any noticeable performance gains in this particular scenario (a rather short file).

    However… try and give “ffmpeg” a try. It can not only encode/transcode video, it also supports audio. Since ffmpeg is multi-threaded it should actually spread the task across all available cores.

    As for the “always pins to the same core” … see joekamprad’s advice above. There’s something not entirely right when you see an odd behavior like this we can’t reproduce.

  • @joekamprad said in Utilize Multicore CPU:

    As it do use all fired on my system, issue is may related to your CPU and current Kernel.
    Do you try to boot on LTS kernel?

    Just tested on LTS kernel. This time, it utilized all cores, but only one at a time. What I mean, that on LTS converters use core #1 for several seconds (other 5 cores are not used), then use core #2 (once again, remaining 5 cores are not used) and so on. At the end, conversion speed is identical.

    Maybe my CPU isn’t properly supported yet because it was launched at the end of 2017? https://ark.intel.com/products/126687/Intel-Core-i5-8400-Processor-9M-Cache-up-to-4_00-GHz

  • @toxpal The Intel Core i5 8400 is fully supported since Linux Kernel 4.15

    I don’t know if the LTS kernel (4.14.56-1 at the time of writing) contains the necessary backports to properly support processors which haven’t been around as the 4.14 series came out … it being a LTS kernel one would actually assume that the “hardware enablement” would be backported.

    If you’re on the rolling kernel (4.17 series) you should certainly be good.

cpu22 utilize1 multicore1 Posts 10Views 524
Log in to reply
Bloom Email Optin Plugin

Looks like your connection to Antergos Community Forum was lost, please wait while we try to reconnect.