[Swift-devel] faster branch
Lorenzo Pesce
lpesce at uchicago.edu
Thu Feb 14 11:32:45 CST 2013
Thanks a lot Mike.
Some day I would like to learn how to build them so I stop asking. I keep hoping I will have time, but it never seems to happen...
On Feb 14, 2013, at 10:32 AM, Michael Wilde wrote:
> David, can you build this and place it in a Beagle module?
>
> A good exercise for Yadu as well.
>
> Thanks,
>
> - Mike
>
> ----- Original Message -----
>> From: "Lorenzo Pesce" <lpesce at uchicago.edu>
>> To: "Mihael Hategan" <hategan at mcs.anl.gov>
>> Cc: "Swift Devel" <swift-devel at ci.uchicago.edu>
>> Sent: Thursday, February 14, 2013 10:20:56 AM
>> Subject: Re: [Swift-devel] faster branch
>>
>>
>> Sorry for being dumb here. It seems to be a bit different from the
>> process defined on the web site:
>> $ mkdir swift-0.93 $ cd swift-0.93 $ svn co
>> https://cogkit.svn.sourceforge.net/svnroot/cogkit/branches/4.1.9/src/cog
>> $ cd cog/modules $ svn co
>> https://svn.ci.uchicago.edu/svn/vdl2/branches/release-0.93 swift $
>> cd swift $ ant redist
>>
>>
>> what should I do? Just download the src and assume the rest is in?
>>
>>
>> Sorry for the silly question, I would like to install it today, but I
>> don't have the time to search for more details.
>>
>>
>>
>>
>>
>>
>> On Feb 12, 2013, at 8:22 PM, Mihael Hategan wrote:
>>
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>
More information about the Swift-devel
mailing list