[Swift-devel] faster branch

[Mihael Hategan]

I agree. My tests are not very glamorous. I usually do the following for
stress tests:

- language/interpreter: foreach(largenumber), fake provider
- coaster staging: many-cat, various file sizes
- basic coasters: foreach(largenumber), local:local with some reasonable
number of worker arrangements (i.e. 2 blocks * 2 workers per block * 2
concurrent jobs per worker).

I think these are pretty easy to construct (which is why I use them),
but I'll be happy to help with the details.

Mihael

On Thu, 2013-02-14 at 13:28 -0600, Michael Wilde wrote:
> Mihael, this is great.
> 
> I'm eager to see us assemble a good set of stress tests into a test-group, and then apply it to both 0.94 and faster/.
> 
> Then get faster/ into trunk, and build on it for 0.95.
> 
> - Mike
> 
> ----- Original Message -----
> > From: "Mihael Hategan" <hategan at mcs.anl.gov>
> > To: "Swift Devel" <swift-devel at ci.uchicago.edu>
> > Sent: Tuesday, February 12, 2013 8:22:38 PM
> > Subject: [Swift-devel] faster branch
> > 
> > Hi,
> > 
> > Over the past couple of weeks I committed the faster branch. It's
> > essentially a re-implementation of the karajan language.
> > 
> > The gist of it is that it is now a semi-compiled language. What I
> > mean
> > by that is that there is no code generation, so the initial parse
> > tree
> > is converted into a compiled tree. Variable and function references
> > are
> > resolved at compile-time. This provides considerable improvements in
> > performance from two fronts:
> > 
> > 1. The interpreter was changed from an event-based system (a system
> > that
> > made sense many years ago, but has little relevance for swift) to a
> > lightweight threading implementation based on exceptions.
> > 2. The compiler can make optimizations that weren't possible with a
> > dynamic language. For example, once the swift and logging settings
> > are
> > known, code that conditionally executes based on a swift property or
> > logging statements can be optimized away and have no run-time
> > overhead.
> > 
> > There is also a benefit in memory consumed. Variables are now stored
> > in
> > arrays rather than hashtables. This should reduce the run-time
> > overhead
> > of the engine.
> > 
> > There are a few more relevant changes from swift's perspective:
> > - there is no more karajan xml. Keeping two inter-operable syntaxes
> > was
> > a pain in the back.
> > - sites.xml is now parsed with a DOM parser
> > - all the coaster code has been moved into provider-coaster. Karajan
> > is
> > now independent of that (and the other way around).
> > 
> > Most of the tests pass, but that means little. So if you can give it
> > a
> > shot, please do. If it works sufficiently well, we can merge this
> > into
> > trunk.
> > 
> > Code is at:
> > https://cogkit.svn.sourceforge.net/svnroot/cogkit/branches/faster/
> > https://svn.ci.uchicago.edu/svn/vdl2/branches/faster
> > 
> > Mihael
> > 
> > (PS: Contrary to my initial beliefs, the TUI seems to mostly work,
> > but I
> > haven't tested in detail).
> > 
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
> >