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

41–50 of 105 posts

Re: D for the Win

#41

Post by marcosdumay »

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.

That entirely depends on your data size.

If you have just a few thousand pages, with a few thousand bytes each in a normal (real) server, no your computer will keep everything at memory, and will only touch the disk for saving data. Also, if you have enough independent requests, throughput will not be network bound.

But CPython may still keep most of its time waiting for RAM. D is much better at this, as is Pypy.

Re: D for the Win

#42

Post by JoeAltmaier »

falcolas wrote: post #39
waps wrote: post #36

Earlier quoted context omitted.

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…

Used to write translators for computer languages. Biggest was PL/M to C. That was easy because PL/M had fewer constructs than C. I managed to recognize constant declarations and map them to #defines or consts which actually made the code More readable.

But these days, languages have features that may be completely orthogonal to other languages. Automatic translation may not be possible. Still it would be by far the cheapest solution.

Re: D for the Win

#43

Post by Iftheshoefits »

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.

I'm not convinced. There are benchmarks[0] that strongly suggest a choice of language is as much a factor in general performance (not merely I/O tasks) as platform (though these frequently go together) and hardware.

[0]http://www.techempower.com/benchmarks/#section=data-r9: in which python frameworks generally perform poorly compared to...anything else other than Ruby

Re: D for the Win

#44

Post by valarauca1 »

copx wrote: post #23
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 [...] ..or Dwarf Fortress player ;)

Oooh thank you for reminding me. I recently upgraded to a i7-4790k I've been meaning to jump back into DF now that I should have much better single threaded performance. I honestly haven't played since 2008 on my parents home pentium3.

Re: D for the Win

#45

Post by blt »

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…

"Write in Python/Ruby/whatever and optimize the slow parts in C" echoes around the programming community endlessly, but I wonder how many people have actually done it. It's kind of hard.

- Automated tools like SWIG have weird limitations and are complex.

- Binding to a C library manually means you have to wrangle the data from a heapy, pointery dynamic language world into whatever format the C libary wants.

- Writing the C code to operate on the dynamic language's objects directly means you have to learn how the language works under the hood, and your C code will never be useful in any other language.

- Python and Ruby both have a GIL that prevents you from using multithreading to its full potential.

- The way dynamic languages lay out objects in memory causes an inherent slowness everywhere. Your app's slowness may well be a death of a thousand cuts, with no easily optimized hot spot.

I think anyone who has actually worked on a project built this way will appreciate the idea of a compiled language that is closer to the expressiveness of Python.

Re: D for the Win

#46

Post by furyofantares »

marcosdumay wrote: post #37
a8da6b0c91d wrote: post #34

Earlier quoted context omitted.

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 e…

It depends on the web app. My experience is that being bottlenecked on the database, while natural, is so crippling to scaling that extensive caching is used to prevent the majority of requests from touching the database.

Re: D for the Win

#47

Post by andrei_ »

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…

would you write Bitcoin in python?

Re: D for the Win

#48

Post by thinkpad20 »

blt wrote: post #45
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…

"Write in Python/Ruby/whatever and optimize the slow parts in C" echoes around the programming community endlessly, but I wonder how many people have actually done it. It's kind of hard. - Automated tools like SWIG have weird limitations and are complex. - Binding to a C library manually means you have to wrangle the data from a heapy, pointery dynamic language world into whatever format the C libary wants. - Writing…

This isn't an assertion, just a question: isn't that exactly the reason why Cython exists, both to more easily facilitate the connection between Python and C, and to create essentially "a compiled language that is closer to the expressiveness of Python"?

Re: D for the Win

#49

Post by simias »

charlieflowers wrote: post #24

"The strange alias _curr this is a lovely feature of D known as subtyping. It basically means that any property that doesn't exist at the struct's scope will we forwarded to _curr, e.g., when I write myCtx.foo and myCtx has no member named foo, the code is rewritten as myCtx._curr.foo." That's a great feature. I don't see many languages investing enough focus into this kind of "delegation wiring."

If I understand correctly you can achieve something similar in many other languages by implementing a dereference operator. You'll have to be explicit when you use the object though (o.foo vs. o->foo for instance). I tend to prefer these kinds of explicit constructs over compiler magic, but it's a matter of taste really.

Re: D for the Win

#50

Post by valarauca1 »

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…

Slightly unrelated, but this confused me.

>1139 (each of which causes a program reschedule)

I thought system calls were packaged into the binary itself and didn't necessarily cause a job to re-schedule. But just caused a context switch to take place, then execution continues.

I thought re-scheduling only happened on interrupt, or a thread reaching a blocked stated.

Could you clarify this for me, I'm interested.

Post reply on HN