Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #41793
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: GA144 use cases |
| Date | 2015-09-06 14:51 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2015Sep6.165104@mips.complang.tuwien.ac.at> (permalink) |
| References | (7 earlier) <msal0b$udo$1@dont-email.me> <2015Sep4.102450@mips.complang.tuwien.ac.at> <msc53k$en6$1@dont-email.me> <2015Sep5.171017@mips.complang.tuwien.ac.at> <msfhog$ej7$1@dont-email.me> |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>No, that's not a resource lock, that's a wakeup signal.
>>
>> Only one thread is active, so there can be no contention. You are
>> thinking about something that is not contention.
>
>"Contention" here is when someone has to wait.
It does not help if you use established terms with a different
meaning. When someone talks about locks (and mutexes (including
futexes) are kinds of locks), contention has a specific meaning, and
when only one thread is accessing the lock, there is no contention.
>It's not the same sort of contention you have with equal processes, it's
>"pipeline contention".
Googling for "pipeline contention" did not give me appropriate hits,
so it seems that is not an established term.
>> If the consumers are faster than the producers, run the producers on
>> more cores than the consumers. If you have only one producer, and
>> that is sequential, and the consumers combined are still faster than
>> the producer, you have a parallelism of <2.
>
>I don't quite see the problem of having a parallelism of say 1.8, and be
>able to use it. When the wake/sleep operation costs me as much as
>processing one block, I can't use it.
Make the blocks longer, and you can. Or, if you don't want to do
that, and you are certain about the 1.8 paralellism, use busy waiting
with PAUSE. It would be cool if you could slow the clock for the core
with the faster thread, but I think that's not possible (having only
one thread on the core and that using PAUSE might be a sign to the
hardware to slow the clock down, but I doubt that this is done yet).
>The overall number of available cores
>today is a small integer, so I can't have 10 producers and 9 consumers
>running in parallel.
On some Xeons you can, but anyway, you get different problems when you
want to exploit a parallelism of 1.8 on a four-core CPU, or a
parallelism of 19.
>> You can still reduce the
>> wakeup overhead by only sending wakeup signals when the producer has
>> produced enough (and stored it in a buffer) that the wakeup overhead
>> is small compared to the processing time. Yes, this increases
>> latency, so it's a balance of efficiency vs. latency; you can bound
>> the increase in latency by waking the consumer some fixed time after
>> the producer has started producing.
>
>net2o's timing-based flow control breaks with that approach. You have to
>process each packet as soon as possible, and finally, when a packet arrived
>unencrypted in its destination, you take the time of arrival.
So when your machine is busy and may context-switch your net2o threads
out in favor of something else, your control-flow approach breaks.
Hmm. Maybe it needs some more work to be less brittle.
>>>And yes, I've a model in mind, where more compute cores are sleeping than
>>>working; with a x64-style implementation, you would use SMT for that, not
>>>multiple cores.
>>
>> If there are not enough active threads for all the cores, the only
>> reason to use SMT is to conserve energy or because communication is
>> cheaper (the shared cache is L1 instead of L3). But if you are
>> interested in performance, I expect that, running two threads on two
>> otherwise idle cores usually gives better performance than running
>> them in the same core, even if they communicate. Sure, there is the
>> PAUSE instruction for slowing a waiting thread down, but even with
>> that, i expect that situation where SMT performs better than two cores
>> are not very common.
>
>My situation is different: I've running and sleeping processes, and I want
>to wake/sleep them quickly. Using different cores and having them all spin-
>loop is consuming energy and a waste of resources, because the threads are
>waiting.
Yes, but it's what is available.
>So I put them all as "semi-active" on a SMT core, where the
>sleeping threads only consume registers in the register file, but can start
>running within a nanosecond.
Sure, but if you have such such sleep/wakeup instructions, there is no
need to restrict this to SMT. An otherwise idle core can also sleep
with the thread state in the register file etc, and then wake up in a
nanosecond.
>>>And buffering reduces performance, as it requires way more actual
>>>parallelism.
>>
>> Buffering also enables parallelism. E.g., with a conventional screen
>> and with vertical synchronization to avoid tearing, double buffering
>> means that rendering has to wait for the vsync, while with tripple
>> buffering there can be rendering all the time.
>
>But the right solution is to go away from the fixed refresh, and display the
>buffers when they are ready.
If you have a screen that supports that, fine. Most screens don't,
yet. Anyway, this is an example of how having more buffers helps
parallelism. I can also give others: E.g., CPUs have write buffers,
OSs have write buffers, hard disk drives have write buffers, ... They
also have read buffers, and data from disk is stored in buffers in RAM
instead of being caught from the wire by the CPU.
>BTW: Just moving the task switch from software into microcode doesn't make
>it "hardware". Neither iAPX 432 or 286 PM had any hardware capabilities for
>task switching, they both just had complicated microcode. AFAIK, a Forth
>PAUSE with pusha/mov sp,[up+next]/popa was about two orders of magnitude
>faster than a task gate call.
It also does much less. But it seems that, what the task gate does
more is not actually worth the price (although there are probably
still fans of advanced security concepts that disagree).
>> You may be dreaming of hardware that has, say, dozens sets of
>> process/thread states per core, most of which are sleeping most of the
>> time, and that can put themselves to sleep cheaply, and be woken up
>> cheaply, but you have to make a really good case for that to get it
>> included in hardware. Is your model of lots of small tasks with
>> little parallelism overall really that relevant?
>
>That's your model, not mine. Let's repeat it:
>
>* The tasks are small, so that expensive wake/sleep operations don't work,
>and moving the tasks from one core to the other is also not a good idea.
>Hot tasks which are already in the L1 code cache and data in L1 data cache
>can easily be several times faster than "cold tasks". There's not enough
>work for one specific task to run all the time, because the tasks are
>diverse.
>
>* The tasks are related to each other in a consumer-producer relation,
>sometimes with DAG-like structures, i.e. a task may combine the output of
>two producers, or feed two consumers.
>
>* There are enough of those tasks to keep all cores in current CPUs active
>(and maybe many more), but when used with the current high-overhead IPC,
>there's no benefit.
But for that problem, you don't need much OS-level stuff. If you can
keep all the cores (and hardware threads) busy, the solution is to
create one OS-level thread per hardware thread and have a user-level
schedulers within each thread that schedules the tasks and coordinates
with the other schedulers (using user-level means) to balance the load
etc.
I don't see a need for special hardware for that problem. It's only
when you cannot keep everything busy that OS-level stuff (or busy
waiting) comes into play.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
GA144 use cases dunno <dunno@dunno.dunno> - 2015-08-31 07:20 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-08-31 09:55 -0400
Re: GA144 use cases Syd Rumpo <usenet@nononono.co.uk> - 2015-08-31 16:49 +0100
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-08-31 18:35 -0400
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-08-31 19:08 -0700
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 10:57 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 14:17 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 11:28 -0700
Re: GA144 use cases hughaguilar96@gmail.com - 2015-09-02 13:41 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 16:50 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 15:03 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 18:18 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 16:14 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 20:40 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-02 17:53 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 21:25 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 22:28 -0700
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-02 22:53 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 11:32 -0400
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-03 11:57 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-03 10:35 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 15:54 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-03 16:11 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 13:06 -0400
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:07 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-04 11:49 -0400
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 11:06 +0000
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-05 09:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-05 12:59 -0400
Re: GA144 use cases mhx@iae.nl - 2015-09-05 10:56 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:29 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 22:08 +0200
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-03 14:00 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 01:28 +0200
Re: GA144 use cases franck.bensusan@gmail.com - 2015-09-03 23:04 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:24 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 15:09 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 15:10 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 22:04 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:51 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-06 22:51 +0200
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-06 17:30 -0700
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-04 22:27 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 13:07 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 11:22 +0000
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:14 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 15:13 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 16:06 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 21:05 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:37 +0000
Re: GA144 use cases Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-11-30 04:17 -0600
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-01 23:06 +0100
Re: GA144 use cases Mark Wills <markwills1970@gmail.com> - 2015-09-03 00:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 13:08 -0400
Re: GA144 use cases forther <forther@gmail.com> - 2015-09-07 11:26 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 15:15 -0400
Re: GA144 use cases forther <forther@gmail.com> - 2015-09-07 11:21 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-11-30 16:33 -0500
Re: GA144 use cases forther <forther@gmail.com> - 2015-12-03 12:12 -0800
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-12-03 16:10 -0500
Re: GA144 use cases Jason Damisch <jasondamisch@yahoo.com> - 2015-09-02 12:10 -0700
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-03 01:27 -0700
Re: GA144 use cases Syd Rumpo <usenet@nononono.co.uk> - 2015-09-03 13:32 +0100
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 11:32 -0400
Re: GA144 use cases mhx@iae.nl (Marcel Hendrix) - 2015-09-03 18:57 +0200
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 23:58 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 07:52 +0000
Re: GA144 use cases Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-09-05 16:32 +0000
Re: GA144 use cases mhx@iae.nl - 2015-09-05 10:52 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 22:11 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:18 +0000
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-07 07:49 +0000
Re: GA144 use cases Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-09-05 23:42 +0000
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-05 17:25 -0700
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-07 03:18 -0700
Re: GA144 use cases Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-09-07 03:31 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-07 15:06 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-08 21:41 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 02:54 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 03:02 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 16:55 -0400
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-09 20:12 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 23:40 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 23:43 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 00:07 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 21:55 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 01:43 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 23:49 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 14:43 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 16:10 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-12 03:15 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-12 10:28 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 13:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-13 18:59 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 18:42 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-13 22:47 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 21:24 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 02:00 -0400
Re: GA144 use cases borota@gmail.com - 2015-09-14 08:35 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 12:06 -0400
Re: GA144 use cases borota@gmail.com - 2015-09-14 09:33 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 13:25 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-14 14:17 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 18:12 -0400
Re: GA144 use cases Greg <schmegner@gmail.com> - 2015-09-14 18:15 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 22:16 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-18 14:50 -0700
Re: GA144 use cases Jason Damisch <jasondamisch@yahoo.com> - 2015-09-18 15:11 -0700
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-19 05:32 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-19 08:39 -0700
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-20 19:03 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-21 06:44 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-22 13:10 -0700
Re: GA144 use cases Mark Wills <markwills1970@gmail.com> - 2015-09-18 16:18 -0700
Re: GA144 use cases schmegner@gmail.com - 2015-09-14 18:21 -0700
csiph-web