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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| Date | 2015-09-02 12:10 -0700 |
| Message-ID | <7ba24fb5-b57f-49c2-8388-957d54db5d58@googlegroups.com> |
| In reply to | #41625 |
On Monday, August 31, 2015 at 12:20:21 AM UTC-7, dunno wrote: > After reading documentation on GA144 I don't know but it sure is darn pretty. :^)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2015-09-03 01:27 -0700 |
| Message-ID | <68658d57-155b-42d2-a293-33ac845d7e4d@googlegroups.com> |
| In reply to | #41625 |
Hi guys Why not buy an EvalBoard and find out yourself what the GA144 is capable of doing?
[toc] | [prev] | [next] | [standalone]
| From | Syd Rumpo <usenet@nononono.co.uk> |
|---|---|
| Date | 2015-09-03 13:32 +0100 |
| Message-ID | <ms9ehn$s78$1@dont-email.me> |
| In reply to | #41692 |
On 03/09/2015 09:27, Stefan Mauerhofer wrote: > Hi guys > > Why not buy an EvalBoard and find out yourself what the GA144 is capable of doing? > Because I'm not independently wealthy and I need to eat. Cheers -- Syd
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-03 11:32 -0400 |
| Message-ID | <ms9p2b$8t0$1@dont-email.me> |
| In reply to | #41695 |
On 9/3/2015 8:32 AM, Syd Rumpo wrote: > On 03/09/2015 09:27, Stefan Mauerhofer wrote: >> Hi guys >> >> Why not buy an EvalBoard and find out yourself what the GA144 is >> capable of doing? >> > Because I'm not independently wealthy and I need to eat. That is what I was told by GA when I was trying to push the timing of the parallel I/O for an SDRAM interface. I asked for detailed timing info just as you would need for any memory interface. It was suggested that I should build it and see how fast it ran. lol Not only might that be a big waste of my time, it wouldn't tell me how fast it would run on any GA144 other than the one I was testing it on. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2015-09-03 18:57 +0200 |
| Message-ID | <94781700948432@frunobulax.edu> |
| In reply to | #41625 |
Bernd Paysan <bernd.paysan@gmx.de> writes Re: GA144 use cases > Anton Ertl wrote: >> And the same goes for paragraphs. OTOH, TeX is so fast on modern CPUs >> that one can really say that paralellizing it would not enhance it. >> Also, parallelizing it would require quite a bit of effort. The NGSPICE manual is 650 pages and takes more than two minutes to process. When maintaining the manual (small, infrequent edits) that is too long and quality suffers (one doesn't do a single edit, or one doesn't want to check the outcome). > Well, TeX is written in an "unmaintainable" programming language, c-web. > Let's go with the paragraphs: TeX tries to render the paragraph with several > different attempts, and chooses the best-"looking", with a metric of what is > "best". That is fairly easy to parallelize, you just run all the trials in > parallel, and then collect the results. The one with the lowest badness > wins, and the others get deleted. That approach would suffer unbearably from Amdahl's law, doesn't it? > 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. Why not have a writable instruction set for these kind of problems? > 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. I am an ngspice maintainer and see the same thing there. The actual device code that is executed per time step is almost always so small that e.g. openmp does not work. Although all cores run at 100%, the simulation takes 20% longer. It works a little bit for some transistor models that are extremely lengthy, but there Amdahl's law cuts in again when all other processing is included. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-09-03 23:58 +0200 |
| Message-ID | <msafnk$9sk$1@dont-email.me> |
| In reply to | #41700 |
Marcel Hendrix wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes Re: GA144 use cases > >> Anton Ertl wrote: >>> And the same goes for paragraphs. OTOH, TeX is so fast on modern CPUs >>> that one can really say that paralellizing it would not enhance it. >>> Also, parallelizing it would require quite a bit of effort. > > The NGSPICE manual is 650 pages and takes more than two minutes to > process. When maintaining the manual (small, infrequent edits) that is too > long and quality suffers (one doesn't do a single edit, or one doesn't > want to check the outcome). That gives an estimate about how long it takes per paragraph: Let's assume 10 paragraphs per page (some of them small, some larger), you maybe have 6000 paragraphs in your document. Makes 20ms per paragraph. That's in the ballpark where the microsecond IPC is a non-issue, and where algorithmic improvements are probably an even lower-hanging fruit. > That approach would suffer unbearably from Amdahl's law, doesn't it? When it's really 20ms per paragraph, and maybe 2ms per variant, no. >> 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. > > Why not have a writable instruction set for these kind of problems? If Intel puts some FPGA stuff into each core (after all, they bought Altera), and connects the FPGAs together, that would solve part of the job. The other part, keeping some contexts in the core's large register file, but not executing the instructons and wait for wakeup, needs to go deeper in the details. However, for the crypto stuff, I'd probably rather use the FPGA to implement the crypto primitive (Keccak) directly, that's using a few thousand LEs with a potentially higher speedup than parallelization. >> 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. > > I am an ngspice maintainer and see the same thing there. The actual device > code that is executed per time step is almost always so small that e.g. > openmp does not work. Although all cores run at 100%, the simulation takes > 20% longer. It works a little bit for some transistor models that are > extremely lengthy, but there Amdahl's law cuts in again when all other > processing is included. Yes, that's why we must reduce the communication overhead. Amdahl's law is there, because communication between threads is way too expensive. -- 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-04 07:52 +0000 |
| Message-ID | <2015Sep4.095253@mips.complang.tuwien.ac.at> |
| In reply to | #41700 |
mhx@iae.nl (Marcel Hendrix) writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes Re: GA144 use cases
>> Well, TeX is written in an "unmaintainable" programming language, c-web.
>> Let's go with the paragraphs: TeX tries to render the paragraph with several
>> different attempts, and chooses the best-"looking", with a metric of what is
>> "best". That is fairly easy to parallelize, you just run all the trials in
>> parallel, and then collect the results. The one with the lowest badness
>> wins, and the others get deleted.
>
>That approach would suffer unbearably from Amdahl's law, doesn't it?
Does it? What is the sequential component? Probably input parsing.
Although even for that you do not have to parse everything before
formatting the first paragraph. How much is the time spent in input
parsing?
I think it might be a lot for those inputs that take a lot of time (at
least I have a TeX source that collects data from several files and
then produces a document from that, and that takes a lot more time
than the Gforth manual which produces a document that has six times as
many pages. Looking at your numbers, the ngspice manual might also be
such a case. I guess one would need other speedup techniques for that
(and parallelizing would probably not be the one to try first).
- 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 | Waldek Hebisch <hebisch@antispam.uni.wroc.pl> |
|---|---|
| Date | 2015-09-05 16:32 +0000 |
| Message-ID | <msf5e2$fli$1@z-news.wcss.wroc.pl> |
| In reply to | #41700 |
Marcel Hendrix <mhx@iae.nl> wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes Re: GA144 use cases
>
> > Anton Ertl wrote:
> >> And the same goes for paragraphs. OTOH, TeX is so fast on modern CPUs
> >> that one can really say that paralellizing it would not enhance it.
> >> Also, parallelizing it would require quite a bit of effort.
>
> The NGSPICE manual is 650 pages and takes more than two minutes to process.
> When maintaining the manual (small, infrequent edits) that is too long and
> quality suffers (one doesn't do a single edit, or one doesn't want to check
> the outcome).
That is unusually long time. For example the TeX book has 535
pages and takes 0.727s to process on my machine. So 650 pages
plain TeX document should take less than a second. I do not
have so large LaTeX document. But my 44 pages document takes
of order of 0.2 seconds, so I would expect about 3 seconds
for 650 pages LaTeX. Main difference between TeX and LaTeX
seem to be that LaTeX defines several complex macros and
macro processing starts to dominate the runtime. Macro
processing in TeX depends on continously redefining macros
and due to this is very hard to do in parallel.
One guess is that long typesetting times for NGSPICE manual
are due to graphics: there are popular packages which
abuse TeX typesetting engine to simulate graphics engine.
Typically one wants several pictures and each picture
have a priori known bounding box, so in principle all
pictures could be processed in parallel (and parallel
to the main document). But due to the way picutures
are presented TeX does not know that this is not a usual
unparallelizabel case.
You may also get slowdown due to file searches: modern
macro packages are split into a lot of files spread over
a lot of directories. In number of files (and especially
directories) in question exceed size of kernel caches
there is thrashing and huge slowdown. In such case
parallel execution does not help at all. Bigger kernel
caches or better organization of TeX distribution
should help.
--
Waldek Hebisch
hebisch@antispam.uni.wroc.pl
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-09-05 10:52 -0700 |
| Message-ID | <eb036774-b58b-4c0d-9352-47bc9a501cbe@googlegroups.com> |
| In reply to | #41768 |
On Saturday, September 5, 2015 at 6:32:03 PM UTC+2, Waldek Hebisch wrote: > Marcel Hendrix <mhx@iae.nl> wrote: [..] > > The NGSPICE manual is 650 pages and takes more than two minutes to process. > > When maintaining the manual (small, infrequent edits) that is too long and > > quality suffers (one doesn't do a single edit, or one doesn't want to check > > the outcome). > > That is unusually long time. For example the TeX book has 535 > pages and takes 0.727s to process on my machine. So 650 pages > plain TeX document should take less than a second. I do not > have so large LaTeX document. But my 44 pages document takes > of order of 0.2 seconds, so I would expect about 3 seconds > for 650 pages LaTeX. Main difference between TeX and LaTeX > seem to be that LaTeX defines several complex macros and > macro processing starts to dominate the runtime. Macro > processing in TeX depends on continously redefining macros > and due to this is very hard to do in parallel. [..] Well, actually I use LyX, and it is not two minutes but 84 seconds on my noise-tuned PC (it's probably 22 seconds in hi-perf mode). The time is for LyX start-up and one rebuild. I didn't change anything in the text, so maybe there is caching going on. There are maybe 8 pictures in the manual and of course some formulas. ( http://sourceforge.net/p/ngspice/ngspice-manuals/ci/master/tree/ ) FORTH> TIMER-RESET cr s" manual.lyx" SYSTEM .ELAPSED 84.353 seconds elapsed. ok I don't know LaTeX / LyX and what/how it is doing, but 0.727s for 535 pages ... Where did you buy that workstation :-) -marcel
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-09-05 22:11 +0200 |
| Message-ID | <msfi5j$ej7$2@dont-email.me> |
| In reply to | #41773 |
mhx@iae.nl wrote: > I don't know LaTeX / LyX and what/how it is doing, but > 0.727s for 535 pages ... Where did you buy that > workstation :-) Sounds a bit fast. Gforth's texi manual, just one run, takes 1,329s user time here with texi2dvi (3GHz Core i7). That's almost 300 pages. -- 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:18 +0000 |
| Message-ID | <2015Sep6.161808@mips.complang.tuwien.ac.at> |
| In reply to | #41780 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>mhx@iae.nl wrote:
>
>> I don't know LaTeX / LyX and what/how it is doing, but
>> 0.727s for 535 pages ... Where did you buy that
>> workstation :-)
>
>Sounds a bit fast. Gforth's texi manual, just one run, takes 1,329s user
>time here with texi2dvi (3GHz Core i7). That's almost 300 pages.
Hmm, it's
1.181u 0.354s 1.430r 107.35%
on my 1.9GHz Core i3-3227U laptop.
On our shiny new Core i7-4790K box (not overclocked), it's
0.868u 0.128s 0.989r 100.00%
I am a bit disappointed at the low speedup from the 4790K, which
should be at least twice as fast. Maybe different software versions.
Anyway, plenty fast. makeinfo is a bigger problem than TeX.
- 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-07 07:49 +0000 |
| Message-ID | <2015Sep7.094937@mips.complang.tuwien.ac.at> |
| In reply to | #41790 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>mhx@iae.nl wrote:
>>
>>> I don't know LaTeX / LyX and what/how it is doing, but
>>> 0.727s for 535 pages ... Where did you buy that
>>> workstation :-)
>>
>>Sounds a bit fast. Gforth's texi manual, just one run, takes 1,329s user
>>time here with texi2dvi (3GHz Core i7). That's almost 300 pages.
>
>Hmm, it's
>
>1.181u 0.354s 1.430r 107.35%
>
>on my 1.9GHz Core i3-3227U laptop.
>
>On our shiny new Core i7-4790K box (not overclocked), it's
>
>0.868u 0.128s 0.989r 100.00%
That's wrong, these numbers probably came from a 2.8GHz Xeon X3460
(Lynnfield/Nehalem).
The Core i7-4790K takes:
real 0m0.479s
user 0m0.404s
sys 0m0.004s
>Anyway, plenty fast. makeinfo is a bigger problem than TeX.
Still valid:-)
- 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 | Waldek Hebisch <hebisch@math.uni.wroc.pl> |
|---|---|
| Date | 2015-09-05 23:42 +0000 |
| Message-ID | <msfulm$2g8$1@z-news.wcss.wroc.pl> |
| In reply to | #41773 |
mhx@iae.nl wrote:
> On Saturday, September 5, 2015 at 6:32:03 PM UTC+2, Waldek Hebisch wrote:
> > Marcel Hendrix <mhx@iae.nl> wrote:
> [..]
> > > The NGSPICE manual is 650 pages and takes more than two minutes to process.
> > > When maintaining the manual (small, infrequent edits) that is too long and
> > > quality suffers (one doesn't do a single edit, or one doesn't want to check
> > > the outcome).
> >
> > That is unusually long time. For example the TeX book has 535
> > pages and takes 0.727s to process on my machine. So 650 pages
> > plain TeX document should take less than a second. I do not
> > have so large LaTeX document. But my 44 pages document takes
> > of order of 0.2 seconds, so I would expect about 3 seconds
> > for 650 pages LaTeX. Main difference between TeX and LaTeX
> > seem to be that LaTeX defines several complex macros and
> > macro processing starts to dominate the runtime. Macro
> > processing in TeX depends on continously redefining macros
> > and due to this is very hard to do in parallel.
> [..]
>
> Well, actually I use LyX, and it is not two minutes
> but 84 seconds on my noise-tuned PC (it's probably 22 seconds
> in hi-perf mode). The time is for LyX start-up and one rebuild.
> I didn't change anything in the text, so maybe there is caching
> going on. There are maybe 8 pictures in the manual and of course
> some formulas.
> ( http://sourceforge.net/p/ngspice/ngspice-manuals/ci/master/tree/ )
>
> FORTH> TIMER-RESET cr s" manual.lyx" SYSTEM .ELAPSED
> 84.353 seconds elapsed. ok
>
> I don't know LaTeX / LyX and what/how it is doing, but
> 0.727s for 535 pages ... Where did you buy that
> workstation :-)
>
> -marcel
The timings are on 2.4 GHz Core 2. This is quad core machine.
AFAIK TeX uses only one core, but there is some possiblity
for parallel execution of TeX and OS. Note that the 535
pages are plain TeX. IME LaTeX is usually slower, freqently
3 to 4 times slower (I mean single run of LaTeX).
Apparently LyX introduces substantial additional overhead.
--
Waldek Hebisch
hebisch@math.uni.wroc.pl
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-09-05 17:25 -0700 |
| Message-ID | <87y4gkz94o.fsf@jester.gateway.pace.com> |
| In reply to | #41784 |
Waldek Hebisch <hebisch@math.uni.wroc.pl> writes: > Note that the 535 pages are plain TeX. IME LaTeX is usually slower, > freqently 3 to 4 times slower Hmm, that might also explain the gforth manual (and the emacs manual which I'm more used to) formatting comparatively slowly. They're both in Texinfo, which is a quite complicated TeX macro package that makes TeX look like a predecessor of Scribe (another markup-based formatter) with roots in MIT history. So Texinfo may also slow things down compared to plain TeX. Formatting big documents in TeX used to be an inconveniently slow operation like a big compilation, but on today's hardware TeX's speed is usually not a significant problem.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2015-09-07 03:18 -0700 |
| Message-ID | <e905438b-6503-42bf-8461-19bb710145d1@googlegroups.com> |
| In reply to | #41625 |
I suggest we return to our topic, the GA144. (Please open another thread for discussing the speed of TeX interpreters). The GA144 has some unique features that distinguishes it from other devices. First it is asynchronous. It has no clock or any sort of time reference. This makes it a little bit more difficult to use the chip in applications that requires a time base, like communications. However a couple of nodes can start and drive a crystal oscillator. It can even stop the crystal from oscillating when not needed. This makes it uniquely suitable for application where low power is a must. E.g. imagine a data acquisition station where the data is transmitted only once a day. The communication crystal needs to run only for a few minutes during a day. I don't know any other device that can stop and restart a crystal quartz.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-09-07 03:31 -0700 |
| Message-ID | <943c2b33-d9a0-4b2a-a122-5c7d54855440@googlegroups.com> |
| In reply to | #41811 |
> However a couple of nodes can start and drive a crystal oscillator. It can even stop the crystal from oscillating when not needed. This makes it uniquely suitable for application where low power is a must. E.g. imagine a data acquisition station where the data is transmitted only once a day. The communication crystal needs to run only for a few minutes during a day. > > I don't know any other device that can stop and restart a crystal quartz. Many cortex-m devices claim a sleeping sub-microampere power budget these days, including an rtc for precise waking times. I don't know if they stop the crystals or not and I don't care. Give me power figures so I can compare the things.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-07 15:06 -0400 |
| Message-ID | <mskn52$php$1@dont-email.me> |
| In reply to | #41812 |
On 9/7/2015 6:31 AM, Raimond Dragomir wrote: >> However a couple of nodes can start and drive a crystal oscillator. It can even stop the crystal from oscillating when not needed. This makes it uniquely suitable for application where low power is a must. E.g. imagine a data acquisition station where the data is transmitted only once a day. The communication crystal needs to run only for a few minutes during a day. >> >> I don't know any other device that can stop and restart a crystal quartz. > > Many cortex-m devices claim a sleeping sub-microampere power budget these days, including an rtc for precise waking times. I don't know if they stop the crystals or not and I don't care. Give me power figures so I can compare the things. Yes, crystals are stopped and started on any processor that is shooting for really low power levels while sleeping. They either use a second crystal, 32.768 kHz or use an internal RC slow clock to wake up by. The high speed crystal clock takes some milliseconds to restart and a low speed crystal clock takes a significant part of a second to restart and stabilize. I doubt anything done with the GA144 will significantly improve on this. In fact, they never got a general purpose high speed crystal clock to work. I think Chuck punted and used a resonator. The initial accuracy of the crystal stimulus is too critical for the GA144 tolerances. Did anyone else explore the world of crystal oscillators with the GA144? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2015-09-08 21:41 -0700 |
| Message-ID | <1430c824-aede-406e-942d-66ea2cdb95a7@googlegroups.com> |
| In reply to | #41825 |
Am Montag, 7. September 2015 21:06:58 UTC+2 schrieb rickman: > On 9/7/2015 6:31 AM, Raimond Dragomir wrote: > >> However a couple of nodes can start and drive a crystal oscillator. It can even stop the crystal from oscillating when not needed. This makes it uniquely suitable for application where low power is a must. E.g. imagine a data acquisition station where the data is transmitted only once a day. The communication crystal needs to run only for a few minutes during a day. > >> > >> I don't know any other device that can stop and restart a crystal quartz. > > > > Many cortex-m devices claim a sleeping sub-microampere power budget these days, including an rtc for precise waking times. I don't know if they stop the crystals or not and I don't care. Give me power figures so I can compare the things. > > Yes, crystals are stopped and started on any processor that is shooting > for really low power levels while sleeping. They either use a second > crystal, 32.768 kHz or use an internal RC slow clock to wake up by. The > high speed crystal clock takes some milliseconds to restart and a low > speed crystal clock takes a significant part of a second to restart and > stabilize. I doubt anything done with the GA144 will significantly > improve on this. In fact, they never got a general purpose high speed > crystal clock to work. I think Chuck punted and used a resonator. The > initial accuracy of the crystal stimulus is too critical for the GA144 > tolerances. > > Did anyone else explore the world of crystal oscillators with the GA144? > > -- > > Rick Hi Rick Thanks for the info about other low power devices. It seems quite obvious to shut down the high speed clock and run a low speed clock to monitor the wake-up condition. Regarding your question: Yes, I did. I could start and keep running crystals up to 16 MHz without any external electronics or manipulating the voltage or temperature.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-09 02:54 -0400 |
| Message-ID | <msokvd$p51$2@dont-email.me> |
| In reply to | #41879 |
On 9/9/2015 12:41 AM, Stefan Mauerhofer wrote: > Am Montag, 7. September 2015 21:06:58 UTC+2 schrieb rickman: >> >> Did anyone else explore the world of crystal oscillators with the GA144? >> >> -- >> >> Rick > > Hi Rick > > Thanks for the info about other low power devices. It seems quite obvious to shut down the high speed clock and run a low speed clock to monitor the wake-up condition. > > Regarding your question: Yes, I did. I could start and keep running crystals up to 16 MHz without any external electronics or manipulating the voltage or temperature. Did you ever publish your code? Chuck was not able to start a 10 MHz crystal oscillator due to the lack of adequate resolution in his timing method, the software loop. How do you get yours going? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Stefan Mauerhofer <smauerhofer@androsoft.ch> |
|---|---|
| Date | 2015-09-09 03:02 -0700 |
| Message-ID | <b309492e-f09f-47f6-b927-96818dd2bce4@googlegroups.com> |
| In reply to | #41881 |
Am Mittwoch, 9. September 2015 08:54:21 UTC+2 schrieb rickman: > On 9/9/2015 12:41 AM, Stefan Mauerhofer wrote: > > Am Montag, 7. September 2015 21:06:58 UTC+2 schrieb rickman: > >> > >> Did anyone else explore the world of crystal oscillators with the GA144? > >> > >> -- > >> > >> Rick > > > > Hi Rick > > > > Thanks for the info about other low power devices. It seems quite obvious to shut down the high speed clock and run a low speed clock to monitor the wake-up condition. > > > > Regarding your question: Yes, I did. I could start and keep running crystals up to 16 MHz without any external electronics or manipulating the voltage or temperature. > > Did you ever publish your code? Chuck was not able to start a 10 MHz > crystal oscillator due to the lack of adequate resolution in his timing > method, the software loop. How do you get yours going? > > -- > > Rick Hi Rick I am planning to publish the code this year. The problem is that currently I have other priorities. You are right, the software loop resolution is not sufficient. By spreading the code & data over 4 nodes I could increase the average resolution of the software loop. I am using 1 node to hold 64 software loop counter. 1 node is calculating the in-between values with a kind of Bresenham algorithm and write them to the data node. 1 node is controlling the search algorithm and the last node is controlling the I/O pin, sense the feedback from the crystal and report the result back. I am not happy with the result yet, because I had a 2 MHz crystal, which would not run with my program. So I need some more investigation on what is happening with the crystals. I was astonished, that I could start and lock on a 16 MHz crystal. I tried about 20 different crystals from 32 kHz to 18 MHz. I could excite every crystal (even the 2 MHz) up to 16 MHz. Beyond 16 MHz the F18A node was to slow to create a stable frequency with a software loop. - Stefan
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web