Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #41625 > unrolled thread
| Started by | dunno <dunno@dunno.dunno> |
|---|---|
| First post | 2015-08-31 07:20 +0000 |
| Last post | 2015-09-14 18:21 -0700 |
| Articles | 20 on this page of 115 — 25 participants |
Back to article view | Back to comp.lang.forth
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
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-09-06 22:51 +0200 |
| Message-ID | <msi8s6$fph$1@dont-email.me> |
| In reply to | #41793 |
Anton Ertl wrote: > 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. Well, I don't remember any specific term for this. The discussion in computer science is always resource sharing, and sleeping apparently isn't even under consideration. Probably because power management wasn't an issue 40 years ago, when the terms were invented. But now, you have to run to finish and then go to sleep, because power budget is a problem. And we have multiple cores and need parallelism. >>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. The reason why I use "contention" is that it fits the way you think about contention with a lock: If there is contention, one task has to go to sleep. And a pipeline is a shared resource, with one writer and one reader. The difference between a lock is the contention case, because the access to the pipeline is not identical. Due to the different situations, pipelines can either jam or stall. If you don't like the term "contention", give me a reference to the current computer science term. If there is no, write a paper to create one. >>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. In net2o, the block size depends on the size of Internet packets; there's a fixed limit. Actually, I think this suggestion is silly, because the smaller the blocks are we can handle efficiently, the higher the potential of parallelism is; this is just the result of Amdahl's law. And the question is whether the high overhead we have now is really necessary, and what can be done about it. The discussion is not about how more parallelism can be achieved in different situations, because these different situations already do well. > 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). Unfortunately, you don't know in advance which path is actually used how often, so full busy-waiting is out of question. Busy-waiting during activity is possible, but so far, I haven't found a robust way to switch over between busy-waiting and non-busy. The Linux kernel futex() call, which wakes up a thread when you write a memory location from another thread, could do that. > 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. No, this works perfectly. When net2o gets kicked out, it detects the slow- down, and reports that to the other side, which adjusts its sender rate. If I change the internal operation of net2o, even though it's active all the time, a false reported "I'm slow" just because I need to fill up an internal pipeline before I start running decryption due to slow IPC is really not what I want. I would have more processing power, and could process packets actually faster! >>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. And I'm not happy with what's available and try to think how to improve that. >>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. The point with SMT is that you can have more than one sleeping thread per core. In a non-SMT-situation, you can only have one sleeping thread per core, and completely sleeping cores are often not startable in a nanosecond. That's because sleeping cores have reduced voltages. Running SMT cores have full voltage, and therefore can go full speed from zero in a nanosecond. endering all the time. > 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. Works fine when you can run the thread all the time; but this is completely out of question with the power budget problems we have today... If you don't have an OS at all, there's already support for sleep/wake IPC for hardware threads (by monitoring memory in the core during sleep, and writing to that memory region for wake), so with my own OS, I could do something. > 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. Indeed, but that's a very typical situation. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Greg <borota@gmail.com> |
|---|---|
| Date | 2015-09-06 17:30 -0700 |
| Message-ID | <efc3c600-e7d2-473d-b2fc-5760ce7713f6@googlegroups.com> |
| In reply to | #41800 |
On Sunday, September 6, 2015 at 3:51:02 PM UTC-5, Bernd Paysan wrote: > Anton Ertl wrote: > > > Bernd Paysan 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. > > Well, I don't remember any specific term for this. The discussion in > computer science is always resource sharing, and sleeping apparently isn't > even under consideration. Probably because power management wasn't an issue > 40 years ago, when the terms were invented. > > But now, you have to run to finish and then go to sleep, because power > budget is a problem. And we have multiple cores and need parallelism. > > >>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. > > The reason why I use "contention" is that it fits the way you think about > contention with a lock: If there is contention, one task has to go to > sleep. And a pipeline is a shared resource, with one writer and one reader. > The difference between a lock is the contention case, because the access to > the pipeline is not identical. > > Due to the different situations, pipelines can either jam or stall. > > If you don't like the term "contention", give me a reference to the current > computer science term. If there is no, write a paper to create one. > > >>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. > > In net2o, the block size depends on the size of Internet packets; there's a > fixed limit. Actually, I think this suggestion is silly, because the > smaller the blocks are we can handle efficiently, the higher the potential > of parallelism is; this is just the result of Amdahl's law. And the > question is whether the high overhead we have now is really necessary, and > what can be done about it. > > The discussion is not about how more parallelism can be achieved in > different situations, because these different situations already do well. > > > 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). > > Unfortunately, you don't know in advance which path is actually used how > often, so full busy-waiting is out of question. Busy-waiting during > activity is possible, but so far, I haven't found a robust way to switch > over between busy-waiting and non-busy. The Linux kernel futex() call, > which wakes up a thread when you write a memory location from another > thread, could do that. > > > 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. > > No, this works perfectly. When net2o gets kicked out, it detects the slow- > down, and reports that to the other side, which adjusts its sender rate. > > If I change the internal operation of net2o, even though it's active all the > time, a false reported "I'm slow" just because I need to fill up an internal > pipeline before I start running decryption due to slow IPC is really not > what I want. I would have more processing power, and could process packets > actually faster! > > >>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. > > And I'm not happy with what's available and try to think how to improve > that. > > >>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. > > The point with SMT is that you can have more than one sleeping thread per > core. In a non-SMT-situation, you can only have one sleeping thread per > core, and completely sleeping cores are often not startable in a nanosecond. > That's because sleeping cores have reduced voltages. Running SMT cores have > full voltage, and therefore can go full speed from zero in a nanosecond. > endering all the time. > > > 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. > > Works fine when you can run the thread all the time; but this is completely > out of question with the power budget problems we have today... > > If you don't have an OS at all, there's already support for sleep/wake IPC > for hardware threads (by monitoring memory in the core during sleep, and > writing to that memory region for wake), so with my own OS, I could do > something. > > > 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. > > Indeed, but that's a very typical situation. > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself" > net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* > http://bernd-paysan.de/ About some of the performance related discussions in this thread: Having a SSD vs. a regular HDD can make a huge difference in compilation times for projects that involve lots/big files. A 7 years old laptop with 4G of RAM was finishing running about 2000 unit tests in about 1/2 the time my latest generation DELL laptop with 16G of RAM but regular HDD was taking. Part of it had to do with the fact that my IDE was 32 bit, so having extra RAM didn't help that much. But anyway, I find out that these days the point where performance breaks is the hard-disk and not as much the processor and/or RAM, computers come with insane amounts of RAM already. According to Don Knuth, CPU manufactures have already hit the wall, so it's more or less just marketing gimmicks to get people to buy the newer processors. And I find that to be the case too, my newer laptop once I put an SSD in it, it is only very little more performant that the older one - I am talking about 1-2 seconds faster in running those 2000 unit tests, for a total time of over 1 min. And about multiple core, I now and then run into performance issues and investigation may lead to OS spinning wheels on distributing the tasks between cores, instead of solving those tasks. It may be and issue in the OS implementation itself, but this does seem to happen often enough that people came up with a name for it, but what is it called escapes my mind at the moment. Having a SSD vs. a regular HDD can make a huge difference in compilation times for projects that involve lots/big files. A 7 years old laptop with 4G of RAM was finishing running about 2000 unit tests in about 1/2 the time my latest generation DELL laptop with 16G of RAM but regular HDD was taking. Part of it had to do with the fact that my IDE was 32 bit, so having extra RAM didn't help that much. But anyway, I find out that these days the point where performane breaks is the hard-disk and not so much the processer and/or RAM, computers come with insane amounts of RAM. According to Don Knuth, CPU manufactures have already hit the wall, so it's more or less just marketing gimmicks to get people to buy the newer processors. And I find that to be the case too, my newer laptop once I put an SSD in it, it is only very little more performant that the older one - I am talking about 1 sencod faster in running those 2000 unit tests, for a total time of over 1 min. And about multiple core, I now and then run into performance issues and investigation may lead OS spinning wheels on distributing the tasks between cores, instead of solving those tasks. It may be and issue in the OS implementation itself, but this does seem to happen often enough that people came up with a name for it, but what is it called escapes my mind at the moment.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-09-04 22:27 -0700 |
| Message-ID | <87twr9fnbm.fsf@jester.gateway.sonic.net> |
| In reply to | #41712 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Unfortunately, the contention is the rule, and the uncontented case > the exception. The problem of asynchronous tasks is that either the > producer or the consumer waits, and that's the contented case. If one of them is waiting then that's uncontended. The one that is waiting is in a kernel sleep. Assuming both tasks actually do significant computation (otherwise there's no point in putting them on different cores), if they're communicating through a task queue, they should both spend almost no time dealing with the lock (futex). The producer generates a new task, acquires the lock, puts the task on the queue, and releases the lock. The consumer finishes doing a task and checks whether there's a new one by acquiring the lock and similarly manipulating the queue. Both queue manipulations take maybe 100 cycles and there is only contention if both processes are simultaneously doing that. And of course you can use multiple queues etc. New Intel processors have some kind of hardware assistance for memory transactions (TSX extension) but I don't currently understand how it works.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-09-05 13:07 +0200 |
| Message-ID | <msei9u$b3j$1@dont-email.me> |
| In reply to | #41748 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> Unfortunately, the contention is the rule, and the uncontented case >> the exception. The problem of asynchronous tasks is that either the >> producer or the consumer waits, and that's the contented case. > > If one of them is waiting then that's uncontended. Like Anton, you don't get it. The wake signal "contention" is when you need a state transition, sleep to active. It's not like a mutex where contention means "both want the same resource at the same time". > The one that is > waiting is in a kernel sleep. Assuming both tasks actually do > significant computation (otherwise there's no point in putting them on > different cores), if they're communicating through a task queue, they > should both spend almost no time dealing with the lock (futex). The > producer generates a new task, acquires the lock, puts the task on the > queue, and releases the lock. The consumer finishes doing a task and > checks whether there's a new one by acquiring the lock and similarly > manipulating the queue. Both queue manipulations take maybe 100 cycles > and there is only contention if both processes are simultaneously doing > that. And of course you can use multiple queues etc. You can only continue working with a queue that's filling up. In this case you'll end up with the producer sleeping and waking, as the queue is not infinite in size, and you really need a distribution of workload where the consumer has more work to do than the producer. If the consumer has only slightly less workload than the producer, the queue will always be empty. That was the case with my net2o experiment: The kernel took longer to deliver a packet through the socket layer than Keccak took to decrypt it. So the consumer (decrypt task) always had an empty queue. The pushing into the queue does not even require setting a lock. It's a single writer, single reader situation. You just put your data into the queue, update the "end" counter, and then you need to make sure the consumer is awake. That's the only expensive operation. > New Intel processors have some kind of hardware assistance for memory > transactions (TSX extension) but I don't currently understand how it > works. That's essentially for spin locks. If you understand how a data base works, it's easy to understand: You read several values in transaction mode, and then you write your results into a commit buffer. Finally, you either commit (if none of the read values have been changed in the meantime), or you rinse and repeat. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-09-05 11:22 +0000 |
| Message-ID | <2015Sep5.132252@mips.complang.tuwien.ac.at> |
| In reply to | #41748 |
Paul Rubin <no.email@nospam.invalid> writes:
>New Intel processors have some kind of hardware assistance for memory
>transactions (TSX extension) but I don't currently understand how it
>works.
AFAIK they don't specify that, so it can be implemented in different
ways, but the little I have read about it sounded like an extended
form of load-locked/store-conditional to me: I.e., one CPU does things
in cache lines, and if another CPU accesses these cache lines in the
meantime, the transaction is rolled back to the beginning. In any
case, the minimal latency for some synchronization thing is still the
same (determined by the round-trip through the shared cache), but you
can do more sophisticated synchronization stuff with it.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-09-04 08:14 +0000 |
| Message-ID | <2015Sep4.101402@mips.complang.tuwien.ac.at> |
| In reply to | #41706 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> If it's just communication, that can go pretty fast through shared
>> memory; on a single-socket multi-core CPU, that's a trip through the
>> L3 cache (<100 cycles latency for the first cache line; and you can
>> communicate pretty long blocks with pretty low additional overhead).
>
>No, the main problem is telling the other thread that there is some data for
>it. That's using an OS IPC call, and that takes several thousand cycles.
>You can pass around a lot of data between the cores; that works well.
That's synchronization, and you don't need to to that through the OS,
you can also use the user level. Unfortunately, I don't know of a
user-level portable library for this stuff.
>> If you manage to use large blocks and synchronization is rare, you can
>> make good use of multiple cores. OTOH, if you need to create lots of
>> short-running tasks and combine their results, you will probably see a
>> lot of overhead.
>
>Yes, and that's the problem. There are a lot of low-hanging fruits for
>parallelization which are short-running tasks.
However, even for that you do not need OS-level synchronization for
every task: the boss can set up lots of tasks, and each worker thread
takes a task, performs it, then calls the per-thread scheduler, which
takes and performs the next task. If there are many short tasks, a
whole batch of them should be assigned to one worker to reduce
synchronization overhead between workers.
>> You can get that by mmap()ing the memory once read-only and once
>> read/write. If you want to mmapt them to the same address, I think
>> you need to do that in two different processes.
>
>Multiple threads in one process all see the same mapping. It works between
>different processes, because they have different page tables.
Yes, so if you want different permissions for threads of one process,
you need to map the same thing two times (at different addresses),
once read-write and once read-only.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-09-04 15:13 +0200 |
| Message-ID | <msc59k$ffs$1@dont-email.me> |
| In reply to | #41718 |
Anton Ertl wrote: >>Multiple threads in one process all see the same mapping. It works >>between different processes, because they have different page tables. > > Yes, so if you want different permissions for threads of one process, > you need to map the same thing two times (at different addresses), > once read-write and once read-only That would still give the other thread write-access to the read-write mapping, and you have to solve the relocation problem, too. You really want the data to sit on the same addresses,so that all pointers work without trickery. I don't see a way to have different permissions for threads in one process cheaply (i.e. without having separate page tables for each thread) without hardware support. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-09-05 16:06 +0000 |
| Message-ID | <2015Sep5.180619@mips.complang.tuwien.ac.at> |
| In reply to | #41722 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>>>Multiple threads in one process all see the same mapping. It works
>>>between different processes, because they have different page tables.
>>
>> Yes, so if you want different permissions for threads of one process,
>> you need to map the same thing two times (at different addresses),
>> once read-write and once read-only
>
>That would still give the other thread write-access to the read-write
>mapping, and you have to solve the relocation problem, too.
Yes.
>You really want
>the data to sit on the same addresses,so that all pointers work without
>trickery.
>
>I don't see a way to have different permissions for threads in one process
>cheaply (i.e. without having separate page tables for each thread) without
>hardware support.
You have the hardware support, it's used for processes. There have
been various discussions about providing things in OSs that are
between threads and processes; I don't know if different memory
permissions have been touched in these discussions.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-09-05 21:05 +0200 |
| Message-ID | <msfeab$19f$1@dont-email.me> |
| In reply to | #41766 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>That would still give the other thread write-access to the read-write >>mapping, and you have to solve the relocation problem, too. > > Yes. In a 386 system, you might be able to do that with segments... but nobody likes segments ;-). >>You really want >>the data to sit on the same addresses,so that all pointers work without >>trickery. >> >>I don't see a way to have different permissions for threads in one process >>cheaply (i.e. without having separate page tables for each thread) without >>hardware support. > > You have the hardware support, it's used for processes. No, you have separate page tables for different processes, and you swap page tables on context switch. That's a software solution. The main reason for threads is to not have the same overhead as for processes. You could share the read-only page tables between all threads that are not allowed to read, but the context switch still would be an expensive inter- process switch with a TLB flush. > There have > been various discussions about providing things in OSs that are > between threads and processes; I don't know if different memory > permissions have been touched in these discussions. I hope so. One problem why the existing sandbox in Linux is next to useless is that it needs a helper thread which runs the checks, and there, only the register file is private data. That doesn't work very well. For that purpose, using one of the unused rings could help - the hardware has support for separate permissions in different rings. Therefore, the kernel-based sandbox (with code compiled by the Berkeley packet filter stuff) is better, but the awful part here is that now the supervisor part executes code in kernel space. Any red pill code not only can break out of the sandbox, but then owns the kernel. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-09-06 14:37 +0000 |
| Message-ID | <2015Sep6.163717@mips.complang.tuwien.ac.at> |
| In reply to | #41777 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>I don't see a way to have different permissions for threads in one process
>>>cheaply (i.e. without having separate page tables for each thread) without
>>>hardware support.
>>
>> You have the hardware support, it's used for processes.
>
>No, you have separate page tables for different processes, and you swap page
>tables on context switch. That's a software solution.
Well, switching between threads with only one hardware thread running
is also a software solution.
The corresponding hardware solution is to have two cores running the
two threads or processes, or two SMT threads on a core, and for that
it does not matter whether the OS sees the two hardware threads as
processes or as threads.
>The main reason for
>threads is to not have the same overhead as for processes.
I think that the main reason for threads is to have less work when you
want to share things, in particular memory. No need to create a
shared-memory object or a file, and map it into the address space,
etc.
>You could share the read-only page tables between all threads that are not
>allowed to read, but the context switch still would be an expensive inter-
>process switch with a TLB flush.
Other architectures have an address-space ID (ASID) to avoid flushing
the TLB on a context switch, but I guess Intel/AMD found efficient
ways to work without that; or have they? The introduction of AMD64
would have been a good time to add ASIDs, but they didn't.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2015-11-30 04:17 -0600 |
| Message-ID | <QPGdnYjmj_mjv8HLnZ2dnUU7-IWdnZ2d@supernews.com> |
| In reply to | #41696 |
Bernd Paysan <bernd.paysan@gmx.de> wrote:
>
> The problem with parallelism I have is not that I can't imagine it, but that
> the overhead is too large. E.g. take net2o: I send and receive messages
> (each takes time in the kernel), and I decrypt and encrypt them. With a
> four-core CPU, I could run that in four tasks.
>
> However, when trying that, I found that the IPC is killing the
> performance. These tasks don't take too much time - en/decrypting a
> 1k block takes 10k cycles, and the IPC then takes about as long,
> too, so all the gain goes down the flush.
>
> What we need for this sort of lightweight tasks done in parallel is
> a lightweight, fast, in-hardware IPC, similar in spirit to the GA144
> connections or Transputer links.
>
> Such a link would pass up to one word (that's 64 bit now) in a go,
> and each process can wait for data from a link or several links
> (whichever comes first, will be used). The links would be routed
> links, so there's no need to put a task on a specific core. And the
> registers of a waiting task would still be kept in the register
> file; maybe you can have 2 active tasks per core (SMT), and 8
> waiting. If the OS decides that one task needs to be swapped out of
> the core, its links become dangling, and will send a "wake me up"
> token to the scheduler task (which the OS never throws out of a
> core).
I'm sorry to be replying to this late: I only just saw it.
There is a mechanism to do something very similar this on ARMv8. WFE
waits for an event on one address in the cache. If any core writes to
this address the waiting core is restarted, and this happens very
quickly. It's also possible to use a timer stream to combine WFE with
a timeout, so that if there is nothing to do for some time a thread
can yield.
The waiting loop looks like this:
sevl
1: wfe
2: ldaxr w1, [w0]
cbnz w1, %1b
stxr w1, w2, [w0]
cbnz w1, %2b
WFE can finish spuriously due to e.g. an interrupt so it's necessary
to loop.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-12-01 23:06 +0100 |
| Message-ID | <n3l5h7$j8n$1@dont-email.me> |
| In reply to | #43964 |
Andrew Haley wrote: > I'm sorry to be replying to this late: I only just saw it. > > There is a mechanism to do something very similar this on ARMv8. WFE > waits for an event on one address in the cache. If any core writes to > this address the waiting core is restarted, and this happens very > quickly. It's also possible to use a timer stream to combine WFE with > a timeout, so that if there is nothing to do for some time a thread > can yield. > > The waiting loop looks like this: > > sevl > 1: wfe > 2: ldaxr w1, [w0] > cbnz w1, %1b > stxr w1, w2, [w0] > cbnz w1, %2b > > WFE can finish spuriously due to e.g. an interrupt so it's necessary > to loop. Yes, this sort of instructions can be used to implement such low-overhead communication. Unfortunately, the ARM64 manual is 5000 pages thick, but the description of WFE is just a bit blah blah :-(. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-09-03 00:05 -0700 |
| Message-ID | <068f91b2-8d4a-4c75-bdc0-365439711d74@googlegroups.com> |
| In reply to | #41678 |
On Wednesday, 2 September 2015 23:18:31 UTC+1, rickman wrote: > Did you read my post? Are you happy with 9 bit audio? Hey! Don't knock it. The Emulator I and II Synths from E-Mu were both 8-bit samplers, and they're on more pop and rock records from the 80s and 90s than you can shake a stick at! :-)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-03 13:08 -0400 |
| Message-ID | <ms9unc$1f8$2@dont-email.me> |
| In reply to | #41691 |
On 9/3/2015 3:05 AM, Mark Wills wrote: > On Wednesday, 2 September 2015 23:18:31 UTC+1, rickman wrote: >> Did you read my post? Are you happy with 9 bit audio? > > Hey! Don't knock it. The Emulator I and II Synths from E-Mu were > both 8-bit samplers, and they're on more pop and rock records from > the 80s and 90s than you can shake a stick at! Are you talking about the distortion based music? I remember an ad for some line of stereos back in the day where they were saying their equipment didn't add distortion.... then next to a picture of a hard rock group, "it won't take away any either" -- Rick
[toc] | [prev] | [next] | [standalone]
| From | forther <forther@gmail.com> |
|---|---|
| Date | 2015-09-07 11:26 -0700 |
| Message-ID | <6563a2bd-5f89-4698-b9dc-bf8a6708e427@googlegroups.com> |
| In reply to | #41675 |
On Wednesday, September 2, 2015 at 3:03:35 PM UTC-7, Mux wrote: > How about audio synthesis? Given the shear amount of nodes you should be able to generate waveforms pretty easily. Each node / group of nodes could be configured as a simple / complex generator, maybe similar to FM or otherwise just simple square / sine / etc. waveforms. > > Given that you have on-chip DAC's it could be a really nifty synth.. Adding a software UART and adding some level-converters and an amp you could have a pretty decent audio device :-) > > -Y https://docs.google.com/presentation/d/1pgamdRQnmXLCIVCCPNvfiGBjXVrsa9WmyvRphCRtgaE/edit?usp=sharing
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 15:15 -0400 |
| Message-ID | <ms7hor$orr$1@dont-email.me> |
| In reply to | #41660 |
On 9/2/2015 1:57 PM, Mux wrote: > A pipelined Mandelbrot :-) > > Not really a real-world application but something I'd love to write. > With an external oscillator for frequency stability, you should be > able to dedicated two nodes for display timing, another one control > and one (or more) acting as a fifo. The remaining nodes each > calculate one iteration of a mandelbrot set. Each node would take the > result from the previous one, perform an iteration and pass on the > result to the next one until it ends up in the fifo. You'd be able to > fill / catch-up during hblank and vblank.. > > Not a real-world example but it's something I'd want to do if I had a > GA144 :-) Here's one that is feasible. Using the built in DACs a multichannel signal generator can be built. I studied the noise issue a while back and for many apps phase truncation as is commonly implemented is the limiting factor in noise generation as it produces close in spurs to the carrier which can not be filtered. The solution is to *not* use phase truncation. Rather than truncate the phase, preserve enough bits to properly represent the desired SNR and use something other than a straight table lookup to translate the phase to the sine signal. The 18 bit word size in the GA144 is enough to get a very high SNR for a full scale signal. I don't recall how fast the DACs are in the GA144, but I believe they are only 9 bits and require dithering to improve the resolution. This means the effective sample rate would be greatly lowered. So I'm not sure what frequency range could be accommodated with 16 to 18 bit resolutions. So in the end, this may only be an interesting exercise. It is exactly this sort of experimentation that a typical MCU provider would have done in house to show the capabilities of their devices. I'm surprised there is not a general purpose library of DAC/ADC drivers to demonstrate the capabilities of the GA144. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | forther <forther@gmail.com> |
|---|---|
| Date | 2015-09-07 11:21 -0700 |
| Message-ID | <66516ea3-bbac-4f22-a974-7912795e8d0f@googlegroups.com> |
| In reply to | #41631 |
On Monday, August 31, 2015 at 7:08:37 PM UTC-7, Dennis Ruffer wrote: > On Monday, August 31, 2015 at 12:20:21 AM UTC-7, dunno wrote: > > Can anyone provide real-world examples? > > IntellaSys had in mind hearing aids and wireless speakers. I've also heard of video in the automotive industry (forget which company at the moment). > > Encryption and signal processing are obvious candidates. > > E.g. anything streaming, but I'm not sure it ever was faster than other technologies. > > DaR They, actually, made a working one: https://docs.google.com/presentation/d/15eouEljeZ7Wp0qUBk-FpPR2DLnqUAavRTY80EcleUmA/edit?usp=sharing
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-30 16:33 -0500 |
| Message-ID | <n3if6r$6mu$1@dont-email.me> |
| In reply to | #41821 |
On 9/7/2015 2:21 PM, forther wrote: > On Monday, August 31, 2015 at 7:08:37 PM UTC-7, Dennis Ruffer wrote: >> On Monday, August 31, 2015 at 12:20:21 AM UTC-7, dunno wrote: >>> Can anyone provide real-world examples? >> >> IntellaSys had in mind hearing aids and wireless speakers. I've also heard of video in the automotive industry (forget which company at the moment). >> >> Encryption and signal processing are obvious candidates. >> >> E.g. anything streaming, but I'm not sure it ever was faster than other technologies. >> >> DaR > > They, actually, made a working one: https://docs.google.com/presentation/d/15eouEljeZ7Wp0qUBk-FpPR2DLnqUAavRTY80EcleUmA/edit?usp=sharing I just saw this post because someone resurrected the thread. Odd little presentation. I had the impression the hearing aid was a special algorithm that did something totally different from typical hearing aid equalizers. I'm not sure what that would be from looking at this presentation. They clearly show a set of bandpass filters running through a set of AGC before being recombined into the output. So I'm not clear on what this is doing that others don't. More importantly they have always talked about how this design was low power while running the design on a TI DSP used the entire device or even two using huge amounts of power. But it appears the code is doing fixed point arithmetic which is compared to a TI floating point processor, in fact, the type designed for a cell base station where power is no problem! So clearly they are misfitting the design to hardware inappropriate for the job then comparing that to a chip which is much better suited to the algorithm. I wonder how this algorithm would perform on more appropriate? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | forther <forther@gmail.com> |
|---|---|
| Date | 2015-12-03 12:12 -0800 |
| Message-ID | <a9c5cd55-7b78-495b-8aca-affb6117a92d@googlegroups.com> |
| In reply to | #43985 |
On Monday, November 30, 2015 at 1:33:32 PM UTC-8, rickman wrote: > On 9/7/2015 2:21 PM, forther wrote: > > On Monday, August 31, 2015 at 7:08:37 PM UTC-7, Dennis Ruffer wrote: > >> On Monday, August 31, 2015 at 12:20:21 AM UTC-7, dunno wrote: > >>> Can anyone provide real-world examples? > >> > >> IntellaSys had in mind hearing aids and wireless speakers. I've also heard of video in the automotive industry (forget which company at the moment). > >> > >> Encryption and signal processing are obvious candidates. > >> > >> E.g. anything streaming, but I'm not sure it ever was faster than other technologies. > >> > >> DaR > > > > They, actually, made a working one: https://docs.google.com/presentation/d/15eouEljeZ7Wp0qUBk-FpPR2DLnqUAavRTY80EcleUmA/edit?usp=sharing > > I just saw this post because someone resurrected the thread. > > Odd little presentation. I had the impression the hearing aid was a > special algorithm that did something totally different from typical > hearing aid equalizers. I'm not sure what that would be from looking at > this presentation. They clearly show a set of bandpass filters running > through a set of AGC before being recombined into the output. So I'm > not clear on what this is doing that others don't. > > More importantly they have always talked about how this design was low > power while running the design on a TI DSP used the entire device or > even two using huge amounts of power. But it appears the code is doing > fixed point arithmetic which is compared to a TI floating point > processor, in fact, the type designed for a cell base station where > power is no problem! So clearly they are misfitting the design to > hardware inappropriate for the job then comparing that to a chip which > is much better suited to the algorithm. > > I wonder how this algorithm would perform on more appropriate? > > -- > > Rick By then TMS320C67x was only DSP able to perform C implementation of the algorithm in real time.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-12-03 16:10 -0500 |
| Message-ID | <n3qavu$kn3$1@dont-email.me> |
| In reply to | #44056 |
On 12/3/2015 3:12 PM, forther wrote: > On Monday, November 30, 2015 at 1:33:32 PM UTC-8, rickman wrote: >> On 9/7/2015 2:21 PM, forther wrote: >>> On Monday, August 31, 2015 at 7:08:37 PM UTC-7, Dennis Ruffer wrote: >>>> On Monday, August 31, 2015 at 12:20:21 AM UTC-7, dunno wrote: >>>>> Can anyone provide real-world examples? >>>> >>>> IntellaSys had in mind hearing aids and wireless speakers. I've also heard of video in the automotive industry (forget which company at the moment). >>>> >>>> Encryption and signal processing are obvious candidates. >>>> >>>> E.g. anything streaming, but I'm not sure it ever was faster than other technologies. >>>> >>>> DaR >>> >>> They, actually, made a working one: https://docs.google.com/presentation/d/15eouEljeZ7Wp0qUBk-FpPR2DLnqUAavRTY80EcleUmA/edit?usp=sharing >> >> I just saw this post because someone resurrected the thread. >> >> Odd little presentation. I had the impression the hearing aid was a >> special algorithm that did something totally different from typical >> hearing aid equalizers. I'm not sure what that would be from looking at >> this presentation. They clearly show a set of bandpass filters running >> through a set of AGC before being recombined into the output. So I'm >> not clear on what this is doing that others don't. >> >> More importantly they have always talked about how this design was low >> power while running the design on a TI DSP used the entire device or >> even two using huge amounts of power. But it appears the code is doing >> fixed point arithmetic which is compared to a TI floating point >> processor, in fact, the type designed for a cell base station where >> power is no problem! So clearly they are misfitting the design to >> hardware inappropriate for the job then comparing that to a chip which >> is much better suited to the algorithm. >> >> I wonder how this algorithm would perform on more appropriate? >> >> -- >> >> Rick > > By then TMS320C67x was only DSP able to perform C implementation of the algorithm in real time. Unlikely. The C67x is a floating point device. They have fixed point devices with higher throughputs and the task could have been segmented into smaller modules to be implemented on the *very* much lower power devices available. The very idea that you *have* to use a battle ship as your point of comparison is absurd. Also, why did it have to be programmable in C? I don't think the GA144 is C programmable. That is my point. This is a *very* lopsided comparison and not at all realistic. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web