Received: by 10.68.233.69 with SMTP id tu5mr1430789pbc.6.1334238995661;
Thu, 12 Apr 2012 06:56:35 -0700 (PDT)
X-BeenThere: nodejs@googlegroups.com
Received: by 10.68.222.193 with SMTP id qo1ls7219170pbc.9.gmail; Thu, 12 Apr
2012 06:56:26 -0700 (PDT)
Received: by 10.68.201.164 with SMTP id kb4mr343811pbc.12.1334238986577;
Thu, 12 Apr 2012 06:56:26 -0700 (PDT)
Date: Thu, 12 Apr 2012 06:56:25 -0700 (PDT)
From: alessioalex <alessio.ijoo...@gmail.com>
To: nodejs@googlegroups.com
Message-ID: <26032957.1122.1334238985885.JavaMail.geo-discussion-forums@vbyz30>
In-Reply-To: <EE71A037-7215-400B-90B3-59A37664CA8C@jorgechamorro.com>
References: <28019445.11.1334175762094.JavaMail.geo-discussion-forums@ynww4> <9929160.82.1334186652157.JavaMail.geo-discussion-forums@pbep2>
<EE71A037-7215-400B-90B3-59A37664CA8C@jorgechamorro.com>
Subject: Re: [nodejs] Re: When fibers beat handwritten callbacks by 10 to 1
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_1120_11550383.1334238985844"
------=_Part_1120_11550383.1334238985844
Content-Type: multipart/alternative;
boundary="----=_Part_1121_14899101.1334238985844"
------=_Part_1121_14899101.1334238985844
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
If you want sync code that badly, why don't you use EventMachine instead
with fibers? You write sync language in Ruby, so it's natural to write
"sync-style" code in EventMachine also.
JavaScript is asynchronous, Node.js is asynchronous, everything feels
natural (and fibers don't).
> Please stop with "the performance hit" bs, thanks.
Just because you make a wrong benchmark doesn't mean anything.
On Thursday, April 12, 2012 3:32:34 PM UTC+3, Jorge wrote:
>
> On Apr 12, 2012, at 1:24 AM, Marco Rogers wrote:
>
> > I would've hoped you had more fortitude against the attacks on
> streamline then to start throwing around hastily designed benchmarks to
> prove your point. It sucks that the "sync-looking" advocates have to deal
> with the level of aggression they do here. I've expressed that to some
> people myself, even though I don't advocate these solutions either. But
> this is almost certainly not the way to win hearts and minds.
> >
> > When you create an abstraction layer, it's almost always slower. That's
> just something you're not going to get away from.
>
>
> That's wrong, StreamLined code does not have to be any slower because it
> simply writes the JS for you:
>
>
> > On Apr 10, 2012, at 10:35 PM, Bruno Jouhier wrote:
> >
> >> Streamline translates its special syntax to vanilla JS with callbacks.
> So, if you implement a function like
> >>
> >> function foo(x, y, _) { ... }
> >>
> >> Normal JS modules (not written with streamline) will be able to call it
> as:
> >>
> >> foo(x, y, function(err, result) { ... });
> >>
> >> Streamline is just a tool that helps you write your code. This tool
> produces vanilla JS that follows the standard node callback conventions. So
> you can publish it to NPM, you won't be forcing anyone else to use
> streamline. (...)
>
> > On Apr 10, 2012, at 11:01 PM, Axel Kittenberger wrote:
> >>
> >> Its not like Bruno is doing an evil plot here. Since as long your
> >> benchmark does not compare apple with oranges, it will always be just
> >> as fast as vanilla written code, since in the end, it translates to
> >> vanilla code.
>
>
> > Even if the benchmark wasn't flawed, simply because you can contrive a
> scenario where it wins doesn't make up for the fact that it stills loses
> most of the time.
>
> Again, wrong. It simply writes for you the ~ exact vanilla JS code you
> would have had to write yourself.
>
> > Then on top of that, it becomes clear that streamline does some trickery
> in transforming to js that injects more cleverness. Hence the fact that
> your example doesn't require an explicit nextTick. So then you leave people
> with the feeling that if it is ever faster, it's because streamline has
> done some tricky optimizations in the background.
>
> Totally safe optimizations, as any other good compiler would do. Is that a
> bad thing too, in your opinion?
>
> > In my opinion, people who are interested in streamline and fibers will
> already be prepared to take the performance hit in exchange for ease of use.
>
> Please stop with "the performance hit" bs, thanks.
>
> > A better argument would be that you're committed to making that hit as
> small as possible. And assuring people that a 2x difference won't often
> make a huge difference in practice.
>
> You're making up numbers.
>
> > I agree with that, and I think it's easily defensible.
>
> Only if it were true, which it isn't.
>
> > This benchmark is not.
>
> FYI the benchmark is a reply to this:
>
> > On Apr 10, 2012, at 4:55 PM, Joe Ferner wrote:
> >> On Apr 10, 10:12 am, Bruno Jouhier <bjouh...@gmail.com> wrote:
> >>> @joeferner
> >>>
> >>> (...) From my experience there are code patterns where fibers beats
> callbacks 10 to 1.
> >>
> >> beats 10 to 1 how? in code readability?
>
> --
> Jorge.
>
------=_Part_1121_14899101.1334238985844
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
If you want sync code that badly, why don't you use EventMachine instead wi=
th fibers? You write sync language in Ruby, so it's natural to write "sync-=
style" code in EventMachine also.<br><br>JavaScript is asynchronous, Node.j=
s is asynchronous, everything feels natural (and fibers don't).<br><br>>=
Please stop with "the performance hit" bs, thanks.<br><br>Just because you=
make a wrong benchmark doesn't mean anything.<br><br>On Thursday, April 12=
, 2012 3:32:34 PM UTC+3, Jorge wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); =
padding-left: 1ex;">On Apr 12, 2012, at 1:24 AM, Marco Rogers wrote:<p>>=
I would've hoped you had more fortitude against the attacks on streamline =
then to start throwing around hastily designed benchmarks to prove your poi=
nt. It sucks that the "sync-looking" advocates have to deal with the level =
of aggression they do here. I've expressed that to some people myself, even=
though I don't advocate these solutions either. But this is almost certain=
ly not the way to win hearts and minds.<br>> <br>> When you create an=
abstraction layer, it's almost always slower. That's just something you're=
not going to get away from.</p><p><br>That's wrong, StreamLined code does =
not have to be any slower because it simply writes the JS for you:</p><p><b=
r>> On Apr 10, 2012, at 10:35 PM, Bruno Jouhier wrote:<br>> <br>>&=
gt; Streamline translates its special syntax to vanilla JS with callbacks. =
So, if you implement a function like<br>>> <br>>> functio=
n foo(x, y, _) { ... }<br>>> <br>>> Normal JS modules (not writ=
ten with streamline) will be able to call it as:<br>>> <br>>> &=
nbsp;foo(x, y, function(err, result) { ... });<br>>> <br>>> Str=
eamline is just a tool that helps you write your code. This tool produces v=
anilla JS that follows the standard node callback conventions. So you can p=
ublish it to NPM, you won't be forcing anyone else to use streamline. (...)=
</p><p>> On Apr 10, 2012, at 11:01 PM, Axel Kittenberger wrote:<br>>&=
gt; <br>>> Its not like Bruno is doing an evil plot here. Since as lo=
ng your<br>>> benchmark does not compare apple with oranges, it will =
always be just<br>>> as fast as vanilla written code, since in the en=
d, it translates to<br>>> vanilla code.</p><p></p><p><br>> Even if=
the benchmark wasn't flawed, simply because you can contrive a scenario wh=
ere it wins doesn't make up for the fact that it stills loses most of the t=
ime.</p><p>Again, wrong. It simply writes for you the ~ exact vanilla JS co=
de you would have had to write yourself.</p><p>> Then on top of that, it=
becomes clear that streamline does some trickery in transforming to js tha=
t injects more cleverness. Hence the fact that your example doesn't require=
an explicit nextTick. So then you leave people with the feeling that if it=
is ever faster, it's because streamline has done some tricky optimizations=
in the background.</p><p>Totally safe optimizations, as any other good com=
piler would do. Is that a bad thing too, in your opinion?</p><p>> In my =
opinion, people who are interested in streamline and fibers will already be=
prepared to take the performance hit in exchange for ease of use.</p><p>Pl=
ease stop with "the performance hit" bs, thanks.</p><p>> A better argume=
nt would be that you're committed to making that hit as small as possible. =
And assuring people that a 2x difference won't often make a huge difference=
in practice.</p><p>You're making up numbers.</p><p>> I agree with that,=
and I think it's easily defensible.</p><p>Only if it were true, which it i=
sn't.</p><p>> This benchmark is not.</p><p>FYI the benchmark is a reply =
to this:</p><p>> On Apr 10, 2012, at 4:55 PM, Joe Ferner wrote:<br>>&=
gt; On Apr 10, 10:12 am, Bruno Jouhier <<a>bjouh...@gmail.com</a>> wr=
ote:<br>>>> @joeferner<br>>>> <br>>>> (...) From=
my experience there are code patterns where fibers beats callbacks 10 to 1=
.<br>>> <br>>> beats 10 to 1 how? in code readability?</p><p>--=
<br>Jorge.</p></blockquote>
------=_Part_1121_14899101.1334238985844--
------=_Part_1120_11550383.1334238985844--
Message from discussion When fibers beat handwritten callbacks by 10 to 1
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |