Disqus - Latest Comments for raggi

Re: Comparing Go and Java, Part 2 – Performance

raggi — Sun, 30 Sep 2012 19:08:53 -0000

I finally got back to this while being stuck in sick.

I did fix a bug in Go's database/sql, but even before that the numbers in this article were quite far off, especially given the hardware.

https://github.com/raggi/go...

Re: Comparing Go and Java, Part 2 – Performance

raggi — Tue, 18 Sep 2012 23:37:17 -0000

I downloaded patricks fork and got 4300r/s with maxprocs 1 with the go version, out the box.

Recompiling and running with gomaxprocs=100, i got 4400r/s.

mvn deploy and running auth-1.0.jar on JDK 1.7 on my box similarly peaked out at 3100r/s.

It's worth noting though, that I was using patricks httperf bench.sh modification, and it appears that httperf was cpu bound in both cases, with the kernel and postres taking about half a core between them.

Using wrk, by contrast, spun main (the go program) up to 2.5 cores, and 6000r/s. Java under wrk lit all cores for a time, then hit `Exception in thread "async-log-appender-0" java.lang.OutOfMemoryError: Java heap space` `Caused by: ! org.postgresql.util.PSQLException: FATAL: sorry, too many clients already`

A bit more investigation and tuning later, using 10 clients `wrk -c 10 -r 100000 -t 4 -H 'Authorization: basic apikey_value' http://localhost:8080/authenticate` Java was spinning out 10kr/s. Go was limited to 6kr/s. It's worth noting some more details however: Go only ever spun up two postgres forks, whereas java spun up 10. There's scope for optimization there. Go used 8mb of ram, whereas java was sitting on 130mb after a few runs. The Java version, cranking out at 10kr/s was maxing the kernel out on one core, so that's probably approaching the practical limit for single machine tests.

I suspect putting a load balancer in front of a couple of instances of the go program would allow you to totally smash the java performance, given that it lit 2 cores at 6kr/s, and java lit 8 at 10kr/s. The memory usage tradeoff is significant - JVM sitting at 130mb and Go sitting at 8mb. Clearly everyone needs to draw their own conclusions on this, for their own purposes. The JVM solution is carrying a stats server, a ton of other tooling and so on. The Go system has some - pprof was included, but it's limited by comparison. Arguably gdb and so on can actually be of real use in the Go case, but that's also an exercise for the reader.

Interesting any which way you look at it. There are a lot of other interesting side effects (that need working out) in both programs as evidenced by this simple testing. Postgres also needs some tuning if you really want to slam this with anything remotely resembling a real world scale test.

My tests were done on OSX 10.8 12B19 on a 2.3GHz i7 wiht 8GB of DDR3 at 1333MHz, an intel 510 SSD, totally untuned postgres. The machine is a Macbook from whatever year that is.

Here's wrk, for anyone looking for it: https://github.com/wg/wrk

Re: Why Bundler 1.1 will be much faster - Pat Shaughnessy

raggi — Mon, 17 Oct 2011 14:07:16 -0000

True.

With regard to those though, that's as much a bug in rubygems for not having the spec fetcher cache them locally and use conditional gets to re-request them. It would have been an easy patch if the http fetching wasn't such awful code. It's one of the many things on a long list of my TODOs for that code base.

Re: Why Bundler 1.1 will be much faster - Pat Shaughnessy

raggi — Mon, 17 Oct 2011 13:23:59 -0000

I'm not sure I'd say it's the "processing" of the gems that makes the old one slow. It's straight up the Marshal.load call that uses up ~200mb of ram. 200mb of strings in arrays is a lot of objects, which is horrible for the GC and ruby isn't all that great at this. Interestingly, when stored as a flat file, that's only 34mb...

Re: SimpleText.ws sync errors

raggi — Thu, 02 Dec 2010 12:09:20 -0000

I seem to remember that the sync protocol is pretty open, can you describe it and/or point me at a copy of the sync server, as I see the software allows us to host our own, I'd happily host one for a while.

Re: Firesheep In Wolves Clothing: App Lets You Hack Into Twitter, Facebook Accounts Easily

raggi — Mon, 25 Oct 2010 05:41:31 -0000

Anyone doing disqus on this site? ;-)

Re: The magical (and not harmful) rebase - Jeff Kreeftmeijer

raggi — Mon, 11 Oct 2010 09:55:51 -0000

I have to ask why you're even pushing there?

You could just be using --amend and rebasing completely locally.

There's absolutely no reason to need to force push in the environment you just described.

Re: The magical (and not harmful) rebase - Jeff Kreeftmeijer

raggi — Mon, 11 Oct 2010 09:51:32 -0000

I'd be much more happy if git had an option that said "open a link to the remote repository, open a lock, rewrite the history if the current branch history matches my local cache, then free the lock". This way the local developer can be sure that their changes are overwriting specifically commits that they're aware of, and never commits they are unaware of. This is *not* what -f does, though. Also, as seen recently at work, -f without refspecs will force push all branches that have remote branches set for merge, meaning there's massive potential for human error here too.

Re: The magical (and not harmful) rebase - Jeff Kreeftmeijer

raggi — Mon, 11 Oct 2010 09:48:15 -0000

That depends, any time you force push you risk blowing someone else's work away or forcing them to write a merging commit (rebase or merge, it makes no odds). One forces them to rewrite history, one apparently "makes a mess". In some cases it should fast-forward, sure. The point is, you don't ever lock the remote repository, which means that you can, if there's more than one person on a branch, never ever ensure that you won't be overwriting changes with a force push. How do you propose this should be addressed correctly?

Re: The magical (and not harmful) rebase - Jeff Kreeftmeijer

raggi — Mon, 11 Oct 2010 09:41:39 -0000

git push --force is evil. If your process of choice is making you use it often then I would say your process is broken. That is absolutely harmful, and I don't see how anyone can really justify otherwise.

The point about a force push is that it's really the equivalent of sending a zip package containing a new repository tree out to other people. It's a step backward, not a step forward.

I'm all for people rewriting their history *locally*, git commit --amend and rebase are indeed useful for local operations, but as soon as you've pushed you should merge.

People seem to wax on about clean histories, but I've never been annoyed by an unclean history. I've been annoyed by an OCD-cleansed history many times, where I can't see the real flow of events, and thus miss many reasons behind things. One example people give is crunching down cyclic changes, but that's either: a) you weren't thinking about it, and boo hoo, use amend or man up. b) you were thinking about it and you learned something along the way. In the case of (a) if you risk blowing my work away with a --force, you deserve a punch because it's only your pride you're protecting, leave your ego (and OCD) at the door, tbh, it just makes you look like a slacker anyway. In the case of (b), I damn well need to see those commits. The reasons (and history) matter. Don't rewrite history publicly. Clean your own worklog, sure, but do not rewrite public history.

Git is a VCS, please do not remove *versions*, otherwise it's really just a glorified transport for patch bundles, and you may aswell move back to zips and ftp, with a few wrapper scripts called "push" and "pull" (actually, pull breaks, so it's checkout -f).

Re: Eric Schmidt: Google gets close to 'the creepy line'

raggi — Wed, 06 Oct 2010 10:45:20 -0000

The creepy line depends on intent. You don't worry about a doctor touching your genitals if they do it with your permission. If they do it without your permission, you care. The same goes for personal information and information driven tools or services.

Re: detailed explanation of a recent privilege escalation bug in linux (CVE-2010-3301)

raggi — Mon, 27 Sep 2010 10:42:20 -0000

bro, you're not a ruby programmer.

Re: Crowd Interactive Tech Blog :: Benchmarking thin vs unicorn

raggi — Wed, 22 Sep 2010 21:26:46 -0000

Also, the minimal difference can be the statistical error in ab. It lies about the number of requests it makes, check the data transfer sizes and request counts on the server sides.

Re: Rail's Enumerable#sum is slower than Enumerable#inject

raggi — Sat, 11 Sep 2010 17:26:51 -0000

If you really want to analyse it from a complexity standpoint against the *actual runtime* then it's not even fair to say both are O(n) as the differences in their performance profiles are nothing to do with even the factors of n in reality, but more the block invocation performance, which has a far far far more complex computational complexity. Seems it's all drastically oversimplified to reduce it down to these terms, but the closest thing at this level of non-abstraction is to not reduce the terms. - This is what I meant when I said apples are not oranges.

Re: Ruby Benchmark > Implicit Versus Explicit Return

raggi — Fri, 10 Sep 2010 23:48:11 -0000

interpreter specific.

Re: Ruby Benchmark > Hash Merge

raggi — Fri, 10 Sep 2010 23:47:50 -0000

This is only true for a single value like this, it is not testing merging, but the creation (or not thereof) extra hashes by the literals passed as the arguments to merge. This will as with every other benchmark I've seen here, misinform users.

For preexisting hashes, merge is faster than multiple method calls, as (on MRI) it all runs in C.

Test broken.

Re: Ruby Benchmark > String Generation

raggi — Fri, 10 Sep 2010 23:45:07 -0000

Like most of the other tests here, these are tarnished by a lack of range testing.

Re: Ruby Benchmark > Gsub Literal Vs Regex

raggi — Fri, 10 Sep 2010 23:44:22 -0000

Regular expression literals are cached in the AST when not interpolated, so new objects are not created for them. String literals are not cached, and are reevaluated each time. Practical applicability of this test is questionable as it does not highlight the large space-time difference between the two. A GOOD number of repetitions would reveal the string literal to be "much slower", as it would cause the GC to kick in more often due to the churning of new string objects. Either way, the test is pointless, use a constant for the string to compare gsub performance statistics, and furthermore, you should observe that there are significant differences if the input and search string sizes change significantly. Another appalling benchmark.

Re: Ruby Benchmark > Checking For Zero

raggi — Fri, 10 Sep 2010 23:40:55 -0000

stdlib benchmark can do this test over an order of magnitude faster. I would anyway suggest that this test is also running for insufficient time to be clear of statistical errors, although the final conclusion is not far wrong, for MRI.

Re: Ruby Benchmark > Clearing An Array

raggi — Fri, 10 Sep 2010 23:31:53 -0000

As per so very many other of the benchmarks on this site, this test is CLEARLY broken. There is absolutely no way on MRI that a method call be that much slower than replacement of a local variable.

I suspect there is statistical invariance introduced by the library or by the GC during the runtime of this test.

Proof: https://gist.github.com/a26...

Re: Ruby Benchmark > Enumerable Iteration

raggi — Fri, 10 Sep 2010 23:26:43 -0000

For calls each. something is wrong. I suspect the test runtime is too short to be statistically accurate.

Re: Ruby Benchmark > Test

raggi — Fri, 10 Sep 2010 23:24:56 -0000

Warning: this will not hold true on other interpreters.

Re: Ruby Benchmark > Test

raggi — Fri, 10 Sep 2010 23:24:34 -0000

Warning: this will not hold true on other interpreters.

Re: Ruby Benchmark > Test

raggi — Fri, 10 Sep 2010 23:22:56 -0000

Regular expression literals are cached, wheras string literals are reevaluated. This has nothing to do with the performance of gsub or the regex engine, but the overhead of creating new strings in every iteration in the gsub supplied with a string benchmark. Another awful benchmark on this site.

Re: Rail's Enumerable#sum is slower than Enumerable#inject

raggi — Fri, 10 Sep 2010 23:19:25 -0000

Ahem, the sum algorithm is NOT O(n) it's O(2n), it maps first, then sums.

Apples are not Oranges.