On Tue, May 7, 2013 at 11:36 PM, Levi Pearson wrote:
> And to take another little digression down history lane, Go's
> concurrency features such as goroutines are ultimately derived from
> early work on specifying/formally describing concurrent processes,
> namely the model of Communicating Seque
On Tue, May 7, 2013 at 6:06 PM, Dave Smith wrote:
> 1. Python programs can be "frozen" into a compiled binary so that it can run
> natively on a target OS. I've done this for Windows before. However, the
> binary is just a clever packaging of the Python interpreter with your code,
> still in P
On May 7, 2013, at 10:57 AM, Daniel Fussell wrote:
> [1.1*] I didn't know haskell could compile to multiple output forms; it
> does make learning haskell a more appealing idea. Isn't python able to
> do the same thing? I'd heard rumor that such was the case, but I'm so
> busy maintaining som
On Tue, May 7, 2013 at 10:57 AM, Daniel Fussell wrote:
> [1.1*] I didn't know haskell could compile to multiple output forms; it
> does make learning haskell a more appealing idea. Isn't python able to
> do the same thing? I'd heard rumor that such was the case, but I'm so
> busy maintaining s
On 05/05/2013 12:07 AM, Dave Smith wrote:
> On May 4, 2013, at 9:22 PM, Tod Hansmann wrote:
>
>> ...
> ...
>
>> Like Sasha says in his 5:01 MST email today, Haskell doesn't "beat" C. At
>> what?
> ...
>
> The Haskell-to-C comparison is particularly apt because both Haskell and C
> actually compi
On 5/7/13 10:53 AM, Ryan Moore wrote:
> Slant rhyme, at best.
To be fair, he didn't say they rhymed with each other...
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
On 05/04/2013 09:22 PM, Tod Hansmann wrote:
> > I didn't say it was a waste of time, I said it was asinine.
>
> Waste of time, asinine; they both rhyme.
>
Slant rhyme, at best.
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the pen
On 05/04/2013 09:22 PM, Tod Hansmann wrote:
> I didn't say it was a waste of time, I said it was asinine.
Waste of time, asinine; they both rhyme.
;-Daniel Fussell
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
On Fri, May 3, 2013 at 4:00 PM, Sasha Pachev wrote:
> Bryan:
>
> bash-4.1$ java -version
> java version "1.6.0_27"
> Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
>
OpenJDK 7 should be noticeably faster. Also, be sure to us
On May 4, Sasha Pachev wrote:
> Regarding the primitives, I agree that a skillful scripting language
> programmer can cut down the number of primitives for a good number of
> problems, but at the same time I can think of a string operation that
> would require a lot of primitives in a scripting lan
On May 4, 2013, at 9:22 PM, Tod Hansmann wrote:
> I didn't say it was a waste of time, I said it was asinine.
Oops. My mistake.
> I can learn from two kids hitting each other over a toy, but it doesn't make
> it less stupid.
You're right about that.
> I'd also point out that the excercise it
On Sat, May 4, 2013 at 5:01 PM, Sasha Pachev wrote:
> Thanks for the contribution. It was very educational. So Haskell can
> do mmap() - that's great, and you got better performance than the
> version in Perl, Python, or Java posted so far.
>
> Did you mean 0.045 s for the non-unicode version?
P
On 5/4/2013 12:26 PM, Dave Smith wrote:
> On May 4, 2013, at 12:36 AM, Tod Hansmann wrote:
>> The comparison of each execution is just asinine in the extreme.
> I don't know why so many people think this exercise has been a waste of time.
> I have learned several interesting things from it, and
Levi:
Thanks for the contribution. It was very educational. So Haskell can
do mmap() - that's great, and you got better performance than the
version in Perl, Python, or Java posted so far.
Did you mean 0.045 s for the non-unicode version?
I am still going to argue that it cannot beat C - it migh
On May 4, 2013, at 12:36 AM, Tod Hansmann wrote:
>
> The comparison of each execution is just asinine in the extreme.
I don't know why so many people think this exercise has been a waste of time. I
have learned several interesting things from it, and I really enjoyed it.
To me, programming do
On 5/4/2013 5:35 AM, Charles Curley wrote:
> On Sat, 04 May 2013 00:36:28 -0600
> Tod Hansmann wrote:
>
>> The comparison of each execution is just asinine in the extreme.
> If your goal is to start a flurry of emails, it works quite well.
>
I hear emacs is the worst editor ever! =cP
-Tod Hansm
On Sat, 04 May 2013 00:36:28 -0600
Tod Hansmann wrote:
> The comparison of each execution is just asinine in the extreme.
If your goal is to start a flurry of emails, it works quite well.
--
Charles Curley /"\ASCII Ribbon Campaign
Looking for fine software \ /Re
On 5/3/2013 11:28 PM, Levi Pearson wrote:
> It could most likely be sped up further until it was about the same
> speed as the C one, but there's not much point to expending the effort
> here.
>
>
This is, I believe, the best summation of the point I've seen in this
thread. It's not about what l
On Fri, May 3, 2013 at 4:00 PM, Sasha Pachev wrote:
> Levi - I still would like to see some code in Haskell, even if it is
> dog slow and I have to do some work to get it to run on my box. I
> programmed in Scheme for a class back in 1994 (CS 330), I do remember
> writing a program in C to help me
> Cheating a little bit, now that the C solution has been made public,
> you just win with the C solution with much smaller data sets because
> all you need to do now is compile it :-) More seriously, it can be
> quickly adapted to do other relatively simple file fixing tasks, in
> particular the o
Bryan:
bash-4.1$ java -version
java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
I tried removing the call to sb.reverse() to see what would happen. I
am not seeing much of a difference change in performance
On Thu, May 2, 2013 at 11:42 PM, Andy Bradford wrote:
> Thus said Michael Torrie on Thu, 02 May 2013 22:13:33 -0600:
>
>> Python version, coded in 1 minutes, well an extra minute to run the
>> REPL to make sure I had the slice syntax correct:
>
> Except it doesn't produce the same output:
>
> $
Thus said Michael Torrie on Thu, 02 May 2013 22:13:33 -0600:
> Python version, coded in 1 minutes, well an extra minute to run the
> REPL to make sure I had the slice syntax correct:
Except it doesn't produce the same output:
$ time ./strrev words > words.strrev
0m0.11s real 0m0.11s u
On Thu, May 2, 2013 at 11:13 PM, Joshua Marsh wrote:
> I vaguely recall something to do with private address space for MAP_PRIVATE
> and how Linux handled the memory for that. It must not be the case now
> though. I just fallocate'd a 100GB file and mmap()'ed it without issue. Has
> something cha
On Thu, May 2, 2013 at 9:35 PM, Levi Pearson wrote:
> Actually, mmap() is often the best way to deal with gigantic files, so
> long as you have sufficient address space (not physical memory, but
> bus width!) to deal with them.
I vaguely recall something to do with private address space for MAP
On Thu, May 2, 2013 at 10:23 PM, Michael Torrie wrote:
> And it turns out that it's pretty easy to generate fast math algorithms
> by emitting C code (Blast I think it is called) that can be used in a
> language like Python to great effect. In fact an awful lot of
> high-performance computing is
On Thu, May 2, 2013 at 7:25 AM, Sasha Pachev wrote:
> it must work correctly on any file that
> has lines shorter than 512 bytes. If the line is longer than that it
> can truncate the string, but must not crash.
I missed this little gem the first time. Only a programmer who has
got their brain f
On 05/02/2013 10:06 PM, Levi Pearson wrote:
> This made Fortran the default choice for matrix programming, and so a
> lot of research was put into developing good compilers, and for a long
> time they soundly trounced C compilers. The C powers that be
> eventually got around to defining standard wa
On 05/02/2013 10:51 AM, Bryan Sant wrote:
> On Thu, May 2, 2013 at 10:38 AM, Steve Alligood wrote:
>
>> As for java: no clue. I suspect in this task it would not do as well as
>> even the perl, as the JIT won't shine until it does it a lot more for a lot
>> longer. Java does tend to suck for doi
On 05/02/2013 07:25 AM, Sasha Pachev wrote:
> OK, the gauntlet has been thrown.
>
> http://asksasha.com/strrev.c
>
> coded in 25 minutes.
Python version, coded in 1 minutes, well an extra minute to run the REPL
to make sure I had the slice syntax correct:
import sys
for x in sys.stdin:
pr
On Thu, May 2, 2013 at 7:25 AM, Sasha Pachev wrote:
> OK, the gauntlet has been thrown.
> Levi, beat this in Haskell. Barry, Dale, beat this in Java. Anybody
> else, beat this in your language of choice including C - I do not
> claim that my implementation is the best. Post your development time
On Thu, May 2, 2013 at 10:57 AM, Joshua Marsh wrote:
> It also benefits from being able to handle much larger files. I haven't use
> mmap() in years, but I'm guessing if you mmap() a 10GB file, you are gonna
> have a bad time. I suppose the C version could be modified to mmap()
> chunks. That's a
On Thu, May 2, 2013 at 12:43 PM, Sasha Pachev wrote:
> Bryan:
>
> Are you sure about that? Explain this:
>
>
> bash-4.1$ time java LineReverse /usr/share/dict/words > /dev/null
>
> real0m1.413s
> user0m1.634s
> sys0m0.270s
>
> bash-4.1$ time ./strrev /usr/share/dict/words > /dev/null
Not intending to offend. And if Gabe endorses you, you can't be
all bad.
Besides, your thread certainly has gotten activity now. ;-)
On Wednesday, May 01, 2013 17:28:01 Matt Ryan wrote:
> You're right, it probably does seem a bit spammy. Not my
intent, sorry
> about that.
>
> Here's a bit of
On 05/02/2013 12:55 PM, Barry Roberts wrote:
> On Thu, May 2, 2013 at 12:08 PM, Sasha Pachev wrote:
>> Barry's comment proves the point that Java is not really that fast for
>> development time.
>>
> All it proves is that I'm not willing to spend any time with a
> contrived benchmark. I've worked
On Thu, May 2, 2013 at 12:08 PM, Sasha Pachev wrote:
> Barry's comment proves the point that Java is not really that fast for
> development time.
>
All it proves is that I'm not willing to spend any time with a
contrived benchmark. I've worked in Java projects with dozens of
developers and over
Bryan:
Are you sure about that? Explain this:
bash-4.1$ time java LineReverse /usr/share/dict/words > /dev/null
real0m1.413s
user0m1.634s
sys0m0.270s
bash-4.1$ time ./strrev /usr/share/dict/words > /dev/null
real0m0.055s
user0m0.052s
sys0m0.003s
bash-4.1$ time java Li
Dale:
This actually has a bug:
int str_rev(char*s)
{
int length = strlen(s);
int pos = 0;
while(length > 0)
{
s[length--] = s[pos++];
}
}
On string abc\0 this will produce:
aaba
losing \0-termination.
I do not think you can manage to reverse without a true byte swap if
you
Actually, the following has a bug:
#!/usr/bin/perl
while ($curr_line = ) {
print scalar reverse($currr_line);
}
The output begins with a spurious \n. I rewrote it like this to fix it:
#! /usr/bin/perl
while (($l=<>))
{
chop $l;
print scalar reverse($l),"\n";
}
the re-written version e
On Thu, May 2, 2013 at 10:51 AM, Bryan Sant wrote:
> This is truth. I think perl is the right tool for the job for this
> specific task too. Dev time is almost nothing and the relative performance
> is outstanding.
>
>
It also benefits from being able to handle much larger files. I haven't use
On Thu, May 2, 2013 at 10:38 AM, Steve Alligood wrote:
> As for java: no clue. I suspect in this task it would not do as well as
> even the perl, as the JIT won't shine until it does it a lot more for a lot
> longer. Java does tend to suck for doing many small, quick tasks like this
> (not talki
On Thu, May 2, 2013 at 7:25 AM, Sasha Pachev wrote:
> OK, the gauntlet has been thrown.
>
> http://asksasha.com/strrev.c
>
> coded in 25 minutes. When compiled with -O3 gives me this on my laptop:
>
> bash-4.1$ time ./strrev /usr/share/dict/words > /dev/null
>
> real0m0.055s
> user0m0.053
Good argument.
Two minutes to code, and even though it take more than three time as long to
run, does this application require the faster runtime?
Unless you are working on a MUCH bigger data set, or this would be called TONS
of times on a truly busy server, I would concur that perl is the righ
On Thu, May 2, 2013 at 7:25 AM, Sasha Pachev wrote:
> Levi, beat this in Haskell. Barry, Dale, beat this in Java.
Sorry, you'll have to find someone with more time on their hands and
who actually cares how fast Java can read, reverse, and print lines of
text.
But I can tell you I would much rath
replace
int str_rev(char* s)
{
char* s_end;
char tmp;
if (!s) return -1;
s_end = s + strlen(s) - 1;
for (; s < s_end; s++, s_end--)
{
tmp = *s;
*s = *s_end;
*s_end = tmp;
}
return 0;
}
with something like this...
int str_rev(char*s)
{
int length =
OK, the gauntlet has been thrown.
http://asksasha.com/strrev.c
coded in 25 minutes. When compiled with -O3 gives me this on my laptop:
bash-4.1$ time ./strrev /usr/share/dict/words > /dev/null
real0m0.055s
user0m0.053s
sys0m0.002s
my /usr/share/dict/words can be downloaded from her
I thought this was a very germane quote of the day, I got a chuckle out of
it anyways...
"There are two types of languages: ones everybody complains about and ones
nobody uses."
On Thu, May 2, 2013 at 1:57 AM, Levi Pearson wrote:
> On Wed, May 1, 2013 at 10:25 PM, Stuart Jansen
> wrote:
>
> >
On Wed, May 1, 2013 at 10:25 PM, Stuart Jansen wrote:
> I don't follow compilers either, but I do remember being convinced of
> the value of runtime optimization when the following came out in 1999:
> http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html
Dynamo was cool stuff. Basically gives
On Wed, 2013-05-01 at 22:14 -0600, Tod Hansmann wrote:
> My understanding of it (and .NET CLR stuff) was that it was JITed on
> first run, and then never had to be JITed again. So the first time you
> ran a Java/.NET app, it had the initial overhead. Subsequent times it
> does not. Is that no
On 5/1/2013 9:40 PM, S. Dale Morrey wrote:
> Depends on if you mean faster 1 time, or faster after running for a time.
>
> Java has a much higher startup overhead making it unsuitable for programs
> that must run quickly and then exit. However JIT will speed up things that
> need to be run for lo
Depends on if you mean faster 1 time, or faster after running for a time.
Java has a much higher startup overhead making it unsuitable for programs
that must run quickly and then exit. However JIT will speed up things that
need to be run for long periods of time, including compiling sections of
c
in Java:
StringBuffer.reverse()
On Wed, May 1, 2013 at 9:08 PM, Sasha Pachev wrote:
> First, let's say thanks to Matt for providing more employment
> opportunities for us. We are good at the technical aspect, but most of
> us are not so good at business. We need to be thankful for the people
>
First, let's say thanks to Matt for providing more employment
opportunities for us. We are good at the technical aspect, but most of
us are not so good at business. We need to be thankful for the people
that are good at business and remember that we need them as much as
they need us. Perhaps we ne
You're right, it probably does seem a bit spammy. Not my intent, sorry
about that.
Here's a bit of meat:
- We're looking to hire in all technical positions - development, dev/ops,
operations, test automation, etc.
- We're looking to hire at all levels, from entry-level to very senior.
- We are
On Wed, May 1, 2013 at 4:45 PM, Jessie A. Morris
wrote:
> On Wednesday, May 01, 2013 16:43:34 Matt Ryan wrote:
>> I wanted to take a minute of your day to let you know about a
> great
>> employment opportunity with Jive Communications in Orem.
>
> Interesting. This is the 3rd time in over a year h
On 01 May 2013, at 16:45, "Jessie A. Morris" wrote:
> On Wednesday, May 01, 2013 16:43:34 Matt Ryan wrote:
>> Hey PLUG members,
>>
>> I wanted to take a minute of your day to let you know about a
> great
>> employment opportunity with Jive Communications in Orem.
>
> Interesting. This is th
On Wednesday, May 01, 2013 16:43:34 Matt Ryan wrote:
> Hey PLUG members,
>
> I wanted to take a minute of your day to let you know about a
great
> employment opportunity with Jive Communications in Orem.
Interesting. This is the 3rd time in over a year he has sent us a job
posting. And he has
Hey PLUG members,
I wanted to take a minute of your day to let you know about a great
employment opportunity with Jive Communications in Orem. We are a rapidly
growing SaaS company, looking to fill several positions in our engineering
organization to keep up with the company's tremendous growth.
58 matches
Mail list logo
