26 Dec
2017
26 Dec
'17
9:34 p.m.
It seems everyone is dropping support for 32 bit machines these days - including
a number of Linux distros.
It makes me wonder how long it will be before single core machines go the same
way. Has anyone seen any hint of that yet?
I think it was LAC 2008 where I first heard discussion on how to plan for
multi-core kit - not that I was touching any code back then :)
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
26 Dec
26 Dec
10:59 p.m.
On Tue, December 26, 2017 2:34 pm, Will Godfrey wrote:
It seems everyone is dropping support for 32 bit
machines these days -
64 bit x86 based processors were first released over 12 years ago. I
don't think you have been able to buy a 32 bit only x86 processor for over
5 years now, so the numbers of 32 bit only machines is dwindling.
It makes me wonder how long it will be before single
core machines go the
same way.
That depends on what you mean. You have not been able to purchase a new
single core processor in quite a few years. As far as I am aware there
are no distributions which build without SMP support, but an SMP capable
kernel can run on a single core, so the situation with core count is not
quite the same as the difference between 32 bit and 64 bit builds.
--
Chris Caudle
27 Dec
27 Dec
1:04 a.m.
On Tue, 26 Dec 2017 15:59:42 -0600
"Chris Caudle" <chris(a)chriscaudle.org> wrote:
On Tue, December 26, 2017 2:34 pm, Will Godfrey wrote:
OK, I wasn't thinking things through clearly.
Presumably if a program did want to spread itself between cores it would have
to first ask how many there were, and if it was 1, then that settled it!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
It seems everyone is dropping support for 32 bit
machines these days -
64 bit x86 based processors were first released over 12 years ago. I
don't think you have been able to buy a 32 bit only x86 processor for over
5 years now, so the numbers of 32 bit only machines is dwindling.
It makes me wonder how long it will be before
single core machines go the
same way.
That depends on what you mean. You have not been able to purchase a new
single core processor in quite a few years. As far as I am aware there
are no distributions which build without SMP support, but an SMP capable
kernel can run on a single core, so the situation with core count is not
quite the same as the difference between 32 bit and 64 bit builds.
26 Dec
26 Dec
11:02 p.m.
On Tue, 26 Dec 2017, Will Godfrey wrote:
It seems everyone is dropping support for 32 bit
machines these days - including
a number of Linux distros.
Which is a bummer... but it looks like Ubuntu lts (18.04) will have a 32
bit option which will stay around as long as the lts. (but don't quote me
on that) I have 3 (or 4) 32 bit machines here and the thing is they seem
to be from a time when things were made to last a bit longer. (I have over
10year old PATA drives in them) Actually I have a 1998 NEC that still runs
around here too, but it is pretty slow.
It makes me wonder how long it will be before single
core machines go the same
way. Has anyone seen any hint of that yet?
The only single core machines I have are 32 bit, but I don't see single vs
multicore being the same problem. For a distro 64 vs 32 bit means two
kernels and two complete software sets. I don't know of any sw that
requires multicore, and there is no second set of sw required for it
either. so there is no real push to switch people over to multicore.
In other words the 32 bit thing is to gain more room without adding more
drives. I am sure people have been looking at how many people download
32bit images and feel it is not worth the upkeep. Lubuntu will continue to
support 32bit machines, but I expect that they will not be able to keep
the whole 32bit eco system up to date... so audio software and other
specialized software will likely vanish in the 32 bit form. 32bit single
core machines seem to do audio very well and so that will leave a hole for
sure. I think some people are running FW interfaces in this way too.
However, if they keep the kernel going and most basic libs, one can always
build anything else.
--
Len Ovens
www.ovenwerks.net
11:26 p.m.
On Tue, 26 Dec 2017, jonetsu wrote:
On Tue, 26 Dec 2017 14:02:49 -0800 (PST)
Len Ovens <len(a)ovenwerks.net> wrote:
Assuming it is a multicore option as in on or off, then it has to work
with whatever number of cores the cpu has. So even if the option was
locked hard on, it would still work with one core. So even though it can
use multicore, it does not require it.
--
Len Ovens
www.ovenwerks.net
I don't know of any sw that requires
multicore, ...
Some u-he synths have a multicore option. 
11:52 p.m.
On Tue, 26 Dec 2017 14:26:11 -0800 (PST)
Len Ovens <len(a)ovenwerks.net> wrote:
On Tue, 26 Dec 2017, jonetsu wrote:
Hence it's an option. Typically activated before doing an export.
Although with some complex sounds on Bazille or Diva, switching it on
while creating can provide a smoother sound.
On Tue, 26 Dec 2017 14:02:49 -0800 (PST)
Len Ovens <len(a)ovenwerks.net> wrote:
Assuming it is a multicore option as in on or off, then it has to
work with whatever number of cores the cpu has. So even if the option
was locked hard on, it would still work with one core. So even though
it can use multicore, it does not require it. I don't know of any sw that requires
multicore, ...
Some u-he synths have a multicore option. 
27 Dec
27 Dec
1:51 a.m.
jonetsu wrote:
Len Ovens <len(a)ovenwerks.net> wrote:
Yes, but I am not clear what that means. It could mean "If you want I
can split the work into concurrent processes/threads in the hope that
you have enough cores to benefit from this.". Or it could mean "I
*will* pin different processes to different cores, and I will fail if
those cores aren't there.".
I Googled around but couldn't find anything that really clears this
up. Mentions of multicore support on multimedia sites generally
amount to little more than "Multicore support in the latest release.
Yay!". Gamers often go into more detail, reporting how many cores
their games are using, how it affects the FPS etc., but nothing I can
find describes exactly how the games are deciding how many cores to
use.
(I also found some reports on Ableton sites where people fixed crackly
audio by disabling multicore support.)
Regards,
Jeremy Henty
I don't know of any sw that requires
multicore, ...
Some u-he synths have a multicore option.
3:17 a.m.
On Wed, 27 Dec 2017, Jeremy Henty wrote:
Yes, but I am not clear what that means. It could
mean "If you want I
can split the work into concurrent processes/threads in the hope that
you have enough cores to benefit from this.". Or it could mean "I
*will* pin different processes to different cores, and I will fail if
those cores aren't there.".
As a developer, I would not want my sw to fail because some *** user told
me to spread out my workload over 12 cores when there are only 4. I would
want my sw to run and never crash. With audio sw, there is already going
to be at least two threads for GUI and rt audio. If there are more
separate audio pathes (like mixer channels) each of those can be a thread
too. Those threads will be spread around the available cores... so if
thread one is on core one and thread two is on core two... if there are
two cores thread three is back on core one... if there is only one core,
all threads are run on that core. Though a lot of single core cpus show up
as two if hyperthreading is enabled. Note, the above description is
greatly simplified, both for easier understanding and because my
programing art is at a beginner level. I do run ring buffers to pass info
from realtime to GUI and back, but that is about as far as I have gotten
:)
--
Len Ovens
www.ovenwerks.net
12:30 p.m.
Len Ovens wrote:
On Wed, 27 Dec 2017, Jeremy Henty wrote:
I guess my use of the word "fail" was too vague. Obviously the
software should not crash. But if the user specifies an impossible
combination of options then the software should say "I'm sorry Dave,
I'm afraid I can't do that" rather than silently do something other
than what the user wanted.
My impression is that at the moment most users only get the option of
telling the software "use as many cores as you like" and the software
does the rest for itself, so the issue of the user making impossible
demands does not arise. It would be nice to know for sure what is
going on, but since I am neither a gamer or an audiophile I don't have
the hardware or the incentive to do the research myself.
Regards,
Jeremy Henty
Yes, but I am not clear what that means. It
could mean "If you
want I can split the work into concurrent processes/threads in the
hope that you have enough cores to benefit from this.". Or it
could mean "I *will* pin different processes to different cores,
and I will fail if those cores aren't there.".
As a developer, I would not want my sw to fail because some *** user
told me to spread out my workload over 12 cores when there are only
4. I would want my sw to run and never crash. 
3:23 p.m.
On 27/12/17 11:29, Jeremy Henty wrote:
Len Ovens wrote:
My understanding, for what it's worth (2p?) is that programs
don't tell
the system how many cores to use, though they can impose an upper limit.
To use multiple cores, your create multiple threads, and the system, being
all-knowing, distributes them as it sees fit, possibly taking into account
any requests to limit the number of cores used. So a program that generates
1,000 threads will be able to take advantage of the new 1K-core processors,
but can still run on an old single core machine. If there is some cunning
way to specify an actual number of cores to be used, then the person who
wrote a program which uses that deserves to get lots of flak from people
using that program!
Bill
--
+----------------------------------------+
| Bill Purvis |
| email: bill(a)billp.org |
+----------------------------------------+
On Wed, 27 Dec 2017, Jeremy Henty wrote:
I guess my use of the word
"fail" was too vague. Obviously the
software should not crash. But if the user specifies an impossible
combination of options then the software should say "I'm sorry Dave,
I'm afraid I can't do that" rather than silently do something other
than what the user wanted.
My impression is that at the moment most users only get the option of
telling the software "use as many cores as you like" and the software
does the rest for itself, so the issue of the user making impossible
demands does not arise. It would be nice to know for sure what is
going on, but since I am neither a gamer or an audiophile I don't have
the hardware or the incentive to do the research myself.
Regards,
Jeremy Henty Yes, but I am not clear what that means. It
could mean "If you
want I can split the work into concurrent processes/threads in the
hope that you have enough cores to benefit from this.". Or it
could mean "I *will* pin different processes to different cores,
and I will fail if those cores aren't there.".
As a developer, I would
not want my sw to fail because some *** user
told me to spread out my workload over 12 cores when there are only
4. I would want my sw to run and never crash. 
4:16 p.m.
On Wed, Dec 27, 2017 at 02:22:58PM +0000, Bill Purvis wrote:
If there is some cunning
way to specify an actual number of cores to be used, then the person who
wrote a program which uses that deserves to get lots of flak from people
using that program!
Depends on how it's used. For example, Ardour allows you to
set the number of cores used. The default is 'all but one',
and that makes perfect sense.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
5:55 p.m.
On 27/12/17 15:16, Fons Adriaensen wrote:
On Wed, Dec 27, 2017 at 02:22:58PM +0000, Bill Purvis
wrote:
I think that simply limits the number of cores, no guarantee that they
will all be
used. If it runs lots of threads, as I assume it does, then the chances
are it will
use as many cores as are permitted.
BILL
--
+----------------------------------------+
| Bill Purvis |
| email: bill(a)billp.org |
+----------------------------------------+
If there is some cunning
way to specify an actual number of cores to be used, then the person who
wrote a program which uses that deserves to get lots of flak from people
using that program!
Depends on how it's used. For example, Ardour allows you
to
set the number of cores used. The default is 'all but one',
and that makes perfect sense.
Ciao, 
6:24 p.m.
On Wed, Dec 27, 2017 at 11:55 AM, Bill Purvis <bill(a)billp.org> wrote:
On 27/12/17 15:16, Fons Adriaensen wrote:
Fons description is correct.
Ardour carefully and deliberately creates as many realtime priority threads
for DSP as told to, based on the number of cores that should be used.
On Wed, Dec 27, 2017 at 02:22:58PM +0000, Bill
Purvis wrote:
If there is some cunning
I think that simply limits the number of cores, no guarantee that they
will all be
used. If it runs lots of threads, as I assume it does, then the chances
are it will
use as many cores as are permitted.
way to specify an actual number of cores to be
used, then the person who
wrote a program which uses that deserves to get lots of flak from people
using that program!
Depends on how it's used. For example, Ardour allows you to
set the number of cores used. The default is 'all but one',
and that makes perfect sense.
Ciao,
10:22 p.m.
On Wed, 27 Dec 2017, Manuel Haible wrote:
I assume: for high samplerates + many tracks +
many fx + very small
buffer size + ultra low latency singlecore performance is equally important as
the number of cores?
Any one track with all its effects and buses it feeds must be in the same
thread. That is, any audio operation that requires another's result to
begin it's own processing must be run by the same thread. So yes, single
core performance is important. For example, a guiter effects chain would
be run as a single thread for audio (the GUI would be separate and
probably of low priority) on one core.
That may be part of the problem with multi-core effects that sound better
with multi-core use turned off. An effect is generally a serial chain of
audio processes that should not be split up.
Secondary cores that borrow
resources from another core like hyperthreading, may cause trouble for
very low latency use. In the days of the single core P4, I found that with
HT enabled I had the odd xrun with jack set 64/2, but with HT off I could
get latency of 16/2 with no xruns using an ice1712 interface. I have not
tested things on newer i3/7 cpus as I have side stepped the whole issue by
using a 4 core i5.
CPU speed still affects things though. Anything that changes the cpu speed
seems to affect audio. I have had better results forcing a cpu to only
800Mhz than allowing that same cpu to run at 1.6Ghz with speed changes. My
i5 runs up to 3.2Ghz and just putting it into performance mode helps but
"Boost" can cause xruns too I have found. I think I could set performance
to 3.4ghz (effectively over clocking) and get things to work as the
temperature stays within limits even with all 4 cores at 100% (building
Ardour takes 15 minutes or so and makes quite a good cpu "burn" test) and
audio can not run at 100% anyway. But I have not tried that.
--
Len Ovens
www.ovenwerks.net
7 p.m.
On Wed, 27 Dec 2017 15:16:49 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Wed, Dec 27, 2017 at 02:22:58PM +0000, Bill Purvis
wrote:
Well, this is all very interesting. Using some of these answers as a
springboard and then doing searches it seems that you can actually assign a
thread to a specific core.
If I've understood that correctly you can also ensure that they are also on the
same socket, which apparently improves memory access.
Not sure what I can do with the information. I shall have to do some more
digging... Anyone got a spare JCB :)
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
If there is some cunning
way to specify an actual number of cores to be used, then the person who
wrote a program which uses that deserves to get lots of flak from people
using that program!
Depends on how it's used. For example, Ardour allows you to
set the number of cores used. The default is 'all but one',
and that makes perfect sense.
Ciao,
28 Dec
28 Dec
8:12 p.m.
Will Godfrey wrote:
If I've understood that correctly you can also
ensure that they are
also on the same socket, which apparently improves memory access.
I think this is what is meant by NUMA (Non-Uniform Memory access).
These days, the time it takes for a core to access memory, even on the
same chip, can depend on where the core and memory are on the chip.
So if you want threads to share memory as fast as possible you need to
be able to pin them down.
The downside is that running many CPU-hungry threads close together on
the chip can cause overheating, causing the CPU to throttle everything
back until things cool off. The CPU architecture giveth, and the CPU
architecture taketh away.
Regards,
Jeremy Henty
11:16 p.m.
On Thu, Dec 28, 2017 at 2:11 PM, Jeremy Henty <onepoint(a)starurchin.org>
wrote:
Will Godfrey wrote:
AFAIK, NUMA is dead for everything except a few research systems.
Parallel/multi-processor systems these days are all "symmetric" (all
processors have symmetrical access to all memory).
NUMA is really, really, really hard to get right. Why? Cache invalidation.
Several companies, organizations, etc. have tried. Last time I looked (and
it has been a while, but I was quite involved with this stuff in the mid
1990s), everybody failed.
If I've understood that correctly you can
also ensure that they are
also on the same socket, which apparently improves memory access.
I think this is what is meant by NUMA (Non-Uniform Memory access).
29 Dec
29 Dec
3:27 a.m.
Paul Davis wrote:
On Thu, Dec 28, 2017 at 2:11 PM, Jeremy Henty
<onepoint(a)starurchin.org>
wrote:
Until I read the Wikipedia NUMA page just now I didn't realise that
NUMA involved multiple processors having their own caches of the same
data. Thanks for bringing me up to speed.
Regards,
Jeremy Henty
Will Godfrey wrote:
AFAIK, NUMA is dead for everything except a few research systems.
Parallel/multi-processor systems these days are all "symmetric" (all
processors have symmetrical access to all memory).
NUMA is really, really, really hard to get right. Why? Cache
invalidation. Several companies, organizations, etc. have
tried. Last time I looked (and it has been a while, but I was quite
involved with this stuff in the mid 1990s), everybody failed. If I've understood that correctly you can
also ensure that they are
also on the same socket, which apparently improves memory access.
I think this is what is meant by NUMA (Non-Uniform Memory access). 
9 a.m.
Paul Davis wrote:
AFAIK, NUMA is dead for everything except a few
research systems.
Parallel/multi-processor systems these days are all "symmetric" (all
processors have symmetrical access to all memory).
While all processors have the ability to access all memory, the speed
of these accesses is different when there are multiple memory
controllers. So all multi-socket systems, and CPUs with multiple memory
controllers on one die (Threadripper, some Xeons) are NUMA.
Regards,
Clemens
5:23 p.m.
On Fri, Dec 29, 2017 at 2:59 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
Paul Davis wrote:
Are they NUMA in the "traditional" sense that there are local caches and a
complex cache invalidation scheme? Or just NUMA in the sense that "it's a
bit slower to get there from here"?
AFAIK, NUMA is dead for everything except a few
research systems.
Parallel/multi-processor systems these days are all "symmetric" (all
processors have symmetrical access to all memory).
While all processors have the ability to access all memory, the speed
of these accesses is different when there are multiple memory
controllers. So all multi-socket systems, and CPUs with multiple memory
controllers on one die (Threadripper, some Xeons) are NUMA.
7:10 p.m.
On Fri, December 29, 2017 10:23 am, Paul Davis wrote:
âAre they NUMA in the "traditional" sense
that there are local caches
and a complex cache invalidation scheme? Or just NUMA in the sense that
"it's a
bit slower to get there from here"?
Well, technically NUMA means non-uniform memory access, so any shared
memory scheme that has differing access speeds for different parts of the
address space counts as NUMA, but yes, any modern multi-socket server or
workstation is considered cache-coherent NUMA, and even many single die
processors have multiple levels of cache that are dedicated per core or
pair of cores, and could be considered a form of NUMA. The new AMD server
and workstation processors are actually NUMA on package, each package has
four separate die mounted with cache-coherent interconnect between the
die, and each die has two memory controllers. On each of the four die the
8 processor cores are arranged in pairs, with some levels of cache
dedicated to each pair, and some shared between all four pairs. So yes,
"complex" is an apt description of the cache management. It is somewhat
mind boggling that it works at all, much less has the performance levels
it does.
--
Chris Caudle
7:15 p.m.
On Fri, Dec 29, 2017 at 1:10 PM, Chris Caudle <chris(a)chriscaudle.org> wrote:
On Fri, December 29, 2017 10:23 am, Paul Davis wrote:
that description makes it sound as if someone (at least AMD) did in fact
figure out a working cache architecture for NUMA. i was working on highly
parallel systems (64 cores) in the mid 90s, and my impression was that
everybody just gave up on the idea that we could ever get cache coherency
correct. it warms my tiny cold (*) heart if someone actually managed to do
so.
(*) it's just the local weather for 10 days, not a psychological condition
​Are they NUMA in the "traditional"
sense that there are local caches
and a complex cache invalidation scheme? Or just NUMA in the sense that
"it's a
bit slower to get there from here"?
Well, technically NUMA means non-uniform memory access, so any shared
memory scheme that has differing access speeds for different parts of the
address space counts as NUMA, but yes, any modern multi-socket server or
workstation is considered cache-coherent NUMA, and even many single die
processors have multiple levels of cache that are dedicated per core or
pair of cores, and could be considered a form of NUMA. The new AMD server
and workstation processors are actually NUMA on package, each package has
four separate die mounted with cache-coherent interconnect between the
die, and each die has two memory controllers. On each of the four die the
8 processor cores are arranged in pairs, with some levels of cache
dedicated to each pair, and some shared between all four pairs. So yes,
"complex" is an apt description of the cache management. It is somewhat
mind boggling that it works at all, much less has the performance levels
it does.
7:35 p.m.
On Fri, December 29, 2017 12:10 pm, Chris Caudle wrote:
any modern multi-socket server or workstation is
considered
cache-coherent NUMA
The lscpu utility will show how many NUMA nodes the kernel scheduler
considers your machine to have.
You can also install numactl to show more details, the output of numactl
--hardware will display the difference in memory access latencies between
the different nodes. You can use more manual control of process placement
with numactl but I don't think that is typically worth the effort on dual
socket machines. Maybe if you are trying to tune your database for
maximum performance on an 8 or 16 socket machine, but that doesn't seem
like something you would typically use for audio processing.
Possibly for extremely low latency use it could be useful to pin all the
audio processes or threads to the cores which share a memory controller,
or to pin them to the socket which controls the I/O connector with the
sound card. Again seems like a pretty special case, not something that
would go into the linux audio FAQ for example.
--
Chris Caudle
9:59 p.m.
On Thu, 28 Dec 2017 17:16:40 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Thu, Dec 28, 2017 at 2:11 PM, Jeremy Henty
<onepoint(a)starurchin.org>
wrote:
This is proving to be quite fascinating, so thanks everyone for jumping on
board and contributing.
I won't say the mists have cleared, but they certainly seem a lot thinner :)
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Will Godfrey wrote:
AFAIK, NUMA is dead for everything except a few research systems.
Parallel/multi-processor systems these days are all "symmetric" (all
processors have symmetrical access to all memory).
NUMA is really, really, really hard to get right. Why? Cache invalidation.
Several companies, organizations, etc. have tried. Last time I looked (and
it has been a while, but I was quite involved with this stuff in the mid
1990s), everybody failed.
If I've understood that correctly you can
also ensure that they are
also on the same socket, which apparently improves memory access.
I think this is what is meant by NUMA (Non-Uniform Memory access).
27 Dec
27 Dec
2:14 a.m.
On December 26, 2017 10:34:26 AM HST, Will Godfrey <willgodfrey(a)musically.me.uk>
wrote:
It seems everyone is dropping support for 32 bit
machines these days -
including
a number of Linux distros.
It makes me wonder how long it will be before single core machines go
the same
way. Has anyone seen any hint of that yet?
I think it was LAC 2008 where I first heard discussion on how to plan
for
multi-core kit - not that I was touching any code back then :)
Well, in response to both 32-bit and multicore topics...my wife's old netbook
(don't recall exactly how old, but at least 7 years old) came with a 64-bit, dual-core
processor. While its hardware is limited to 2GB RAM, it is running 64-bit Ubuntu.
Even the processor called a "Pentium" in a cheap little-use desktop I have is
64-bit 2 cores.
Even the old, cheap entry-level tablet I'm using has a 64-bit 4-core chip in it. (Not
to ignore the 64 GPU cores the Tegra chip also includes.)
Single core CPUs went away a long time ago.
Just to put it in perspective.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
Sent from my Android device with K-9 Mail.
28 Dec
28 Dec
9:09 p.m.
On 12/26/2017 09:34 PM, Will Godfrey wrote:
It seems everyone is dropping support for 32 bit
machines these days
- including a number of Linux distros.
so the rpi is finally going down the drain?
(or not so, just because Debian is conservative enough to not drop 32bit
archs?)
It makes me wonder how long it will be before single core machines go the same
way. Has anyone seen any hint of that yet?
i'm having a hard time imagining an audio software system that cannot
run on multi-core systems with N==1.
(unless you setup artificial guards that will simply refuse to run if
they detect less than N>1 CPUs)
as others pointed out: 32bit vs 64bit is (from a distro perspective) are
(completely) different architectures. otoh, 1 core vs 2 cores vs 4 cores
vs 4069 cores is mainly an hardware extension (that is: the user can -
in theory - just add more CPUs to their existing hardware).
to contracdict myself: one can easily think of audio software that
(strictly) depends on CUDA (or other hardware acceleration), so they
would require multiple PUs (that's even worse than requiring multiple
cores).
or audio software that requires super computing powers with many-core
systems to do anything in a reasonable time (deep learning foo).
but i tihnk both these examples will stay niche products (even nichier
than your average linux software) in the foreseeable future, so
shouldn't concern you much :-)
otoh, i think one important development in the last years has been
virtualisation.
now running a couple of VMs on your 16 core laptop will quickly eat away
your CPU powers - and more so, if you allocate 8 cores to each VM.
so my personal VMs only get a single core allocated by default.
while running audio software in a VM might seem a but odd, i think that
any software not allowing such a use-case should die right away
(probably excepting virtualisation software),
gadsmr
IOhannes
9:18 p.m.
On Thu, 28 Dec 2017, IOhannes m zmölnig wrote:
On 12/26/2017 09:34 PM, Will Godfrey wrote:
I think that is not what is meant... I think the distros are getting rid
of 32bit intel (x86) stuff. Arm is a whole different subject (mud puddle).
--
Len Ovens
www.ovenwerks.net
It seems everyone is dropping support for 32 bit
machines these days
- including a number of Linux distros.
so the rpi is finally going down the drain?
(or not so, just because Debian is conservative enough to not drop 32bit
archs?)
2523
days inactive
2526
days old
linux-audio-user@lists.linuxaudio.org
29 comments
13 participants
participants (13)
-
Bill Purvis -
Chris Caudle -
Clemens Ladisch -
David W. Jones -
Fons Adriaensen -
IOhannes m zmölnig -
Jeremy Henty -
jonetsu -
Len Ovens -
Manuel Haible -
Paul Davis -
Ralf Mardorf -
Will Godfrey