WIth the OpenMP patch I put together last night, adding two million-element
vectors went from about 45ms without OpenMP to about 32ms with OpenMP.
That's evidence that OpenMP is doing *something*, even though the speedup
is nowhere near commensurate with the number of cores (8 on this machine).
I
Any error thrown from a quadSYL setter triggers causes a heap error and
backtrace.
For example:
⎕syl[5;2]←1
INDEX ERROR
⎕SYL[5;2]←1
^^
*** Error in `/usr/local/bin/apl': double free or corruption (fasttop):
0x008c66f0 ***
=== Backtrace: =
/lib64/libc.
Are there any tools or techniques to assist in the generation of test
cases? The use of specific Unicode characters for pattern-matching
seems a bit fussy...
--
"The secret to creativity is knowing how to hide your sources."
Albert Einstein
http://soundcloud.com/davidlamkins
http://reverbnat
There is also the option of adding another numeric type: bignum. This would
probably take a lot of work though.
On 12 Mar 2014 08:47, "Frederick H. Pitts" wrote:
> Hello Kacper,
>
> Thanks for the explanation.
>
> I hope GnuAPL can be fixed so that accurate integer arithmetic can
On 2014-03-11 17:29:08, Frederick H. Pitts wrote:
> If one executes
>
> i ← 0
> 63 1 ⍴ { ⍵ , i ← ¯1 + 2 × i + 1 }¨ 1 + ⍳ 63
>
> one should get a 2-column table of bit count and corresponding maximum
> positive representable integer (assuming high order bit is a sign bit).
> Th
Hello Kacper,
Thanks for the explanation.
I hope GnuAPL can be fixed so that accurate integer arithmetic can be
performed on integers in the 54 to 63 bit range. If not, ⎕SYL should be
changed to report the largest and smallest integers corresponding to 53
bits so that users do no
Gentle people,
If one executes
i ← 0
63 1 ⍴ { ⍵ , i ← ¯1 + 2 × i + 1 }¨ 1 + ⍳ 63
one should get a 2-column table of bit count and corresponding maximum
positive representable integer (assuming high order bit is a sign bit).
The maximum integer should be odd. Running the
I finally could get GNU APL work as a REPL inside Vim!
See: http://www.vim.org/scripts/script.php?script_id=4887
(for unix/linux only; uses FIFO and external shell commands: "tail", "gnu apl",
one subshell)
tiny bug: the subshell is still alive after leaving Vim; I have to asked some
shell-gur
On 2014-03-11, at 4:30 PM, Peter Teeson wrote:
> Mac Pro Desktop dual quad core CPU's, Mountain Lion OS X 10.8.5
>
> I DL'd the 2014-01-13 APL 1.2 tar.gz and did ./configure.
> Blew up because of
> configure:2767: checking for gcc
> configure:2797: result: no
> configure:2860: checking for cc
> c
Mac Pro Desktop dual quad core CPU's, Mountain Lion OS X 10.8.5
I DL'd the 2014-01-13 APL 1.2 tar.gz and did ./configure.
Blew up because of
configure:2767: checking for gcc
configure:2797: result: no
configure:2860: checking for cc
configure:2907: result: no
configure:2963: checking for cl.exe
co
Gentle people,
And
9223372036854775807 + ¯9223372036854775808
0
is not correct either.
Regards,
Fred
On Tue, 2014-03-11 at 23:32 +0800, Elias Mårtenson wrote:
> Running ⎕SYL shows the following:
>
>
> largest integer 9223372036854775807
>
>
>
Running ⎕SYL shows the following:
largest integer 9223372036854775807
Trying to subtract one from this value gives a weird result:
*9223372036854775807-1*
¯9223372036854775808
Regards,
Elias
Oh and one more thing: Have you given any thought to my comments re. the
coalescing of certain functions to reduce thread dispatch effort? (also,
add some more functions to the no-copy optimisation?)
Regards,
Elias
On 11 March 2014 23:22, Elias Mårtenson wrote:
> I agree. I just wanted to poin
Thanks, Jürgen.
I'll try to work up some test cases this week.
In my quick scan of the OpenMP document yesterday, I noted that there
are different strategies for assigning work to threads. As with just
about everything else in OpenMP, the strategy is configurable.
My initial thought for putting
I agree. I just wanted to point out that without a runtime option,
delivering binary versions will be hard, forcing the package maintainers to
choose a default that will surely be wrong for the majority of users.
That said, being able to choose a compile-time value is good too.
Regards,
Elias
O
Hi,
we could do it similar to the LOG macro where you can choose between
more efficient compile-time settings and less efficient run-time settings.
It is important that we do these things properly from the outset to avoid
too many changes later on.
/// Jürgen
On 03/11/2014 04:10 PM, Elias Mår
May I suggest that being able to choose the number of cores at runtime
should actually be the default. Remember that most Linux distributions will
not compile the source on the local machine and instead distributes
binaries.
Having some #ifdefs would be good, and having runtime user-selected (or
a
Hi David,
looks good! Some comments, though.
1 .you could adapt src/testcases/Performance.pt with some longer
skalar functions in order to get some performance figures. You can start
it like this:
./apl -T testcases/Performance.pt
2. I believe we should not bother the user with specifying
p
Hi Thomas,
I fixed the infinite lopp when the interpreter has no input. It now
stops after
10 attempts within short time (to distinguish that from ^D typed by the
user).
Deamon mode (-d) simply fork()s the process of the APL interpreter with the
parent process exit()ing and the child continui
19 matches
Mail list logo
