Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Did anybody solve this?

1.61803398874.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Did anybody solve this?

#11

Post by [deleted] »

mvgoogler wrote: post #10
dexen wrote: post #7

Earlier quoted context omitted.

The only problem with `tee' is that it's hard to find it unless you know where to look -- took me some 2 years. Perhaps the real challenge here is sticking with the team that produces incredible qunatities of code , as they put it, and will rather re-implement tee than find it. I wonder if they implemented own virtual memory with on-demand paging yet ;-)

Except that if you read the problem statement, you'll see that tee doesn't meet the requirement of 'taking advantage of all available I/O parallelism'. Tee writes to each output file sequentially. Given that their core business is data-stores that take full advantage of emerging storage technologies (such as flash), this seems like pretty relevant question.

[deleted]

Re: Did anybody solve this?

#12

Post by ryaf »

a3_nm wrote: post #5

Also, did anyone solve their "canine challenge"? It seems to me that what they're asking for is "tee FILE... > /dev/null", but maybe I'm missing something?

I am by no means a system programmer (I'd love to learn, no idea where to start), but seeing some sort of either breakdown or a list of implementation challenges to solve this problem would be awesome. I get that the man page describes what it needs to handle, but I don't clearly see every moving piece that this would have to deal with and account for.

Re: Did anybody solve this?

#13

Post by krakensden »

jerfelix wrote: post #9

Spoiler Alert! The answer is rethingdb. Apparently an ad for rethinkdb.com: >>> print "".join((chr((ord(x)-int(y)-ord("a"))%26+ord("a")) for x,y in zip("xfbhlqtlj","61803398874"))) rethinkdb

You know what's sad? I knew that just from the job description. I'm not sure if that means I've spent far too much time on HN over the years, or if there is a real dearth of startups doing systems-level development.

Re: Did anybody solve this?

#14

Post by joshcorbin »

mvgoogler wrote: post #10
dexen wrote: post #7

Earlier quoted context omitted.

The only problem with `tee' is that it's hard to find it unless you know where to look -- took me some 2 years. Perhaps the real challenge here is sticking with the team that produces incredible qunatities of code , as they put it, and will rather re-implement tee than find it. I wonder if they implemented own virtual memory with on-demand paging yet ;-)

Except that if you read the problem statement, you'll see that tee doesn't meet the requirement of 'taking advantage of all available I/O parallelism'. Tee writes to each output file sequentially. Given that their core business is data-stores that take full advantage of emerging storage technologies (such as flash), this seems like pretty relevant question.

Except that if you do: whatever | tee filea | tee fileb | tee filec | tee filed >/dev/null, you'll get parallelism. This works since tee will write first to stdout, and then to the file you pass it. This may not be "all available" parallelism, but I suspect that it's a decent approximation of "good enough".

Re: Did anybody solve this?

#15

Post by a3_nm »

mvgoogler wrote: post #10
dexen wrote: post #7

Earlier quoted context omitted.

The only problem with `tee' is that it's hard to find it unless you know where to look -- took me some 2 years. Perhaps the real challenge here is sticking with the team that produces incredible qunatities of code , as they put it, and will rather re-implement tee than find it. I wonder if they implemented own virtual memory with on-demand paging yet ;-)

Except that if you read the problem statement, you'll see that tee doesn't meet the requirement of 'taking advantage of all available I/O parallelism'. Tee writes to each output file sequentially. Given that their core business is data-stores that take full advantage of emerging storage technologies (such as flash), this seems like pretty relevant question.

I did read the problem statement, but I thought tee was writing to all files in parallel. It's surprising that there seems to be no way to achieve that.

Re: Did anybody solve this?

#16

Post by dexen »

a3_nm wrote: post #15
mvgoogler wrote: post #10

Earlier quoted context omitted.

Except that if you read the problem statement, you'll see that tee doesn't meet the requirement of 'taking advantage of all available I/O parallelism'. Tee writes to each output file sequentially. Given that their core business is data-stores that take full advantage of emerging storage technologies (such as flash), this seems like pretty relevant question.

I did read the problem statement, but I thought tee was writing to all files in parallel. It's surprising that there seems to be no way to achieve that.

Tee writes in one-thread-per-file level of parallelism; simple experiment:

  $ tee foo.bin bar.bin baz.bin
writes to all three files `at once' (in small time-slices, actually). Used GNU tee from coreutils-8.10.

Perhaps OP meant several-threads-per-file level of parallelism, where number_threads > number_files?

Re: Did anybody solve this?

#17

Post by [deleted] »

dexen wrote: post #16
a3_nm wrote: post #15

Earlier quoted context omitted.

I did read the problem statement, but I thought tee was writing to all files in parallel. It's surprising that there seems to be no way to achieve that.

Tee writes in one-thread-per-file level of parallelism; simple experiment: $ tee foo.bin bar.bin baz.bin writes to all three files `at once' (in small time-slices, actually). Used GNU tee from coreutils-8.10. Perhaps OP meant several-threads-per-file level of parallelism, where number_threads > number_files?

[deleted]

Re: Did anybody solve this?

#18

Post by mvgoogler »

dexen wrote: post #16
a3_nm wrote: post #15

Earlier quoted context omitted.

I did read the problem statement, but I thought tee was writing to all files in parallel. It's surprising that there seems to be no way to achieve that.

Tee writes in one-thread-per-file level of parallelism; simple experiment: $ tee foo.bin bar.bin baz.bin writes to all three files `at once' (in small time-slices, actually). Used GNU tee from coreutils-8.10. Perhaps OP meant several-threads-per-file level of parallelism, where number_threads > number_files?

tee has a simple main loop: while not EOF: (synchrounously) read up to BUFSIZE bytes from stdin into buf for each output file: (synchrounously) write buf to file

(source code here: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/tee....)

All of the reads and writes are done through synchronous file apis. I don't see where you are getting one-thread-per-file (or any other kind of parallelism) there.

Re: Did anybody solve this?

#19

Post by etrain »

kuriraisu wrote: post #2

Yes. Use the modulus implementation of the vignere cypher. Then look up how C and python handle modulus.

The latter half of the challenge was much more interesting to me. I'm a C/Python guy but didn't know the subtle language difference here. Additionally, in figuring out the difference, I learned that the C implementation takes almost the same # of characters as the python one..

Re: Did anybody solve this?

#20

Post by munin »

I like how they changed the text from "In your e-mail, please explain why C and Python solutions to decipher the string above return slightly different results."

they added "naive" and "might" ...

Post reply on HN