At 21:20 -0400 2007/05/20, Terrence Brannon wrote:
On 5/20/07, Terrence Brannon <[EMAIL PROTECTED]> wrote:
On 5/20/07, Joey K Tuttle <[EMAIL PROTECTED]> wrote:
The real advantage is terse programs that subsume
detail much more than most programming languages.
Well, if you take a look at most entries for this benchmark, they were
much simpler than the J code.
http://shootout.alioth.debian.org/debian/benchmark.php?test=sumcol&lang=all
But maybe I can change that with jmf.
Actually, I cannot. The file coming in on stdin, so I can't really use
jmf. When they run it, they are simply going to cat the file and pipe
it to a program which has to take it and give the right results.
----------------------------------------------------------------------
And it is your contention that most entries were much
simpler than the j code (requiring stdin) you are saying
that is true of the one I presented earlier? Namely -
$ cat cs.ijs
echo +/ 0&". ;._2 stdin''
$ time cat sumcol-input.txt | ja cs.ijs
500
real 0m0.192s
user 0m0.047s
sys 0m0.060s
Not to argue, but I think the one line
echo +/ 0&". ;._2 stdin''
Is pretty simple/short. The gzip of cs.ijs is 53 bytes
while the uncompressed file is 26...
But I think there are other issues with the shootout, I
had forgotten that I looked at "the shootout game" earlier
and decided that like most benchmarks, it is indeed just a
game - and one of little practical use. As you say when -
At 21:19 -0400 2007/05/20, Terrence Brannon wrote:
On 5/20/07, Joey K Tuttle <[EMAIL PROTECTED]> wrote:
The thing is that benchmarks which read a line at a time as in
the example that started your questions are just "not done that
way in j" -
yes, the shootout requirements are very rigid. They do not allow each
language to "strut its stuff" - they try to force all languages to do
things in a certain way.
In a sense, J has to read the file line-by-line as part of the mapping
process, so I suppose that counts as line-oriented.
It is an encouraging (to me) sign that while j has the
control structures similar to other languages, it is
completely lacking the fundamental behavior of read()
as used in the submissions to shootout - likewise I
applaud the absence of print() and the scalar thinking
such force people to use. I don't see much use of learning
any language if the student is prohibited from allowing
it to "strut its stuff"...
Actually mapping doesn't have to read the entire file
line-by-line as part of the mapping process. It is for
that reason that -
You
can see that j used 87 megabytes (not a big load on my 1.5G
iMac) to process the 227,944,072 byte file.
wow, that defies logic. a 227 megabyte file in an eager language only
used 87 megabytes???
Other queries against the data might use much less memory -
for the particular one shown, all lines (in this case, fixed
length records) of the file were involved, but only parts of
the lines were used. The memory used was the high water mark
that the j address space reached.
I think almost all the forum members agree that the power of
j (and before of APL) has more to do with alternative thinking
and constructs than how fast a scalar loop runs. In the case of
the phone record summary, I am more impressed that the j analysis
(try writing it in c or some such to see what the 2 lines
expand into) runs faster than the simple utility wc (which I
assume is rather tightly written c) is pretty amazing...
And finally, your first question -
Terrence,
On a lot of modern machines, that is mostly moot.
What is mostly moot and why?
And can you ignore the fact that there are text files larger than memory?
I went to a lecture several years ago at Xerox PARC where
the speaker, David Patterson of UC Berkeley, said that by
the year 2000 engineering workstations would have a gigabyte
of RAM - now if you want to enjoy videos in Vista, 4 GB is
recommended... He went on to say that 1 GB RAM was quite
interesting because it was the average size of the database
used by ATM machines in large nation wide banks.
His point was that algorithms that used to strive for minimum
memory usage were becoming a moot issue - hence my comment.
Of course, things like a DVD image etc. are indeed larger than
(current) RAM sizes and even the scandalous AOL search records
database is text larger than real memory. Still, the copy I have
has 10 files of about 225 megs each. Fun text files to experiment
with. Mapping them in j is an effective analysis tool and it is
surprisingly fast.
In any case, I hope you are enjoying the games.
- joey
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
