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

D for the Win

tomerfiliba.com

Post reply on HN
Print view View original

31–40 of 105 posts

Re: D for the Win

#31

Post by [deleted] »

valarauca1 wrote: post #14
tomwilde wrote: post #10

Earlier quoted context omitted.

As I read it that's one AWS server of unknown size serving ~500rps of an application of unknown complexity. Tripled when using PyPy (whatever that is). Maybe a very small instance serving something fairly complex?

How complex? In one second a modern processor can do ~1 billion operations (ish, some are faster, some are slower, sometimes multiple are done in the same clock tick). Even if its slow, core2 architecture. This means they have the time for about ~200 million instructions per request (Ignoring internal disk I/O, or network I/O). That amount of work is insane! :.:.: I want to say their doing something fundamentally wro…

[deleted]

Re: D for the Win

#32

Post by chrisseaton »

tomwilde wrote: post #20
valarauca1 wrote: post #14

Earlier quoted context omitted.

How complex? In one second a modern processor can do ~1 billion operations (ish, some are faster, some are slower, sometimes multiple are done in the same clock tick). Even if its slow, core2 architecture. This means they have the time for about ~200 million instructions per request (Ignoring internal disk I/O, or network I/O). That amount of work is insane! :.:.: I want to say their doing something fundamentally wro…

Unless you're a mathematician or theoretical physicist the gross of your CPU time will be spent waiting for IO. Reading from disk, writing to the network, synchronizing, etc. They're probably just aggregating 2 or 3 APIs, maybe hitting a database and then adding it all together. That description can apply to almost any and all web applications and is inherently IO-bound.

"Unless you're a mathematician or theoretical physicist the gross of your CPU time will be spent waiting for IO"

As someone working in VM research, I'm not entirely convinced this is true. Perhaps we should do some work to find out where most web applications really do spend their time.

Here's one real-world example: Rap Genius. They certainly aren't mathematicians or theoretical physicists, all they do is process text I think, but it appears they spend over half their time in the Ruby interpreter - not waiting on network or database (if I'm reading the graph correctly).

http://images.rapgenius.com/75aa2143d3e9bf6b769fc9066f6c40c8...

Re: D for the Win

#33

Post by pkinsky »

tomwilde wrote: post #20
valarauca1 wrote: post #14

Earlier quoted context omitted.

How complex? In one second a modern processor can do ~1 billion operations (ish, some are faster, some are slower, sometimes multiple are done in the same clock tick). Even if its slow, core2 architecture. This means they have the time for about ~200 million instructions per request (Ignoring internal disk I/O, or network I/O). That amount of work is insane! :.:.: I want to say their doing something fundamentally wro…

Unless you're a mathematician or theoretical physicist the gross of your CPU time will be spent waiting for IO. Reading from disk, writing to the network, synchronizing, etc. They're probably just aggregating 2 or 3 APIs, maybe hitting a database and then adding it all together. That description can apply to almost any and all web applications and is inherently IO-bound.

This can be solved by minimizing blocking code, either by using actors (Erlang, Akka, etc) or just chaining callbacks on futures/promises and using monadic composition to avoid callback hell.

For a concrete example, check out my Redis-based Twitter clone http://typesafe.com/activator/template/redis-twitter-clone, running at https://clockwork-semaphore.herokuapp.com/#.

Re: D for the Win

#34

Post by a8da6b0c91d »

ckaygusu wrote: post #27

This article is full of D hype and so so so far away from reality. Alright, some basics; Everything that has to access persistent information frequently is bound by disk/network/whatever IO, and web programming is no different. The reason why languages such as Python and Ruby are very viable options for this task is they are quite a lot abstracted away from bare metal to hasten the development process. The wait for I…

People endlessly parroting the "IO bound" line never post numbers. As far as I've seen it's just not true. Things like web apps are routinely bottle-necked by execution speed, not disk or network.

Re: D for the Win

#35

Post by Tloewald »

ckaygusu wrote: post #27

This article is full of D hype and so so so far away from reality. Alright, some basics; Everything that has to access persistent information frequently is bound by disk/network/whatever IO, and web programming is no different. The reason why languages such as Python and Ruby are very viable options for this task is they are quite a lot abstracted away from bare metal to hasten the development process. The wait for I…

So you're arguing that it's "hype" because while it's all true, it doesn't matter if something is I/O-bound. Even if you're right, a server farm that uses 5x fewer CPU cycles is saving a lot of electrical power. 5x is of course a very conservative estimate.

I remember this argument being made in favor of Java (over native compiled code) and there it at least had some credibility. Python and Ruby are far, far slower.

Certainly, the only credible/really important argument in favor of Python (or whatever alternative language you want to suggest) is programmer productivity. Get the feature out the door, and then when it's making money figure out how to optimize it. If I were going to pick on anything in the article, it's the long line of "}"s in the HTML generation example. One of the best arguments in favor of Python's indentation I've ever seen.

Re: D for the Win

#36

Post by waps »

falcolas wrote: post #25
tomwilde wrote: post #20

Earlier quoted context omitted.

Unless you're a mathematician or theoretical physicist the gross of your CPU time will be spent waiting for IO. Reading from disk, writing to the network, synchronizing, etc. They're probably just aggregating 2 or 3 APIs, maybe hitting a database and then adding it all together. That description can apply to almost any and all web applications and is inherently IO-bound.

> That description can apply to almost any and all web applications and is inherently IO-bound. If their system was truly just IO bound, then moving to D wouldn't help them.

That's not true. Well it's true in a very narrow technical sense, but it's not really true.

For example, the amount of housekeeping python does in order to execute a function call is staggering. It leads to all sorts of nice functionality, but nevertheless (plus C++/D does it almost entirely without housekeeping. Either no housekeeping, or 1 level of indirection).

Python has so many indirections for a function call it hardly even makes sense to talk about it in numbers of indirects.

Assembly hello world on my machine : 86,607 cpu cycles (of which Python hello world on my machine (.pyc was available) : 59,099,731 instructions (including half a million branch misses) Syscalls used by python to execute 'print "hello, world"' : 1139 (each of which causes a program reschedule)

These programs do the same thing. Programmers often forget that things they take for granted are not in fact free, they may not even be O(1). Memory allocation. Subprocess execution. Function calls in scripting languages. Syscalls. Writing to files. Allocation of bytes on disks. All of these things come at a really, really high cost, and most not even O(1) costs (e.g. memory allocation is O(N^2) on a busy server as long as things actually fit in main memory, and O(N^4) or even worse when using virtual memory).

Sadly using memory does not even have bounded complexity. At some point, just attempting to use virtual memory might cause virtual memory to be allocated just for the lookup. This is generally referred to as "thrashing" and you're very likely to have rebooted your machine before this completes because it'll be frozen for minutes, sometimes hours, if this happens.

Likewise the memory model is useful, but huge. Strings in C++ take one byte + the actual contents of the string. Strings in python take up 60 bytes + twice the length of the string. And that's assuming you just set a variable to the string. If you construct the string, the difference is going to be much bigger.

The point here is that things that are io-bound (esp. memory bound) in python may be cpu-bound in C++ or D, simply because you avoid doing all the indirections that higher level languages do.

Re: D for the Win

#37

Post by marcosdumay »

a8da6b0c91d wrote: post #34
ckaygusu wrote: post #27

This article is full of D hype and so so so far away from reality. Alright, some basics; Everything that has to access persistent information frequently is bound by disk/network/whatever IO, and web programming is no different. The reason why languages such as Python and Ruby are very viable options for this task is they are quite a lot abstracted away from bare metal to hasten the development process. The wait for I…

People endlessly parroting the "IO bound" line never post numbers. As far as I've seen it's just not true. Things like web apps are routinely bottle-necked by execution speed, not disk or network.

Well, my experience is that web apps are most often bottlenecked by the database speed, because almost any other problem can be solved with money (and not even much of it).

I've seen databases bottleneck on lots of different resources, even some virtual ones (unexpected serializing). But I'm very suspicious of people claiming that one must write webapps in low level languages "because speed". (And yes, I know there exist problems out there where this is true, the same way that there exist people out there that've won the lottery.)

Re: D for the Win

#38

Post by skizm »

Python a D have totally different use cases. Just because you can do something with Python doesn't mean you should.

Re: D for the Win

#39

Post by falcolas »

waps wrote: post #36
falcolas wrote: post #25

Earlier quoted context omitted.

> That description can apply to almost any and all web applications and is inherently IO-bound. If their system was truly just IO bound, then moving to D wouldn't help them.

That's not true. Well it's true in a very narrow technical sense, but it's not really true. For example, the amount of housekeeping python does in order to execute a function call is staggering. It leads to all sorts of nice functionality, but nevertheless (plus C++/D does it almost entirely without housekeeping. Either no housekeeping, or 1 level of indirection). Python has so many indirections for a function call i…

How many instructions were executed after the interpreter was loaded into memory (a much more realistic analog to the twisted server model)?

Once loaded into memory, any program which is bound by IO to memory (i.e. moving the stack from memory to caches/registers) will show up in tools not as being IO bound, but CPU bound.

And yes, CPU bound programs will benefit greatly from moving the hotspots into a linked module written in C or Cython.

I have no problem with moving away from Python (I'm in the process of doing this myself), but the costs associated with re-writing an entire program (especially one complicated enough to only handle 50 requests per second) are non trivial, and if there was simply a small CPU hotspot, it could have been smoothed away in a number of ways that don't involve learning a new language.

In short, everything points towards OP moving to D because of a personal desire instead of a real business case.

Re: D for the Win

#40

Post by valarauca1 »

chrisseaton wrote: post #32
tomwilde wrote: post #20

Earlier quoted context omitted.

Unless you're a mathematician or theoretical physicist the gross of your CPU time will be spent waiting for IO. Reading from disk, writing to the network, synchronizing, etc. They're probably just aggregating 2 or 3 APIs, maybe hitting a database and then adding it all together. That description can apply to almost any and all web applications and is inherently IO-bound.

"Unless you're a mathematician or theoretical physicist the gross of your CPU time will be spent waiting for IO" As someone working in VM research, I'm not entirely convinced this is true. Perhaps we should do some work to find out where most web applications really do spend their time. Here's one real-world example: Rap Genius. They certainly aren't mathematicians or theoretical physicists, all they do is process te…

I can't find the blog post, and the above poster likely knows more then me.

I remember seeing a post several years ago that XEN increases the likelihood of cache misses by 25-50%. Thus while the CPU looks to be at 100% processing power its really waiting on RAM/cache.

Post reply on HN