CCR and Performance

[Uri Goldstein]

Way back when we had the first Alt.Net Israel meetup, we had a slot
(which I managed to miss) about MS CCR (Concurrency and Coordination
Runtime - http://msdn.microsoft.com/en-us/library/bb905450.aspx) and
how useful it is for managing threads.

Now I've finally come to a point where I think CCR might be of use to
me and I'm busting my brains trying to learn what it does and how.

Might the kind soul who gave that talk (was it Ken, perchance?) guide
me in the direction of some useful "CCR for Dummies" resources on the
web? I've gone over http://msdn.microsoft.com/en-us/magazine/cc163556.aspx
and http://www.lnbogen.com/2008/02/04/MicrosoftCCRCleanWayToWriteParallelCodeInNet.aspx
and I keep getting that fuzzy "I'm not really getting it" feeling :(

Also, does anyone know what impact CCR has on performance? I'm
planning to use it on a data intensive server that requires very fast
responses to a large volume of small bits of data. Might CCR
significantly slow me down?

As usual - many thanks in advance!
Uri

[Ken Egozi]

It was actually Oren Ellenbogen.  I actually have also missed that session.

There is some stuff on CCR on his blog - www.lnbogen.com

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.gotfriends.co.il

[Reshef Mann]

Try to take a look a Retlang. I found it more intuitive to work with than CCR.

[Uri Goldstein]

Thanks Ken and Reshef.

Retlang looks very interesting for me Reshef, do you maybe know of
real world applications using Retlang that I can showcase?

One thing that I see Retlang promising is "that the messages are
delivered to each subscriber serially and in order". Would anyone
happen to know if the same can be achieved with CCR?

I've taken a code sample from http://msdn.microsoft.com/en-us/magazine/cc163556.aspx
:

private static void MultipleItemDemo(DispatcherQueue dq) {
Port<String> stringPort = new Port<String>();
Arbiter.Activate(dq,
Arbiter.MultipleItemReceive(true, stringPort, 10,
delegate(String[] strings) {
Msg("Ten strings={0}", String.Join(", ",
strings)); }));

for (int i = 0; i < 50; i++) stringPort.Post(i.ToString());
}

And when I ran it on my dual-core machine I've come up with non-serial
results, as opposed to what's shown in the article.

This poses a problem for me is as I need to have my data ordered in
the same sequence as it was inputted. Any idea how to achieve that in
CCR?


Thanks
Uri

On Mar 2, 2:08 pm, Reshef Mann <reshef.m...@gmail.com> wrote:
> Try to take a look a Retlang <http://code.google.com/p/retlang/>. I found it

[Lior Friedman]

Hi,

I've been thinking it's about time I'll give GIT a try.
So what do I need in order to get the most out of it?
What extension to make my life easier as a .net developer working under VS
IDE?

Lior Friedman
Agile Consultant - AUT/TDD Expert | Mobile:
972.52.833.3660 | Email: lfri...@gmail.com
Blog  - http://imistaken.blogspot.com

[Ken Egozi]

get GitExtensions.  it's quite nice, and installs all the needed stuff (msysgit and kdiff3)

TortoiseGit is in the make, but very buggy currently.

2009/3/2 Lior Friedman <lfri...@gmail.com>

[Lior Friedman]

 

Ok ill start there.

I also saw a some nice beginner materials on the GIT main site. Any thoughts about them?

 

On a different matter doesn’t Alt.Net USA give us the urge to have ALT.NET IL 2?

 

Lior

[Ken Egozi]

materials are good.
take a look at GitHub's website. they also have tutorials. very good ones actually



as for alt.net IL 2 - on a new thread

[Ohad Israeli]

I haven't been able to respond earlier... but I'll just add that during the
last month I had several talks with George Chrysanthakopoulos the MS CCR &
DSS architect and after a poc it really looks like a great framework.

Last Thursday we had a 4hr overview about a commercial product by the name
of RTI DDS (http://www.rti.com/) which looks like WOW but then... it has its
price which I haven't received yet :-)

The other tool is great as a multi platform engine as it does support
C,C++,C#,Java, Corba, VxWorks,Windows, Linux etc... and work FAST !

Ohad.

[Reshef Mann]

I am using retlang for an application we are currently work on in my company. It is a real world application, not in production yet however we had no issues with retlang in the load tests.

[Ohad Horesh]

Hi Lior

An article about the basic differences between GIT and other VC's like svn
http://www.ericsink.com/entries/dvcs_dag_1.html

On Mon, Mar 2, 2009 at 9:01 PM, Lior Friedman <lfri...@gmail.com> wrote:

--
Ohad.

[Oren Ellenbogen]

As Ken said, I did a ~15 minutes talk on CCR in the last alt.net.

I'm considering preparing a lecture on the subject (and some common problems & solutions for concurrent development), is there any interest on the subject? if so - are you interested in 400+ level or just an overview of the solution and possible usages?

Uri, regarding your question, if the order of the items is important for you (which means you've got dependency between items, this is a big no-no in concurrent programming, most of the time), what do you gain from trying to parallelize the process? you probably should parallelize multiple processes and leave the internal flow sync (unless there is major gain inside that I'm not aware of), so instead of doing:

Request -> [ PARALLEL work, somehow, that is order specific ] -> Done.

[PARALLEL] -> Request -> sync work -> Done

Another option is to extract independent work, do it in parallel and then sync the work to make sure it runs in order (you can define 2 ports and use Arbiter.Interleave with Exclusive on the serial port and Concurrent on the parallel port).

Anyway, I need more details in order to come up with a real solution. You can contact me directly if you want (if you feel it's too "CCR specific" for the group)..

Cheers,

Oren.

On Tue, Mar 3, 2009 at 9:48 AM, Reshef Mann <reshe...@gmail.com> wrote:

I am using retlang for an application we are currently work on in my company. It is a real world application, not in production yet however we had no issues with retlang in the load tests.

--
Cheers,
Oren.

:: Visit my blog: http://www.lnbogen.com/

[Uri Goldstein]

Hi Oren,

Thanks very much for your help and for the good resources you've put
online about CCR. I will send you an email with the specifics of my
case.

I would love to hear your talk more about CCR. I would personally
prefer a thorough introduction to a 400 level deep dive.

What about comparing Retlang with CCR?


Uri

On Mar 9, 12:17 pm, Oren Ellenbogen <oren.ellenbo...@gmail.com> wrote:
> As Ken said, I did a ~15 minutes talk on CCR in the last alt.net.
>
> I'm considering preparing a lecture on the subject (and some common problems
> & solutions for concurrent development), is there any interest on the
> subject? if so - are you interested in 400+ level or just an overview of the
> solution and possible usages?
>
> Uri, regarding your question, if the order of the items is important for you
> (which means you've got dependency between items, this is a big no-no in
> concurrent programming, most of the time), what do you gain from trying to
> parallelize the process? you probably should parallelize multiple processes
> and leave the internal flow sync (unless there is major gain inside that I'm
> not aware of), so instead of doing:Request -> [ PARALLEL work, somehow, that
> is order specific ] -> Done.
> [PARALLEL] -> Request -> sync work -> Done
>
> Another option is to extract independent work, do it in parallel and then
> sync the work to make sure it runs in order (you can define 2 ports and use
> Arbiter.Interleave with Exclusive on the serial port and Concurrent on the
> parallel port).
>
> Anyway, I need more details in order to come up with a real solution. You
> can contact me directly if you want (if you feel it's too "CCR specific" for
> the group)..
> Cheers,
> Oren.
>

[Ariel Raunstien]

Ok, masters of all that is SCM - 

Git vs. Mercurial. Any thoughts?

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "altnetisrael" group.
To post to this group, send email to altnet...@googlegroups.com
To unsubscribe from this group, send email to altnetisrael...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/altnetisrael?hl=en
-~----------~----~----~----~------~----~------~--~---

[Dotan N.]

This is a flammable subject :)

They are very similar, with a some what similar time line. mercurial/HG is implemented in python, Git in C. i dont care about the python part and i really believe in dropping the "performance" arguments in favor of correctness and usability.

BUT:

Use Git.

From my experience i can draw on RAW numbers that Git is faster, more efficient and it in the case of distributed SCM, it matters. in distributed context you'll be checking out entire repos every time, you'll be branching and merging more than you are used to. one example is that the metadata size in Git for a 1.3GB repository i'm using was 120mb, in HG it was ~400. Git was faster.

Git gives you flexibility, HG supports the 'one way' notion.

under windows, intuitively, i believe Git will be a better decision in the long term.

--

You received this message because you are subscribed to the Google Groups "altnetisrael" group.

To post to this group, send email to altnet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altnetisrael?hl=.

[Ori Peleg]

Pick one and go forward.

There are countless arguments for and against, and they're all bunk.

On Wed, Nov 11, 2009 at 12:15 PM, Ariel Raunstien <ari...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "altnetisrael" group.

To post to this group, send email to altnet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altnetisrael?hl=.

--
Check out my blog: http://orip.org

[Ariel Raunstien]

Dotan - what about the "Git is more complicated to use than HG" line? Any truth to that?

Ori - yes, but I wanted someone else to do the picking for me. :)

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Dotan N.]

Ariel, theres no truth to that. i know it sounds a bit smug, and i've read it, been skeptical about it, tried Hg, Bzr, and then Git, but git really is simple in terms of workflows.

so far i'm ok with the command line. i'll be honest and say i'm not using it under heavy enterprise grade development so i'm not familiar with pitfalls of using Git (or any DSCM for this matter) in complicated scenarios.

under windows all it takes is a bit of googling to find tortoisegit, and msysgit.

In the windows world, HG and Git are so similar in terms of workflow and terminology you might be confused if you run them side by side, TortoiseHg is pretty mature, but ugly and wierd in terms of UI, TortoiseGit is ok although under heavy dev. -- and it seems to be a port of TortoiseSVN which looks and feels much better..

[Ariel Raunstien]

Ok, cool.

Thanks.

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Ken Egozi]

There's GitExtensions which is wrapping all of the needed windows stuff for git in a simple installer, and adds a useful GUI (which can do most of what git-gui and gitk can, plus most of the daily command-line things).

my personal TortoiseGit experience was poor, but it was quite some time ago, it might have gone better with time.

For day-to-day I find the combination of GitExtensions and the commandline productive enough.

I'm not using git at work though, only for small, personal projects.  I did use it for work on a team of 5 people, divided across  continents, and the experience was great,  far superior than any non dscm

http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם

[Dotan N.]

Ken,
for the 5 people team, what was the size of the repository?

[Ken Egozi]

quite large. I do not recall exact numbers though.

SVN was a pain in the neck. using a remote server (we used hosted solutions) a merge was taking 40minute to 1hr.

after moving to git (also remote - on github), it came down to a couple of seconds.

[Ariel Raunstien]

A poor merge experience broke me too.

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Lior Friedman]

If you won’t branch,

You won’t need to merge.

 

And then you could stop spending your time on evaluating SCM’s which for most is not that interesting.

(at least not as interesting as adding new functionality to your product)

 

Lior Friedman
Blog  - http://imistaken.blogspot.com

[Ken Egozi]

With large enough team (>5 usually, >10 most certainly), feature branches will be a must

With a web-based product that have short release cycles (and actually with most products), release branches will be a must

under these assumptions, you'd want the fastest, most flexible, low friction tool.

imo - GIT is the one.

[Ariel Raunstien]

I'm Gitting for a couple of days now and it's very nice. Basically - I only miss one thing from SVN: SVNMonitor, which lets me know when there are available updates.

Now I have to randomly sync my repository. Which is silly.

Actually, VisualSVN also grew on me rather quickly (used it for only a week or so), and I really liked to be able to "Commit" by rightclicking on the code window's tab.

Hmm... That could be a really simple VS addin to implement... 

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Ariel Raunstien]

Oh, and Lior - I agree that branching is "not fun", but you have to agree - it is a must. I've had to do it for a team of only two developers.

With DSCMs you don't have to branch as much because you can "Commit" without "Pushing".

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Lior Friedman]

Hi Ariel,

 

Just to make sure I understand your context,

You MUST branch because you work in a big company that has clients using an older version of your product, refusing  to upgrade while still demanding bug fixes on that specific older version they use?

 

If by any chance you are working in a small company with no paying customers (yet), or with a product who has yet to be release.

Then I think MUST is not really appropriate. In fact I think that AVOID would probably serve you better.

 

Ken, the following link should be relevant:

http://martinfowler.com/bliki/FeatureBranch.html

[Ariel Raunstien]

Nothing is a must, ok.

I do have customers who may not be paying, but I do have their best interest at heart, and since I'm still with an unstable product - I want the ability to release a bugfix version within minutes.

The point is that it shouldn't BE hard. It can be done better. So no, the excuse that "it's hard to merge is SVN, so don't branch on any SCM" does not stick. :)

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Lior Friedman]

And branching is your solution for that?

I think that there are other better ways to be able to release bug fixes within minutes without resorting to branches.

 

Actually, the reason I don’t like branches is completely different.

For the long version:

http://imistaken.blogspot.com/2008/10/source-branches.html

and http://imistaken.blogspot.com/2009/09/branching-is-evil.html

 

The short version:

Branching is the easy way out, the longer the branch the higher the risks and the harder it will be to integrate back.

Also working on a single main source line, encourages higher quality standards and higher quality (as I think you already heard me saying) is the best/only way to become more productive.

 

The added bonus of choosing not to branch is that you then don’t have a merge problem (ever).

 

BTW, I don’t have a stand about SCM’s in some contexts (e.g. a single programmer working with the SCM server just under his feet) SVN does a great job, and GIT from what I’ve seen is an excellent system as well.

[Ariel Raunstien]

I'll ask you this: you have a desktop product, and about to undergo a complete UI re-write. How would you've approached it?

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Lior Friedman]

Divide and Conquer,

 

I would try, splitting it the work one window at a time,

after each window is “Done”

and by “Done” I mean at least: implemented, tested and explored.

I would commit it into the mainline.

 

And yes the trick, is how to split the UI into meaningful windows which are mostly independent and can be added into the product without making the entire application useless.

 

BTW what’s the purpose of the entire rewrite?

Is it a cosmetic change aiming to make things just look better? A logical change aimed at improving the user experience? Or just a general cleanup aimed to make the internal code structure better?

 

The tactic for splitting the work will probably differ depending on the context.

Lior

[Dotan N.]

what if two developers must work on that...

[Lior Friedman]

On the same single window at the same time?

Why are they doing so?

 

But how about putting them on the same machine?

I’m dead serious. This practice even have a big name: Pair Programming, and deserves it own discussion.

 

More to the point how exactly branching will help this cause? I must be missing something, I thought branching is used in order to avoid the need to share your changes until they are done.

I think the scenario you referring to is covered by basic usage of SCM. And really does not warrant a full pledged branch.

 

That being said, to some extend each time you work on a local copy it can be viewed as a “branch”.

Obviously this is not the kind of branching which is in question here.

 

 

 

 

From: Dotan N. [mailto:dip...@gmail.com]
Sent: Monday, November 16, 2009 12:47 PM
To: altnet...@googlegroups.com
Subject: Re: Using GIT

 

what if two developers must work on that...

[Ariel Raunstien]

Announcing: ViGit!

The simplest VisualStudio Addin you'll ever see. Allows you to commit a single file from an action on the tab's context menu:

Download here: http://github.com/QuickUnit/ViGit/downloads

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Ken Egozi]

GitExtensions is nice

[Dotan N.]

on the same feature. interdependent too.
they have to commit to somewhere common which is not head

--

[Ariel Raunstien]

Not Tortoiseish.

Pity.

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Ken Egozi]

you don't need the tortoise-ish thing. just fire up Git-GUI and you get the changed files listed in front of you, with the relevant diff next to it. *way* better (and faster) than Tortoise's commit dialog

[Lior Friedman]

I really think that most likely they should pair.

 

Also I kind of suspect that I would try to avoid such a scenario in the first place,

or make it so short as not to include usage of the SCM at all.

 

But if you are working on a big feature that you can’t break to independent tasks, and you have more the one person working on that.

You are not at a very good place to begin with are you?

 

 

From: Dotan N. [mailto:dip...@gmail.com]
Sent: Monday, November 16, 2009 4:43 PM
To: altnet...@googlegroups.com
Subject: Re: Using GIT

 

on the same feature. interdependent too.

[Ariel Raunstien]

"I don't need", but I want. I really don't want to learn a new GUI.

Arielr, Tortoising since 2009.

http://blogs.microsoft.co.il/blogs/ariel/

[Ken Egozi]

hmm - coming from the guy who is just replacing the GUI for his product ...

[Ariel Raunstien]

That's ok, no one got used to it yet.

Speaking of which...

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Dotan N.]

On Mon, Nov 16, 2009 at 5:37 PM, Lior Friedman <lfri...@gmail.com> wrote:

I really think that most likely they should pair.

 

Also I kind of suspect that I would try to avoid such a scenario in the first place,

or make it so short as not to include usage of the SCM at all.

 

But if you are working on a big feature that you can’t break to independent tasks, and you have more the one person working on that.

you can break it but you cant break it to purely independent tasks. its called reality :)

You are not at a very good place to begin with are you?

 

 

From: Dotan N. [mailto:dip...@gmail.com]
Sent: Monday, November 16, 2009 4:43 PM

To: altnet...@googlegroups.com
Subject: Re: Using GIT

 

on the same feature. interdependent too.

they have to commit to somewhere common which is not head

--

[Lior Friedman]

Yes, reality does tend to interfere ;)

And I don’t have clear cut answer for this situation.

 

I just know that for every problem there is more than a single solution , and that Branching  is usually

very low on that list.

 

Lior

 

 

From: Dotan N. [mailto:dip...@gmail.com]
Sent: Monday, November 16, 2009 7:36 PM
To: altnet...@googlegroups.com
Subject: Re: Using GIT

 

 

On Mon, Nov 16, 2009 at 5:37 PM, Lior Friedman <lfri...@gmail.com> wrote:

[shovavnik]

I think there is a psychological aspect to this argument.

Those of us who "grew up" using Microsoft's traditional SCM's and had
to suffer the poor support for merging and branching have developed an
ingrained aversion to merging, almost a reflex. Seems to me that most
(but definitely not all) of the reasoned arguments against branching
and merging are based on poor experience.

I read an interview recently where Torvalds was asked about the
reasons for developing git, yet another DSCM for the Linux kernel.
Essentially, his argument was that he wanted to develop a DSCM that
would make working with branches much easier, with merging as a goal
to improve progress and communication between disparate teams, rather
than an impediment to progress.

It's possible this has to do more with the nature of the open source
world, and the linux kernel in particular, but what struck me the most
was the attitude that sees branches as an obviously useful tool-of-the-
trade and merging as a device for communication.

So unlike Lior, Torvalds et al generally see branching as a preferable
solution over the alternatives.

Noam

On Nov 16, 8:22 pm, "Lior Friedman" <lfried...@gmail.com> wrote:
> Yes, reality does tend to interfere ;)
>
> And I don't have clear cut answer for this situation.
>
> I just know that for every problem there is more than a single solution ,
> and that Branching  is usually
>
> very low on that list.
>
> Lior
>
> From: Dotan N. [mailto:dip...@gmail.com]
> Sent: Monday, November 16, 2009 7:36 PM
> To: altnet...@googlegroups.com
> Subject: Re: Using GIT
>

[Lior Friedman]

Hi Noam,

can you post the link?

Lior

[Ori Peleg]

I'm not sure this was shovavnik's source, but he talks about it in this good tech talk:

http://www.youtube.com/watch?v=4XpnKHJAok8

--

You received this message because you are subscribed to the Google Groups "altnetisrael" group.
To post to this group, send email to altnet...@googlegroups.com.

To unsubscribe from this group, send email to altnetisrael...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/altnetisrael?hl=.

[Ariel Raunstien]

+1

Arielr

http://blogs.microsoft.co.il/blogs/ariel/