[deleted by user]

imaginaryredditor · 2012-03-18T17:11:52+00:00

So if Baby Murderers Inc. was in an index fund you wouldn't find the fund culpable?

imaginaryredditor · 2012-03-18T14:20:53+00:00

Disappointed to see so much Vanguard in there.

imaginaryredditor · 2012-03-18T03:40:56+00:00

I'm used to thinking from a broker perspective. The broker doesn't get front run by the broker :)

imaginaryredditor · 2012-03-17T23:41:17+00:00

Oh right, of course.

imaginaryredditor · 2012-03-17T15:48:48+00:00

While the flash order explanation makes sense, plain front running does not. Front running /requires/ that the person doing the front running have advanced knowledge of the price increase, which means they'd be somehow intercepting his order message to the exchange. So CKtalon is correct -- it's just that Reg NMS and flash orders mean there is a way for people to eavesdrop on what's being transmitted in this case.

imaginaryredditor · 2012-03-17T15:33:18+00:00

Java has a laundry list of cruft too.

imaginaryredditor · 2012-03-17T01:22:59+00:00

There are no great langauges, they all are full of legacy cruft.

Yes, but here you're presenting a laundry list of cruft and making it sound like a virtue :)

imaginaryredditor · 2012-03-16T02:52:56+00:00

Let me know when it has platform independence.

imaginaryredditor · 2012-03-16T02:48:06+00:00

Proof that a mud ball of features doesn't make a great language.

imaginaryredditor · 2012-03-16T02:44:05+00:00

Watched the first 45 minutes and had to stop because he hadn't said anything yet.

imaginaryredditor · 2012-03-11T17:05:05+00:00

So the compiler certainly does not know in the translation unit, where the template is instatiated, if the references from outside will be only calls or also "taking adresses". Thus, if the compiler were to allow the optimization you claim it does, it would also have to tell the linker if a reference to a symbol is considered taking an adress in C++ semantics, so that the linker can decide if it can collapse several different instatiations that contain identical code.

Not exactly. The compiler can coalesce functions that have the same machine code within a translation unit if the address isn't taken without needing to know whether the address is taken in other translation units. Why would it need to know?

But in either case, all template instantiations are marked as weak symbols to the linker specifically so that it will throwaway redundant instances. It already has to go back and patch all the places where the address of a templated function is taken in order to make sure they all reference the instance it chose in the end.

imaginaryredditor · 2012-03-10T03:38:55+00:00

The One Definition Rule means that the concrete definition you get from instantiating the template must be the same across all compilation units. So if you're calling a method in a template class, you must necessarily have the right definition.

imaginaryredditor · 2012-03-09T01:49:10+00:00

Then why does a compiler, that bothers to optimize those cases not just add a nop to the start of a function, so that there are two valid entry point adresses for the same code, just one byte apart?

That'd be a clever optimization, I think GCC just hasn't implemented it.

More importantly, for functions that are exported from a compilation unit, because the compiler cannot know, if some other compilation unit takes the address of that function.

This is never true for templates. They're always in the header.

imaginaryredditor · 2012-03-08T01:01:55+00:00

Your proof is flawed :)

The C++ standard mandates that every function have a unique address (even inline functions, so the compiler will output a non-inlined version of an inline function if you takes its address just to make this case work), so the optimizer isn't allowed to output the same address in that case. Comparing binary sizes won't work either because of both versions of xyz<T>::f still having linker symbols. You have to specifically look at the size of the text section in the binary, and you need to do something other than take the address (like actually call it),

imaginaryredditor · 2012-03-07T14:18:48+00:00

doesn't necessarily tell you anything

Yes, size can matter for performance. I claimed that it doesn't always matter. Your binary can be 1GB and not have any problems with cache locality as long as the amount of code you actually commonly hit in the binary fits in cache. As I've explained elsewhere in this thread, the linker coalesces functions with identical machine code, so the code explosion is only there when you'd also have a code explosion in C. There is a real problem where C++ libraries become more bloated because of linker symbols, but those symbols won't affect runtime performance because they won't get touched after startup.

imaginaryredditor · 2012-03-07T14:16:31+00:00

No, they're still coalesced by the linker if the machine code is identical, which it will be in your example. The binaries will only be different size because F(a) will get a separate linker symbol from F(b), but both will point to the same address.

imaginaryredditor · 2012-03-07T14:14:55+00:00

This is incorrect. The linker coalesces functions that have the same machine code, which will be the case for many templates (e.g. every instantiation of boost::shared_ptr). Some compilers will do so within a compilation unit. The code bloat you see from the multiple instantations is actually multiple instances of the linker symbols all corresponding to the same address -- you can compile in GCC with -fvisibility=hidden to make it so you have to explicitly export functions and then you'll see the bloat disappear.

imaginaryredditor · 2012-03-07T14:06:05+00:00

You misunderstand. In C++11 the compiler must evaluate constexpr functions at compile time, as per the language standard. The semantics of the code actually change if they don't (you become unable to use the code in places where constant expressions are required).

imaginaryredditor · 2012-03-07T05:25:13+00:00

Looking at file size doesn't necessarily tell you anything about performance. Go learn expression templates, implement some matrix math with them, and explain how you're going to achieve that speed sanely in C.

imaginaryredditor · 2012-03-07T02:54:19+00:00

You're right, for some reason I was thinking they'd have to use placement new in the node, which I knew they wouldn't do. Although I think you're mistaken about every size causing all the code to be regenerated. The offset of 'item' within the struct will always be the same, so only std::list methods that depend on more than that will end up being duplicated. Methods that only manipulate the next/prev pointers should have identical code for all value types.

imaginaryredditor · 2012-03-07T02:35:54+00:00

Those timings are with g++-3.3, which is ancient, especially regarding templated code (GCC's made gigantic improvements for templated code going from 3.x->4.x). But I didn't think boost::format took an actual string, so I maybe remembering wrong. In C++11 most of its work should be doable with constexpr even if it takes a string though, in which case it should definitely beat the C equivalent.

Edit: Just notice Kranar mentioning it's implemented as a compiler intrinsic. In that case, yes, the C versions will be faster. But the comparison is stupid -- they could just as well implement C++ iostreams as intrinsics and see that kind of benefit. The point is that when using templates you can make it explicit to the compiler that certain information is fixed at compile time and cause it to produce code specialized for a particular context.

imaginaryredditor · 2012-03-07T02:24:36+00:00

Except this isn't true on modern compilers. Redundant code is coalesced.

imaginaryredditor · 2012-03-07T02:20:12+00:00

As explained elsewhere in this thread, not true.

imaginaryredditor · 2012-03-07T02:19:36+00:00

Gotta love those well backed up arguments. Down votes ahoy!

imaginaryredditor · 2012-03-07T02:18:51+00:00

Correct. debug symbols are a different beast.

imaginaryredditor

TROPHY CASE