Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 21 19:59
    fraya review_requested #1250
  • Aug 21 19:58
    fraya opened #1250
  • Aug 21 18:48

    cgay on master

    [Doc] Intro to Dylan: DRM links… doc: Simplify multi-word `:drm… Merge pull request #1248 from f… (compare)

  • Aug 21 18:48
    cgay closed #1248
  • Aug 21 18:48
    cgay closed #97
  • Aug 21 15:39
    fraya review_requested #1248
  • Aug 21 15:23
    fraya synchronize #1248
  • Aug 19 11:38

    waywardmonkeys on master

    feat: Convert multi word `:drm:… (compare)

  • Aug 19 11:38
    waywardmonkeys closed #17
  • Aug 19 11:34
    fraya review_requested #17
  • Aug 19 11:15
    waywardmonkeys commented #1248
  • Aug 19 07:51
    fraya synchronize #1248
  • Aug 14 20:27

    housel on master

    testworks: Add an option for dy… testworks-run: Add a standalone… Merge pull request #100 from ho… (compare)

  • Aug 14 20:27
    housel closed #100
  • Aug 14 20:25
    housel synchronize #100
  • Aug 14 15:52
    cgay commented #1249
  • Aug 14 15:51
    cgay commented #1249
  • Aug 14 14:19
    housel opened #100
  • Aug 14 04:36
    Slids opened #1249
  • Aug 13 11:33
    fraya ready_for_review #1248
Alfredo Beaumont
@abeaumont
CL also wins on the tooling and performance sides
Dylan is like a cleaner and simpler subset (not a real subset, but still)
Carl Gay
@cgay
@abeaumont how are you comparing the performance?
I don't doubt that you're right, mind you. Just wondering how you compared.
Carl Gay
@cgay
I'm converting the shootout libraries to have separate -library.dylan files so I can get them to compile.
Peter S. Housel
@housel
Did we break single-file support at some point?
And if so, on purpose or just because we weren't using or testing it?
Alfredo Beaumont
@abeaumont
@cgay I'm just speaking from memory from when I worked on dylan's shootout code and other benchmarks I've done in the past
Peter S. Housel
@housel
At one point I had a Perl script in the shootout repository that would automatically create library and lid files for building with dylan-compiler
Alfredo Beaumont
@abeaumont
dylan compiler doesn't generate too fast code (idk if that has changed with LLVM support)
and OTOH sbcl generates some pretty fast code
Carl Gay
@cgay
@housel I don't remember what the format for single-file libraries was, but the shootout libs don't compile. https://github.com/dylan-lang/shootout/blob/master/ackermann.dylan
Alfredo Beaumont
@abeaumont
one of the fastest code for a dynamic language I have seen, which I find kind of surprising
Peter S. Housel
@housel
Depends on what it is, but the LLVM-generated code is usually significantly better than the old compiler output (largely due to improved calling convention overhead I suspect)
Alfredo Beaumont
@abeaumont
anyway, I'm talking about microbenchmarks, which are kind of irrelevant in most cases, but that's the only data I have
Peter S. Housel
@housel
Oh, @abeaumont removed fdsingle.pl in 2013
Alfredo Beaumont
@abeaumont
hmmm, I guess I did because single-file libraries made it unnecessary
Carl Gay
@cgay
I'd like to do some IO benchmarking. Dylan, SBCL, and at least one non-Lisp language, Python perhaps. I have a feeling we need a lot of optimization there.
The shootout code currently uses two files though.
I'm probably mixing up my ideas from DEP 6 and what we actually had.
Carl Gay
@cgay
Suddenly (and without warning) I am able to compile the shootout libraries that only use a .lid and one .dylan file.
Wish I had written down the error, but I assumed it would be easy to reproduce.
Internal error: No applicable method, applying {<sealed-generic-function>: top-level-convert-using-definition} to {<simple-object-vector>: #f, #f, {<function-macro-fragment>}}.
Clean build reproduces it.
Peter S. Housel
@housel
Could you run it with the -debugger option ?
(I can do it myself later)
:zzz:
Peter S. Housel
@housel
I managed to get Dylan code to work with llvm’s support for gcov-style code coverage instrumentation… but it was really painful (clang —coverage easily gets confused about the paths to the coverage data files)
Peter S. Housel
@housel
As I suspected, test suite coverage of io/pprint.dylan is abysmal (llvm-cov gcov measures 7% of code lines executed)
(versus, say, 91% for io/streams/sequence-stream.dylan)
I should sleep as well
Carl Gay
@cgay
Cool.
Peter S. Housel
@housel
So it looks like you just need to do dylan-compiler -build io first then you can compile the "single-file" library via its LID
(it's dying compiling a := macro call in io/format.dylan, not sure why specifically that caused a problem)
Peter S. Housel
@housel
Probably the magic Dylan namespaces didn't get registered properly without a dylan-user module
Carl Gay
@cgay
Did anything change around there recently? (For a Dylan value of recent.)
I'll probably go ahead and use separate library files though, because I want to make it so those benchmarks can be easily sent to the Benchmarks Game people but we can also run them as testworks benchmarks. Not sure exactly how that will look yet.
Peter S. Housel
@housel
The benchmarks game itself has changed quite a bit since we updated those programs; there are not nearly as many of them included as there used to be
Peter S. Housel
@housel
I've been writing testworks-style benchmarks corresponding to https://github.com/smarr/are-we-fast-yet
There is some overlap with the benchmarks game
A nifty feature that their benchmark framework has, in addition to repeating a specified number of iterations, it allows running assertions on the values computed by the final iteration outside of the benchmark time counter
Still thinking about how to add that to testworks
Peter S. Housel
@housel
To answer your earlier question, I don't know of anything that would have changed (but then I was concentrating mainly on back-end stuff for most of the current decade)
Carl Gay
@cgay
Neat, another benchmark thing. Did you mean you've already started implementing some of are-we-fast-yet?
Peter S. Housel
@housel
Yes, 6 out of 15 benchmarks so far
Carl Gay
@cgay
You're fast.
Peter S. Housel
@housel
I started in early April, it's been a low-priority background task
Carl Gay
@cgay
ok, you're slow (about mentioning things). :)