Fork me on GitHub
#clojure-dev
<
2019-02-15
>
andy.fingerhut00:02:05

I somehow happened across the new programming language Pyret recently. It seems to have a fairly well thought out definition for 3 different equality operators, including identical, equal-always, and equal-now, where equal-always looks very close to Clojure =, but Clojure = also does double duty for equal-now, which is more like Java .equals: https://www.pyret.org/docs/latest/equality.html

andy.fingerhut00:02:41

Stuff I geek out on after writing the equality guide for Clojure: https://clojure.org/guides/equality

alexmiller04:02:21

If you come here with info about performance degradation from latest java 8 or 11 upgrade, please provide me the following info: 1) java -version (when it is happening) 2) Clojure version 3) Leiningen version (if using lein) 4) a repo where you experienced the problem 5) the command you run in that repo to see it

Shantanu Kumar18:02:19

@alexmiller You might want to look at this thread: https://groups.google.com/forum/?fromgroups#!topic/mechanical-sympathy/lflljWsKw0M - 8u201 received a zero-day fix that screwed up performance for static methods

alexmiller18:02:31

This looks entirely relevant, thank you for the link. In particular this affects perf during static initialization and user.clj is loaded during RT static initializer, which matches several things about the repro

hiredman05:02:54

https://github.com/hiredman/weird-user-load-performance is a small reproducible case the user.clj performance issue I was helping someone with earlier. what I see is on some jdks loading core.async from user.clj takes about twice the time as loading it from a -i script. this appears to be in some way general slowness loading code from user.clj, more apparent when it is macro heavy

alexmiller05:02:46

yes, the macro heavy aspect seems to be common across multiple cases

alexmiller06:02:25

I filed a Java bug report

dpsutton06:02:32

@alexmiller can you put a link to the bug report?

alexmiller06:02:02

there is no link

parens 1
alexmiller06:02:12

I presume it is going through some triage machinery to measure its worth

alexmiller06:02:29

and then, if we are very lucky, it will become a Bug

alexmiller06:02:49

but more likely, they'll just ask for Java code

alexmiller06:02:28

I have additionally reached out via Other Means

1
1
gklijs07:02:15

What about using the graal jvm with clojure. It works, but is it faster?

alexmiller07:02:41

if you mean with native-image, then yes it's much faster to start, but it's precompiled so can't jit based on runtime data and is maybe slower after that

alexmiller07:02:23

there are some significant limitations with dynamic loading so it depends a lot what your program is doing as to whether you can make a native image at all

gklijs07:02:05

No, just the JVM packed with Graal

athos09:02:13

Is this intentional?

(meta '^:x []) ;=> nil
while
(meta '^:x [:a]) ;=> {:x true}
(meta '^:x a) ;=> {:x true}
Looks like a bug

athos09:02:07

@bronsa Aha, thanks! I couldn’t find that ticket in JIRA.

bronsa14:02:41

@alexmiller FWIW Rich vetted the ticket a long time ago, before it was closed as duplicated and I reopened it, dunno if it should've been bumped back to pre-vetted

alexmiller14:02:45

yeah, I know. It's fine. (needs screening of course)

bronsa14:02:49

:thumbsup:

bronsa14:02:56

sorry for the messy history on that ticket :)

alexmiller14:02:24

it happens :)

mikerod21:02:19

that’s an oldie