GWT, Volta, and Cloud Computing
Ray Cromwell
Someone at the conference asked about this at the close (GWT and
Android). For those interested, I put up an article on my experiences
in doing this at: http://timepedia.blogspot.com/2007/12/cloud-computing-and-gwt.html
Nothing earth shattering, since most of it is self-evident, except for
perhaps some of the 'gotchas' you might encounter when trying to go
the mobile route.
-Ray
Joel Webber
Andrés Testi
On 10 dic, 14:02, "Joel Webber" <j...@google.com> wrote:
> Yay to Microsoft for validating our approach :)
>
Ray Cromwell
ever a platform which could do cloud computing, it was Applets +
Servlets, as both the server and client ran a full J2SE, practically
identical platforms. Where it all breaks down is the idea of
pretending that RPC calls can be abstracted away and that you can just
ignore serialization/marshalling.
In the pre-J2EE days, I developed several CORBA/RMI-ized applications
(anyone remember Netscape's IFC and CORBA ORB in their browser? :) ),
working with junior programmers, and one of the common mistakes I saw
was people remoting functions left and right, as well as sending huge
object trees around. Even today with GWT RPC, we still see this as
people slurp huge database queries into an object graph and try to
send thousands of objects through an RPC call.
The "beauty" of REST/JSON/etc is that the abstraction forces one to
think about the dataflow issues, which are what kills user experience.
I like GWT RPC, and the one thing it has going for it that Volta
doesn't, is that it forces you to take notice that you're making an
RPC call and maybe think about the implications of it. It makes thing
just easy enough to justify using it, while hopefully not making it so
easy that you forget the data you're sending around. (well, I'd also
argue that IsSerializable forced people to re-think what they might be
marshalling)
I mean, we all dream of a toolkit platform which removes the burden of
having to think about dataflow and network I/O, but I really don't
think anything short of Strong AI compilers are going to deliver it.
:)
-Ray
Rob Jellinghaus
> Where it all breaks down is the idea of
> pretending that RPC calls can be abstracted away and that you can just
> ignore serialization/marshalling.
how to know what's going over the wire when you declare something as
[RunAtServer] in Volta.
At least they admit that it's early days :-) From
http://labs.live.com/volta/docs/issues.aspx :
"The serialization between the two tiers is not very fast."
As well, I'm not clear that their MSIL->Javascript compiler can do as
much structural optimization as GWT does. I talked to Ben Livshits at
GWT2007 about this, though, and since MSIL preserves all generic
information (e.g. MSIL doesn't do type erasure), there's evidently no
reason in principle they couldn't optimize to GWT-like levels. I'm
still unsure whether targeting all MSIL-compilable languages would
limit the kinds of structural assumptions they can make.
In Microsoft's defense, the size/performance issues are things they
may well be able to make substantial headway on over time. This is a
very first technology preview. I think the jury's still out on
whether declarative tier splitting -- writing your server and client
code as a single unified codebase -- will wind up being an abstraction
stretched too far, or a real boost to productivity.
If you cross your eyes and think about it flexibly enough, the people
who want the GWT compiler to be able to selectively ignore Java server
code that isn't client-relevant are actually walking very much in the
direction of Volta. If the GWT compiler could flexibly extract pieces
of (annotated) code to be compiled to the client, and if the GWT
compiler also had some funky logic for doing asynchronous code
splitting (so you could write straight-line code that would get
callbacks injected automatically), then you'd basically have Volta!
Except the performance would probably be better, since GWT has a
couple years of optimization behind it already :-)
Cheers!
Rob
Andrés Testi
> compiler also had some funky logic for doing asynchronous code
> splitting (so you could write straight-line code that would get
> callbacks injected automatically), then you'd basically have Volta!
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_frm/thread/4239559936d327e7/8ddd943d6186998e
Ray Cromwell
I would certainly not suggest assuming Volta performance won't get
better. Microsoft has very talented compiler engineers, I've seen them
come back with world-beating optimizations from crappy 1.0 versions on
two occassions, the first was their Java VM, which eventually had the
best performance bar none until Hotspot and IBM JDK. Then, with pixel
shader compilers on graphics cards, they went from having a really
crappy HLSL compiler (worse than NVidia's Cg) to having really awesome
output, which was especially an issue on DirectX8 cards which required
alot of logic to pack SIMD ALUs for maximum efficiency.
Whatever problems Volta has now with optimized code, I'm sure by
Version 2.0, they'll be giving GWT a run for their money. I just don't
think tier-splitting will really pan out, decisions on
dataflow/network I/O should not be postponed until later on the hope
that the compiler/tool can solve them for you. Maybe I'm completely
off my rocker, but I don't see how code that makes the assumptions
that massive object graphs which are passed by reference between
in-process method calls can be automagically offloaded to the client.
Of course, the ultimate problem of Volta in my opinion, is that it
isn't open source, and requires $$$ MS tools. I'm on OSX and Linux, so
it doesn't serve me. :)
-Ray
Matthew Mastracci
> Whatever problems Volta has now with optimized code, I'm sure by
> Version 2.0, they'll be giving GWT a run for their money. I just don't
> think tier-splitting will really pan out, decisions on
> dataflow/network I/O should not be postponed until later on the hope
> that the compiler/tool can solve them for you. Maybe I'm completely
> off my rocker, but I don't see how code that makes the assumptions
> that massive object graphs which are passed by reference between
> in-process method calls can be automagically offloaded to the client.
experience with Microsoft's developer tool strategy.
Microsoft's focus for platform version 1 tends to be on ease-of-use
and the "gee whiz" factor - making really neat looking presentations
for the next developer day or PDC. By making it easy for a developer
to get themselves up and running with a technology, they hook
developers early during their "version-next" prototyping stage. You
don't tend to notice how slow things run when you're prototyping your
next application or next version.
Once they've completed a decent gamut of demoable features,
performance and correctness tend to be the focus for version 2+.
I agree with Ray that they'll try to give GWT a run for their money.
For GWT to hold its own in the long run, it'll probably need to
integrate better into Eclipse so that new GWT developers can point
Eclipse at the GWT update site, install the package and be up-and-
running with a template GWT project within five minutes. If the
template projects are sufficiently compelling, I imagine that GWT can
hook a large chunk of developers looking for an easier path to web
development. It might also be necessary to develop PHP, Python or
Ruby RPC integration to get people up-and-running faster.
Rob Jellinghaus
> Whatever problems Volta has now with optimized code, I'm sure by
> Version 2.0, they'll be giving GWT a run for their money. I just don't
> think tier-splitting will really pan out, decisions on
> dataflow/network I/O should not be postponed until later on the hope
> that the compiler/tool can solve them for you.
http://lambda-the-ultimate.org/node/2563
Some interesting links in there to research on automatically
evaluating and optimizing server-client communication patterns. I
posted some specific questions on these issues for him, we'll see what
he says if anything.
One of Meijer's goals is to solve the "what goes over the wire, and
when?" problem at the framework level rather than making all app
developers deal with it. I agree that it's trying to push remoting
abstraction a lot further than it's yet been pushed, and I agree that
all experience to date would show that trying to make RPC transparent
is a Bad Thing. But then again, we also have seen that even researchy
ideas (like garbage collection! and dynamic code loading! and whole-
program optimization!) that were once considered not ready for prime
time do eventually make it into the mainstream. So, you never
know....
Anyway, I also agree that Microsoft's closed-source nature will likely
continue to prohibit them from taking over the world, and thank
goodness for that since competition is A Good Thing. But learning
from the competition is ALSO a Good Thing.
Cheers!
Rob
Ray Cromwell
I read that article before and the mention of Links, but it seems to
suggest they do nothing more fancy that defaulting to running methods
in the same tier as the call site. Volta, for example, makes bold
claims, but the demos show otherwise: Hundreds of http requests!
Consider the simplest example:
public int calculateTotalCosts() {
Collection<Cost> costs = loadCosts(costsQuery);
int total = sum(costs);
return total * 110/100;
}
public int sum(Collection<Cost> costs) {
int sum = 0;
for(Cost : cost) sum += cost.amt;
}
Now, loadCosts returns a variable amount of data from a data store
(RDBMS, XML, etc). If the amount is small, you could run those two
functions on the client, and retrieve the data via AJAX, but if it is
large, it is best to run them at the server, and make
calculateTotalCosts a stub function which delegates to the server.
Observations:
1) static compiler can't know how much data will be returned by
loadCosts at runtime without profile feedback
2) With profile feedback, solution to #1 is to compile those functions
on the client, and use a guard to select client side
or server side version. (whether to call loadCosts directly, or
call calculateTotalCosts via AJAX)
3) Guard adds extra round trip to check size of loadCosts
4) #3 could be eliminated potentially with a predicate guard: "Try to
loadCosts, if it is too large, implicitly call calculateTotalCosts on
server and return that result, else, return the data itself"
5) code still bloated in case where loadCosts never returns small dataset
6) Synchronous calls hurt app responsiveness
7) Debugging and exceptions could be very tricky and problematic
I think at this point, it may be more trouble than its worth. I spent
a lot of time in my early years doing assembly programming and writing
graphics code to run fast by maximizing system performance, and
perhaps it's my bias, but I think the best way to make an AJAX app fly
is to design up front with dataflow and I/O in mind, rather than
trying to forget about it. The example I gave above gives the
impression that automated tier splitting is very workable, but
consider what happens if you've got 30-40 of these kinds of business
logic calls, is the compiler going to prioritize which ones should
trump others? is it going to place a maximize cap on amount of allowed
I/O? Is it going to switch encoding methods for you as needed? (for
example, look at Google's Chart API sends data in the URL)
It's an interesting academic exercise, but it seems to me it will be a
long time before this kind of compiler will deliver a better
experience than hand-split GWT designs. This reminds me of the
problem of mutation in functional languages (solved by Monads in
Haskell or stric/uniqueness annotations in Clean :) ). We've all seen
the 1-3 line quicksort in function languages, but of course, the real
quicksort sorts in place, and this runs alot faster on modern CPU
cache designs. So, there have been varying attempts to make the
compilers smart enough to auto generate mutate-in-place code. One
variant of this requires you to write your code in a Linear Logic
style, another I've seen uses special Monads with compiler intrinsics
(kind of cheating), in any case, you probably know more than I, that
there is a difference between writing clean, elegant, idiomatic
Haskell, and writing "high performance haskell", and ironically, you
see people falling back to imperative idioms to gain back performance
in some cases. This is a case where the academic ideal, the beautiful
code, is not the best performing code. (C++ has been doing great in
ICFP competitions recently :) )
Perhaps Volta will be like Ruby on Rails. It will get your multi-tier
AJAX up and running really fast when it is simple. Then, once the
compiler starts failing you and performance suffers, you'll be forced
to go do hand-tuned tier-splits everywhere. I guess in this way,
Microsoft can sell you snake oil up front.
I think Volta is a nice R&D project, but the core concepts I think
need probably years of baking in Microsoft's labs before they are
unleashed on end users.
-Ray
Rob Jellinghaus
forums :-) Or maybe I'll do so and channel you!
Cheers!
Rob
http://robjsoftware.org
Reinier Zwitserloot
Ray didn't even BEGIN to touch on the hairyness of this issue. As a
practical matter, in the above situation, the server can always do the
sum calculation. If the data is large, it's a definite improvement,
and if the data is small, it really doesn't matter who calculates it.
However, the client might want the data in the raw if the client will
later proceed to draw each individual entry along with the sum to the
user, for example. -or-, if the client needs to do a bunch of other
calculations on it later, or even if the client -might- draw the
results later. So how do we know the client might need the individual
data at a later time?
I wonder if you can ever really suss that out by just looking at the
code, the halting problem being what it is. You probably need a
'transaction descriptor' or some such, which explicitly mentions
likely future intent for each data request. Once you're there, the
mental leap to just manually specifying whether the data must come
from the server or the client is almost non-existent. Specification
really must be done. Even in the hypothetical situation that the
compiler can make an educated guess, what if the client will want the
data refreshed a lot? Then it wouldn't make a difference again. Now
the compiler also needs to guess how much time will pass between
related events and compare it to the cache timeout value. We're in
deep, deep, uncharted AI territory at this point. If we can solve this
problem, this stuff will only be a minor blip on the radar of things
we need to completely rethink.
No. The advantage of 'cloud computing' in this sense is simply that
you can manually move code from one place to the other simply by copy
and pasting. GWT must learn from this, yes. But the lesson is hardly
needed. With GWT 1.5, you no longer need to wrestle with old-style
java code for your shared code base. Emulation wise, GWT could do with
a bit more classes emulated, but given that the target platform is
javascript, emulation is very limited regardless. The final and most
important lesson of the day:
Investigate if its possible to compile class files into GWT as well as
java files. It would be nice if you could use this to compile e.g.
scala into javascript as well. Practically speaking though, such a
change still won't really allow you to write GWT code in ruby or
python (via jruby/jython) unless the jruby/jython code is heavily
annotated with type info. A crucial element to GWT is dead code
elimination, and you can't do it if the language allows DMP. Python
and Ruby aren't very usable languages if you can't use any DMP
functionality. It's just not that kind of language type. You'd mostly
be doing the effort for scala's sake, I imagine.
Ray Cromwell
As an aside, I imagine Scala would need its own "JRE emul" classes, as
the scala.* packages are probably dependent on some stuff that is not
translatable, so you'd have to reduce those down to a workable set and
eliminate non-translatable methods.
One question that arises is if Scala's better type system would allow
GWT to make better optimization decisions, which might imply that a
Scala AST -> JS AST would still have advantages over
Scala->bytecode->reconstructed Java AST->JS AST.
-Ray
Andrés Testi
proposal :P
I'm a Scala fan too ;)
Reinier Zwitserloot
use reflection? I get the nagging feeling Ray is right; translating
directly from scala source to javascript will have significantly
better results compared to class files. But I'm no scala guru (I have
yet to do more than write toy apps in it. Next project! Honest!).
Andrés Testi
>
> leer más >>
Bruce Johnson
Ray Cromwell
AST->bytecode layer, and either creating a Java AST out of it (that
GWT can consume) or JS AST (but you'll miss the Java AST
optimizations) The only benefit of bytecode compilation is that you'd
pick up alot more languages automatically, but every language (JRuby,
JPython, Groovy, PHP, etc) has its own class library, and so you'd
have N different implementations class library emulation layers (like
JRE Emul). So you don't really gain that much.
Actually, as much as I like Scala, the more interesting thing I'd like
to see is ActionScript+SWF generation. I'd like to put "Actionscript"
translatable source in a .asclient package, and have GWT separately
compile this into AS or HAXE and even produce an SWF from it. The
purpose of this would be Flash libraries callable from GWT and
painless Flash<->GWT interoperability. My primary motivation is so
that I can author the Canvas implementation in Java instead of raw AS
and not have to maintain a non-GWT codebase manually.
That is, I'd like
org.timepedia.chronoscope.client.canvas.FlashCanvas
to be the Javascript stub interface that captures the display list, and
org.timepedia.chronoscope.asclient.canvas.FlashCanvasRenderer
to be the Actionscript code (written in Java) that turns display lists
into MovieClip calls.
And I'd want GWT to recognize the existence of an "asclient" package
and run a separate compilation pass for it.
:)
-Ray
Bruce Johnson
Ray Cromwell
To be honest, I've never tried to load GWT compiled JS into an
ActionScript environment. I think ActionScript is missing some
methods on the String class, doesn't have Regexp natively IIRC, and
may have some other core differences the builtin Javascript objects.
There's also the ability to define packages, classes, and methods, all
with strong types without resorting to prototype-based inheritance
(ala JS2/EC4) This may have performance implications when running in
the ActionScript VM, so it might be valuable to investigate this, and
if a super-set of the JS AST is needed to preserve types/classes, so
that final code generation could produce class/type based AS.
However, what I would like is integrated compilation of multiple
code bases in different deployment platforms. That way, my Java GWT JS
code can be strong-type checked against my Java GWT AS code, in much
the same way that I get strong type checking when making RPC calls
from client to server today, I'd like strong type checking for
Browser<->Flash calls or Browser<->Gears Worker.
Of course, this all sounds like a GWT2.0 feature for Q1 2009. :)
-Ray