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

C++: A language for next generation web apps

stevehanov.ca

Post reply on HN
Print view View original

61–70 of 99 posts

Re: C++: A language for next generation web apps

#61

Post by fauigerzigerk »

anonjon wrote: post #53
jrockway wrote: post #46

Earlier quoted context omitted.

Not really true. I can write the same algorithm in Perl as in Haskell, and the Haskell always runs faster.

Chances are that the majority of developers won't find the most efficient algorithm to solve the problem. (vs. the most efficient implementation of that algorithm... which is clearly going to be in a combination of C and assembly anyway). Anyway, the guy using the good algorithm ends up with the fastest code. Different compilers will produce different quality of code. Question is, if I am using C++ vs. a guy using Pe…

"Chances are that the majority of developers won't find the most efficient algorithm to solve the problem."

If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language.

Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.

Re: C++: A language for next generation web apps

#62

Post by loup-vaillant »

alfredp wrote: post #9

if you're on an embedded device, this is actually not a satire

Current embedded devices are likely to have at least 256Mb of RAM, 4Gb of Flash, and as much MIPS as a Pentium III. Not so "embedded" any more, don't you think? If Portability is an issue, then I am likely to use C with something like Lua. But I can't imagine for a second abandoning garbage collection before I see proof I can't afford it.

Re: C++: A language for next generation web apps

#64

Post by rbanffy »

astine wrote: post #36
rbanffy wrote: post #6

I missed the tag.

From the article: I gave a tongue-in-cheek talk on how C++ can fit in to a web application.

The thruth is, my company maintains a C++ we application. It's implemented as an Apache module and employs some very interesting in-memory shared structures.

And, like I said, I missed that part.

It was not proper markup ;-)

Re: C++: A language for next generation web apps

#65

Post by jrockway »

fauigerzigerk wrote: post #61
anonjon wrote: post #53

Earlier quoted context omitted.

Chances are that the majority of developers won't find the most efficient algorithm to solve the problem. (vs. the most efficient implementation of that algorithm... which is clearly going to be in a combination of C and assembly anyway). Anyway, the guy using the good algorithm ends up with the fastest code. Different compilers will produce different quality of code. Question is, if I am using C++ vs. a guy using Pe…

"Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.

I don't get the constant complaints about the GIL. Letting your Python program run on 2 cores will make it 2x faster at best. Rewriting it in, say, Javascript or Lisp or Haskell or Java will make it run 2-50x faster on one core. After you get your 50x speedup, then you can worry about the 4x you'll get from buying 3 more processor cores.

(And oh yeah; it's only shared-memory concurrency that things like the GIL affects. If you have a job to do that wants to use 8 cores, split the job up into 8 parts and invoke your program 8 times. There's your 8x speedup.)

Re: C++: A language for next generation web apps

#66

Post by metamemetics »

Let's say C++ can code be executed OVER 9000% faster than python.

However this does not imply a web app written in C++ will run even 1% faster than a web app written in python unless the performance bottleneck is code execution.

If the performance bottleneck is instead the database server (which it almost always is) then choosing C++ for your next webapp would be a _very_ masochistic premature optimization.

Re: C++: A language for next generation web apps

#67

Post by fauigerzigerk »

icefox wrote: post #29
joe_the_user wrote: post #19

Earlier quoted context omitted.

Oddly enough I'm back to C++ too, after Ruby. One nice thing is; in a fast language, tests run quickly too. Also, Python and Ruby don't have the equivalent of an ASSERT (you could roll your own but it's not standard practice ). Also, C++ has standard hash lists and complicated data structure are actually going to run quickly. And while memory management can be a pain, you are doing it yourself so you can track down m…

RubyOnRails is very test gunghu, but to run a hello world test takes seconds , anyone know why? This seems very odd. Is this one of those do what I preach, not what I do things?

Because if "performance doesn't matter" is repeated often enough people actually start to believe it, and if enough people believe it, it becomes false. Is there a name for this logic? :-)

Re: C++: A language for next generation web apps

#68

Post by ramchip »

jrockway wrote: post #65
fauigerzigerk wrote: post #61

Earlier quoted context omitted.

"Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.

I don't get the constant complaints about the GIL. Letting your Python program run on 2 cores will make it 2x faster at best. Rewriting it in, say, Javascript or Lisp or Haskell or Java will make it run 2-50x faster on one core. After you get your 50x speedup, then you can worry about the 4x you'll get from buying 3 more processor cores. (And oh yeah; it's only shared-memory concurrency that things like the GIL affec…

> 2x faster at best

That's if you're CPU-bound. I don't use Python, but I made an image acquisition program in C++ which could be a relevant example. We wanted to save the images to disk in real-time (30-60FPS). Doing this in the acquisition loop would make the software unusable (the goal is video-rate confocal microscope imaging); it's far too long, and much of it is just due to disk writes being slow, not to the compression time. Using a thread pool was the solution, not because of an actual increase in speed, but because from the loop's POV the write went from blocking to non-blocking so the CPU stopped wasting time waiting for the disk.

We also wanted shared memory since there can be a lot of image data which is shared between the image compression & saving, display, and possibly statistics or filtering modules.

Re: C++: A language for next generation web apps

#69

Post by birger »

badsectoracula wrote: post #57

For a two to three years i was running in a VPS server in VPSLink which had about 64MB of RAM - for everything and without swap space. The target use of this VPS was probably as an email server or something as most people recommended the more expensive 128MB and 256MB plans for serving (static) pages. And actually there were only about 40MB left since the OS needed some memory for itself too. Personally i thought tha…

Interesting to see that you used FreePascal! We are also experimenting with FreePascal and (fast)CGI. My collegue put up some sample pages: http://services.cnoc.nl/lazarus/index/fclweb

Re: C++: A language for next generation web apps

#70

Post by fauigerzigerk »

jrockway wrote: post #65
fauigerzigerk wrote: post #61

Earlier quoted context omitted.

"Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.

I don't get the constant complaints about the GIL. Letting your Python program run on 2 cores will make it 2x faster at best. Rewriting it in, say, Javascript or Lisp or Haskell or Java will make it run 2-50x faster on one core. After you get your 50x speedup, then you can worry about the 4x you'll get from buying 3 more processor cores. (And oh yeah; it's only shared-memory concurrency that things like the GIL affec…

I can only tell you why _I_ am constantly complaining about the GIL. It's because I would like to use a Python/C combination for in-memory data analysis. C gives me the speed and memory efficiency and Python gives me the ease of use and the web stuff.

There is no 50x speedup to be had as it doesn't get any faster than C. The only significant speedup will come from parallelism. 8 cores this year, 16 next year and probably a 100 cores in a few years. Since I'm holding a lot of data in memory I can only run one process not many unless I implement each and every data structure on top of shared memory, which I'm not going to do because it's unproductive.

I cannot use Java or JavaScript or any language that doesn't have value types (i.e. structs and arrays of structs) with a well defined memory layout. I don't want to use Haskell because my problem doesn't lend itself to functional programming as it's inherently stateful. I feel I would have to fight the nature of Lisp to make it use as little memory as C. It makes no sense to use Lisp when I need to know how lists are laid out in memory.

The only realistic options right now are pure C, pure C++ or C#. Go does have all the right properties as well. It's very immature at this point though.

Post reply on HN