Live data from Hacker News

Starting a tech startup with C++

medium.com

31–40 of 107 posts

Re: Starting a tech startup with C++

#31
post #26
post #16

> Manual memory management is the most popular misconception of C++. Since C++11, it is now recommended to use std::shared_ptr or std::unique_ptr for automatic memory management. There is a small computational cost to maintaining referenced pointers but it’s minuscule and the safety outweighs this cost. I think another misconception is that you need pointers at all. Smart pointers are still pointers. Its better to us…

Because copying the entire in-memory database you're using on every function call is kind of expensive?

Most often you can pass stack values to and from functions without copying. This is because of move constructors, and named return value optimization. Often its slower to use pointers (the indirection).

For instance this does not do any expensive copies:

std::string getStr() { auto huge_str = getDatabaseDump(); return huge_str; }

void readStr(const std::string& str ){ //read str.. }

int main() { auto str = getStr(); readStr(str); }

Re: Starting a tech startup with C++

#32
post #28
post #16

> Manual memory management is the most popular misconception of C++. Since C++11, it is now recommended to use std::shared_ptr or std::unique_ptr for automatic memory management. There is a small computational cost to maintaining referenced pointers but it’s minuscule and the safety outweighs this cost. I think another misconception is that you need pointers at all. Smart pointers are still pointers. Its better to us…

You mean C++ programmers allocate n object on the heap even when its lifetime is the same as the scope of the containing block ? Unless its such a large huge object that stackoverflow is a possibility I cant imagine why would one do that.

Many programmers have this idea. Oh, this is a big object. I better wrap it in a smart pointer to avoid doing expensive copies when I pass it around. They do it as an optimisation. However because of named return value optimisation and move constructors no expensive copies are done when passing stack values to and from functions. Using smart pointers is actually slower (because of the indirection and reference counting).

Re: Starting a tech startup with C++

#33
post #16

> Manual memory management is the most popular misconception of C++. Since C++11, it is now recommended to use std::shared_ptr or std::unique_ptr for automatic memory management. There is a small computational cost to maintaining referenced pointers but it’s minuscule and the safety outweighs this cost. I think another misconception is that you need pointers at all. Smart pointers are still pointers. Its better to us…

Well said! Dynamic memory allocation is a really big performance hit, and in a lot of cases you can pre-allocate data structures on the stack for serious speed improvements. Avoiding DMA was one of the secrets for writing blazing fast real time systems stuff when I was in telecom. I don't think those benefits have gone away.

You and I can't possibly have the same definition of DMA. It is essential to low latency data communication both in the embedded and server domain.

Re: Starting a tech startup with C++

#34

I would find it hard to believe that c++ can be that much faster for many websites since the bottleneck would be the I/O subsystem. I don't understand how they are getting this 40x speed up. I wonder what the benchmark looks like.

It's not that a single request is 40x faster (it may be no faster), it's that 40x requests can be handled in the same amount of time. The limitation is then the processing of the connections both in userspace and in the kernel, and the cost of all the system calls.

This is easy enough to test with ab (apache bench), siege, or jmeter, by just cranking up the number of concurrent requests. I've seen 100x differences in implementations of web servers before, 40x for python vs c++ is pretty believable.

Re: Starting a tech startup with C++

#35
post #4

It's sad that you need to justify using one of the most established and longest serving languages/platforms ever.

I don't think it is sad. You explained why it is necessary, C++ has been around for a while, is/was great but there are now languages that can compete in terms of performance with fewer drawbacks in terms of security and undefined behavior. If you're starting from scratch, it is important to strongly consider which language and platform best suits your needs. Anecdotally, a lot of companies have found success using n…

> there are now languages that can compete in terms of performance

Such as?

Re: Starting a tech startup with C++

#36

Earlier quoted context omitted.

Well said! Dynamic memory allocation is a really big performance hit, and in a lot of cases you can pre-allocate data structures on the stack for serious speed improvements. Avoiding DMA was one of the secrets for writing blazing fast real time systems stuff when I was in telecom. I don't think those benefits have gone away.

You and I can't possibly have the same definition of DMA. It is essential to low latency data communication both in the embedded and server domain.

"Dynamic memory allocation", not "direct memory access".

Re: Starting a tech startup with C++

#37

Earlier quoted context omitted.

Well said! Dynamic memory allocation is a really big performance hit, and in a lot of cases you can pre-allocate data structures on the stack for serious speed improvements. Avoiding DMA was one of the secrets for writing blazing fast real time systems stuff when I was in telecom. I don't think those benefits have gone away.

You and I can't possibly have the same definition of DMA. It is essential to low latency data communication both in the embedded and server domain.

I think he was using a new acronym for Dynamic Memory Allocation rather than Direct Memory Access. I also was confused the first time I read it.

Re: Starting a tech startup with C++

#38
post #16

> Manual memory management is the most popular misconception of C++. Since C++11, it is now recommended to use std::shared_ptr or std::unique_ptr for automatic memory management. There is a small computational cost to maintaining referenced pointers but it’s minuscule and the safety outweighs this cost. I think another misconception is that you need pointers at all. Smart pointers are still pointers. Its better to us…

Pointers (smart or raw or whatever) get used when you need reference semantics. It's true that value semantics are usually better but not always (eg inheritance).

To be sure, though, being able to make proper value types is a strength of C++. Also we should point out most non-trivial value types make extensive (and necessary!) use of the heap under the hood (eg string, vector)

Re: Starting a tech startup with C++

#39
For databases, C/C++ is still the only reasonable choice. For OLAP cubes in particular, you want to keep as much data in memory as possible as efficiently as possible, and drop down to SSE intrinsics where needed. C++ lets you do just that. Frontend can be in any language you like.

Re: Starting a tech startup with C++

#40
post #28
post #16

> Manual memory management is the most popular misconception of C++. Since C++11, it is now recommended to use std::shared_ptr or std::unique_ptr for automatic memory management. There is a small computational cost to maintaining referenced pointers but it’s minuscule and the safety outweighs this cost. I think another misconception is that you need pointers at all. Smart pointers are still pointers. Its better to us…

You mean C++ programmers allocate n object on the heap even when its lifetime is the same as the scope of the containing block ? Unless its such a large huge object that stackoverflow is a possibility I cant imagine why would one do that.

I don't think C++ supports variable length arrays?

So, if you want to allocate N objects, where N is not known at compile time, (I think) you have to use heap allocation anyway. Normally I just use vector, and call reserve() if I feel like extra performance-y. Sure, it's much slower than C99-style variable length arrays, but 99% of the time it's still fast enough.

More importantly, it plays nice with other C++ functionalities. For example, zero-copy construction using emplace_back() inside a for loop. (And if you throw an exception in the middle you're guaranteed that destructors are called exactly for those that are already constructed.)

Post reply on HN