Earn money with programming

[helios]

Ok, so you obviously do not know

Oh, if only you had the slightest clue about anything you're talking about...
Run along, now.

[EzwRko23]

Ok, so you ran out of arguments. EOT from my side, although I'm very curious of your alternative definition of scalability, having nothing to do with the relation between hardware resources and size of the problem ;) You see, scalability is a scientific, unambiguous quantity. You cannot just define it as you wish.

[chrisname]

I think there's a difference between "[running] out of arguments" and discontinuing an argument because it is completely useless. But of course, you couldn't accept that. No, you just had to have an extra power trip to show your [pseudo-]intellectualism.

[Bazzy]

_{Title of the thread:}

Earn money with programming

xorebxebx wrote:

This does not proove anything and is totally offtopic.

helios wrote:

I agree with him. Bazzy went a little off-topic, back there.

_{discussion between xorebxebx and helios:}

completely unrelated to the topic

I went off-topic?

LOL

BTW, how do you pronounce 'xorebxebx' ?

OK, now I am off-topic

[chrisname]

It's XOR EBX, EBX I think, which is an assembly instruction to make EBX = 0. Performing a XOR to zero a register is faster than moving 0 into the register with MOV.

[EzwRko23]

Just as "xor ebx, ebx".
But, yes, I agree, we got offtopic for the last few posts. I don't know why helios tried to discuss scalability and functional programming issues. C++ was never meant to be an FP language and HA systems / massively parallel language - this should be clear to even the most hardcore C++ fanboys. Otherwise Ericcsson would not invent Erlang, and shared nothing database or telecommunication systems would be written in C++ instead of Erlang.

[Bazzy]

we got offtopic for the last few posts

I thought it has been off-topic for the last 6 + ¹/₂ pages...

[helios]

Performing a XOR to zero a register is faster than moving 0 into the register with MOV.

Used to be.

I don't know why helios tried to discuss scalability and functional programming issues.

Excuse me, but I never made any reference to either of those concepts.

I don't know why helios tried to discuss [anything]

Why? Because it's there.

By the way, did anyone else notice that xorebxebx is not the same as xoreaxeax? It's true. Go back to the first page.

[Bazzy]

http://www.cplusplus.com/member/xoreaxeax/ :

This account has been suspended by an administrator.
This was likely due to the user not following some specific rules for a service in this website.
If you believe this to be an error, please use our contact form

Administrator's note: multiple reports no trolling, please

I think it's the same person.
BTW, I didn't notice

[chrisname]

I did. I also investigated and saw the suspension notice.

Who reported him for trolling? I don't think he was trolling; he wasn't deliberately being annoying.

[tition]

Oh common, some adversity from an educated person much more fun than, say, watching politicians argue on TV. I read nothing deserving a ban.

Other than that, xorebxebx's general attitude is as if somebody ate his lunch - which might actually be the case.

Nobody seemed to protest that the java vs C++ discussion kinda funny, in view of how similar the two languages are...

[NGen]

Syntactically, they're fairly similar. In implementation they're a world apart.

Just out of curiosity, how does an immutable state help improve scaleability? What's becoming immutable? And while I'm at it, what does the term 'loc' refer to?

[helios]

Lines Of Code.

[blackcoder41]

Who reported him for trolling? I don't think he was trolling; he wasn't deliberately being annoying.

No one, I guess..

[NGen]

Thanks. I have no idea why I didn't catch that before. Musta' been derpin'.

As for the whole immutable thing?

[EzwRko23]

Just out of curiosity, how does an immutable state help improve scaleability?

1. No need to lock shared immutable objects. You can write totally lockless programs. No locks = no need to ever wait for access to data. In imperative programs you need to lock both reads and writes, even if you do just one write per a thousand reads. And fine grained locking is extremely difficult to get right (deadlocks possible etc.).

2. No need for costly updating of processor caches in NUMA machines. When a shared object changes, hardware must assure that this object is not present somewhere in other processors' caches - and evict this objects from caches in case it is.

3. This is not directly connected with immutability, but usually immutable data structures help in functional programming, and functional programming allows for different concurrency models - e.g. not thread based, but actor based. In the actor based model, immutable messages are passed between actors. Immutability helps to isolate actors from each other. Actors are not tightly bound to the executing threads, so moving the application from a 4 core machine to a 100 core machine needs no changes in code. Actor based model allows even distributing an application between different physical machines connected with network - still with no changes to the code (only in the deployment configuration).

4. If actors hold no mutable state, then they can be transferred accross the nertwork. This allows sometimes a very efficient schemes consisting in moving data processors to data instead of moving data to data processors. This works well when data is large and state is small (actors do have state, but it is just not mutable).

[z05DSL3A]

Who reported him for trolling?

I didn't report xoreaxeax for trolling, but did raise concerns with the admin on another matter. Those concerns had been voice in the public forum by myself and others.

[NGen]

So an immutable object, when just looking at the primary way it's useful, let's you avoided mutexes.

When looking up the term in Google, Wikipedia compares it to just being an object with const tacked on to it. I'm assuming that's not the kind of immutable that's being mentioned here?

[EzwRko23]

Const provides just a shallow immutabile **view** of the object - it is not transitive, and because it can be easily cast away, compilers cannot make any assumptions basing on declared constness. So this is only slightly more than a comment saying "don't modify this" - the compiler would catch direct violations of this, but cannot give any global guarantees. True immutable objects are deeply and always immutable. There is no way to change them otherwise than by exploiting a vulnerability in the runtime system ;) You can not cast immutability away. Thus, when you have a reference to an immutable object, you can be sure it won't change, regardless of how many codemonkeys you have in your team.

You should keep in mind that to create efficient code with immutable structures, you need different data structures than those that are used in imperative programming (particularly persistent data structures which C++ STL is lacking). Otherwise whenever you wanted a modified version of your object, you would need to make a full copy of it. Copying a large vector or a large array every time you needed to change just one item is a bad idea.

[helios]

and because it can be easily cast away

If you like undefined behavior, then yes, you can easily cast the constness away.

compilers cannot make any assumptions basing on declared constness

Sure they can.