attila_lendvai has quit [Ping timeout: 240 seconds]
dra_ has joined #commonlisp
ns12 has quit [Quit: bye]
ns12 has joined #commonlisp
dra has quit [Ping timeout: 240 seconds]
phantomics has quit [Ping timeout: 240 seconds]
unyu has quit [Ping timeout: 268 seconds]
miique has joined #commonlisp
<asarch>
Up to how many handlers can Hunchentoot work with?
<Xach>
asarch: it uses a hash table to store them, so i suppose it is limited by available memory.
<asarch>
Thank you! Thank you very much! :-)
<Xach>
asarch: how many do you think you will use?
<asarch>
My small home-made web application has 89 so far
<asarch>
I remember having some issues when I used Flask for Python
<asarch>
I don't rember if it was Python 2 or Python 3
<Xach>
I bet you could have at least 1000x that many
Bike has quit [Quit: Connection closed]
<asarch>
That's great!
<asarch>
I wonder what web server Amazon uses
dre_ has joined #commonlisp
gaqwas has quit [Ping timeout: 240 seconds]
Inline__ has joined #commonlisp
<hayley>
Probably a fair few, assuming they use approximately too many languages, which probably is the case.
s-liao has joined #commonlisp
igemnace has quit [Ping timeout: 268 seconds]
robin has joined #commonlisp
<rotateq>
asarch: many things and many technologies i would say
<rotateq>
maybe also Clojure (which states it's good for concurrency) or Elixir. the second maybe used in twitch too (I don't know), but surely amazon just bought it in 2014
<rotateq>
hayley: it's easier to list the few powerful things they and others manage to go around :P
Alfr has quit [Remote host closed the connection]
Noisytoot has quit [Read error: Connection reset by peer]
unyu has joined #commonlisp
Alfr has joined #commonlisp
Noisytoot has joined #commonlisp
Everything has quit [Quit: leaving]
dra_ has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
rotateq has left #commonlisp [ERC (IRC client for Emacs 27.2)]
dilated_dinosaur has quit [Ping timeout: 240 seconds]
winning-luser has joined #commonlisp
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
asarch has quit [Quit: leaving]
dilated_dinosaur has joined #commonlisp
<sm2n>
last I heard they were mainly a c++ shop
Inline__ has quit [Quit: Leaving]
dre_ has quit [Ping timeout: 268 seconds]
random-nick has quit [Ping timeout: 240 seconds]
waleee has quit [Ping timeout: 250 seconds]
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
azimut has joined #commonlisp
dre_ has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
Algernon91 has joined #commonlisp
Algernon91 has quit [Ping timeout: 268 seconds]
Alfr has quit [Remote host closed the connection]
Alfr has joined #commonlisp
cosimone has quit [Remote host closed the connection]
lisp123 has quit [Remote host closed the connection]
alfonsox has joined #commonlisp
Oladon has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 260 seconds]
jealousmonk has quit [Quit: ERC (IRC client for Emacs 27.1)]
alvaro121_ has joined #commonlisp
alvaro121 has quit [Ping timeout: 240 seconds]
<beach>
If anyone is ever tempted to improve performance by profiling and low-level optimizations, I recommend you watch this video by Emery Berger "Performance Matters": https://www.youtube.com/watch?v=r-TLSBdHe1A
<beach>
It should tell you that such attempts are pretty futile and that for low-level optimizations to be worthwhile, you need some way more sophisticated tools than a profiles.
<beach>
So unless you have such tools, you might just forget it altogether.
<beach>
For me as a person creating a Common Lisp implementation, I conclude that it would be a huge waste of time for me to guess what would improve overall performance, implement an improvement, and perhaps see some minor performance improvement.
<hayley>
.oO(Yes, a video on performance by the man who famously ruined discussing garbage collection by "quantifying" the effects of garbage collection over explicit memory management. The video is actually useful, but I'm still annoyed.)
<hayley>
Did someone mention performance here? I might have missed something.
<beach>
It happens regularly as I recall, but I may have dreamed that. I seem to remember relative newbies asking whether to do this or that.
<susam>
Good morning, beach!
<susam>
Good morning, everyone!
<beach>
hayley: I can see why you are annoyed. But there are often several different possible conclusions of some work. In this one, you may conclude that you should always write C code and use his tools. But my conclusion is that you should be careful with how to attempt to optimize the performance of your code.
<hayley>
I think "Performance Matters" is a good presentation.
<beach>
It is.
<beach>
And Emery is a smart guy. I met him during my year with Paul Wilson at UT Austin.
<beach>
I frequently cite the paper by Hudak and Jones, too. You may conclude from that paper that you should always use Haskell, but I conclude that choosing the right programming language for a particular task can make a factor 20 difference in development time.
<hayley>
But, much like how people point to benchmarks like the language shootout to make a point, without actually reading the benchmarks (e.g. anything to do with regular expressions usually involves FFI to PCRE2), the paper by Berger and Hertz I am thinking of is "read" in a way that allows one to present shocking results about the performance of garbage collection.
<beach>
Oh, I see.
aeth has quit [Ping timeout: 268 seconds]
taiju has joined #commonlisp
<beach>
I haven't read the paper, and perhaps I should. Are you saying that this is not what one should conclude from it?
<hayley>
The more careful reader would note that the baseline for explicit memory management is generated (as they want to test using Java programs) using an undecidable algorithm. So any explicit memory management technique the programmer uses, or any memory management generated by a compiler (using e.g. regions or linear types) is going to be strictly worse performing than the algorithm presented.
<beach>
It would be surprising since Emery was working in a group that was definitely in favor of automatic memory management.
<beach>
Interesting.
aeth has joined #commonlisp
<hayley>
The conclusion isn't wrong, and I shouldn't blame any interpretation on the authors. But they do overstate the usefulness of their results, in my opinion, since they did not show how their algorithm is representative of what any programmer does.
<beach>
I see. Well, that could be the effect of the need for funding and/or publications for the career.
<hayley>
Sure, I can't blame that on them either.
s-liao has quit [Quit: Client closed]
s-liao has joined #commonlisp
<hayley>
I don't want to distract anyone from the presentation you mentioned though. I tried to make a causal profiler for Common Lisp, but managed to crash SBCL in a way I didn't understand, so I gave up. Someone else should definitely have another try at it.
<beach>
Hmm. Yes, I see.
<hayley>
(Though, I recall Steve Blackburn et al published a similar paper about a week ago, comparing real Java collectors to an "ideal collector", as determined by removing time spent in the collector. But this produces a neither-fish-nor-foul result where you get all the benefits of such collectors, like compacting, but none of the drawbacks. Someone already tried to use the results to dismiss other publications as "idiotic bragging".)
<hayley>
(Again, not the fault of Blackburn or anyone else, but it makes discussing performance harder.)
<beach>
Sure.
Oddity has quit [Ping timeout: 268 seconds]
notzmv has joined #commonlisp
<hayley>
I only bring it up since there was an online programming community I would have liked to participate in, but the participants had already fallen for such noise. It made me feel more uncertain about what I'll do in the future than usual.
<hayley>
Probably overreacting though.
Colt_ is now known as Colt
Lycurgus has joined #commonlisp
Jing has quit [Remote host closed the connection]
<beach>
I understand.
Jing has joined #commonlisp
s-liao49 has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
<Lycurgus>
false conclusion from the fact of undecidability of a class of algorithms
<Lycurgus>
and a generally callow view of how things actually work
<Lycurgus>
gc is very old, very tried and tested and really today mostly uninteresting
<Lycurgus>
i.e. unless you want to obsess on it for some reason
<hayley>
It is more that the algorithm uses more information than any static analysis could gather (and also is more accurate than any dynamic feedback scheme, since it knows exactly where an object is no longer reachable). You're right that undecidability is not the most crucial part of the results, but it is necessary and shows that the algorithm can only be an upper bounds on performance.
<Lycurgus>
a judicious expediture of effort would be enabling cheney (in sbcl) and also sbcl is a problematic implementation in general compared to others that are less so
<Lycurgus>
for example
<hayley>
Eh, nowadays one has to handle caching and the so-called "allocation wall" when you want to allocate faster than primary memory allows you to.
<Lycurgus>
i never heard of that issue sounds spurious
<Lycurgus>
of course heaps have configured limits
<hayley>
On the other hand, caches aren't a new invention, and they've always been annoying (though probably more now than ever before).
<hayley>
"Because the write bandwidth is so limited, we propose the following hypothesis: the scalability and performance is limited by the object allocation on emerging multi-core platforms for those objects-allocation intensive Java applications, as if these applications are running into an "allocation wall"."
<Lycurgus>
ah OK jave i was thinking common lisp
treflip has joined #commonlisp
<Lycurgus>
but still it's just java has a much wider compass that opens up for that to make sense
<Lycurgus>
it's still at some level a make work issue even there
<hayley>
It applies to Common Lisp just as much as any language (something similar happens in Haskell too). Perhaps even in any language with dynamic allocation.
<semz>
That Emery Berger talk is really good. Great case of a solution that seems obvious in retrospect.
dave-from-the-k has quit [Remote host closed the connection]
<Lycurgus>
*java
Lycurgus has quit [Quit: Exeunt]
<hayley>
beach: For what it's worth, I am aware that Hertz and Berger also designed a "bookmarking" garbage collector, which allows for performing conservative collections without thrashing, when some of the heap is paged out. It might be useful for collection in CLOSOS.
lisp123 has quit [Remote host closed the connection]
Algernon69 has joined #commonlisp
nature has joined #commonlisp
szkl has joined #commonlisp
gaqwas has joined #commonlisp
s-liao has joined #commonlisp
lisp123 has joined #commonlisp
gaqwas has quit [Remote host closed the connection]
lisp123 has quit [Quit: Leaving...]
pve has joined #commonlisp
notzmv has joined #commonlisp
Algernon69 has quit [Read error: Connection reset by peer]
Algernon91 has joined #commonlisp
cage has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 250 seconds]
Lord_of_Life_ is now known as Lord_of_Life
rgherdt has joined #commonlisp
treflip has quit [Remote host closed the connection]
jujumambo has joined #commonlisp
jujumambo has quit [Remote host closed the connection]
s-liao has quit [Ping timeout: 256 seconds]
mingus has joined #commonlisp
lisp123mobile has joined #commonlisp
<lisp123mobile>
Does anybody know what is meant the the words “symbol bloat” and “trampoline methods” in the following extract from the Google CL Style guide?
<lisp123mobile>
By default, an abstract base class name is used as the notional protocol name, so accessor names default to <class-name>-<slot-name>; while such names are thus quite prevalent, this form is neither required nor even preferred. In general, it contributes to "symbol bloat", and in many cases has led to a proliferation of "trampoline" methods.
<hayley>
Maybe the author thinks that style leads to symbols that are too long for them?
<hayley>
I don't get the trampoline method part though.
<semz>
A trampoline method is probably a method that just redirects its arguments to a method of a different name
<lisp123mobile>
Yep, I had the same view as you, that kinda makes sense for symbol bloat but I didn’t get the second part
<_death>
I guess the alternative they think about is using the same name as the slot's
<rotateq>
oh lisp123mobile now you advanced to mobile level :D
<semz>
My guess is that they had problems where what should have really been one generic function ended up split into several GFs of different names because of this convention
<rotateq>
hm i read that style guide around 2 years ago but can't remember those
<lisp123mobile>
_death: I was thinking that. Perhaps there are other similarly named slots (e.g. “slot-a”) so if one uses class-name-slot-name then one needs a redirection to (slot-a …)
<semz>
and so the "symbol bloat" would be having lots of symbols and the "trampoline method" would redirect from one GF to the other. All of this is guesswork though.
<_death>
there may be a single generic function FOO that has methods calling THIS-FOO and THAT-FOO according to specialization
<lisp123mobile>
semz: that seems to make sense
s-liao has joined #commonlisp
<rotateq>
after i've looked at some SICL code i see also the possible preferation for prefixing slot-names with #\%
<lisp123mobile>
rotateq: next up, lisp on the phone ;) but this connection may die out at any point
<rotateq>
yes yes, like in apps and webz, the fuuuture. often it sounds like people (who are in business) really think those things are the only ones *weird*
<lisp123mobile>
_death: hmm that makes sense actually
<rotateq>
lisp123mobile: but you can the CL-REPL app, it's fun, with ecl and qml
<_death>
anyway these seem like silly arguments to me.. the conclusion may be a good idea but it's just aesthetics and in my opinion requires a case by case analysis
mingus has quit [Ping timeout: 240 seconds]
<lisp123mobile>
Agree, just wanted to see if I was missing something
xsperry has quit [Ping timeout: 268 seconds]
lisp123mobile has quit [Remote host closed the connection]
lisp123mobile has joined #commonlisp
lisp123mobile has quit [Remote host closed the connection]
Inline__ has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
gaqwas has joined #commonlisp
random-nick has joined #commonlisp
Inline__ has quit [Quit: Leaving]
Algernon91 has quit [Ping timeout: 240 seconds]
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
casionaut has joined #commonlisp
rain3 has joined #commonlisp
waleee has joined #commonlisp
s-liao has joined #commonlisp
Inline__ has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
tyson2 has joined #commonlisp
igemnace has joined #commonlisp
Alfr has quit [Killed (mercury.libera.chat (Nickname regained by services))]
Alfr has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 250 seconds]
amb007 has joined #commonlisp
nature has quit [Ping timeout: 256 seconds]
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.4]
Alfr has quit [Killed (erbium.libera.chat (Nickname regained by services))]
Alfr has joined #commonlisp
gaqwas has quit [Remote host closed the connection]
nij- has joined #commonlisp
treflip has joined #commonlisp
igemnace has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.4]
Algernon69 has joined #commonlisp
Colt has quit [Remote host closed the connection]
aeth has quit [Ping timeout: 240 seconds]
Colt has joined #commonlisp
aeth has joined #commonlisp
Colt has quit [Remote host closed the connection]
Colt has joined #commonlisp
jealousmonk has joined #commonlisp
Lycurgus has joined #commonlisp
gaqwas has joined #commonlisp
Colt has quit [Remote host closed the connection]
Colt has joined #commonlisp
Alfr is now known as Guest5008
Guest5008 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
Alfr has joined #commonlisp
nij- has quit [Quit: Using Circe, the loveliest of all IRC clients]
Colt has quit [Read error: Connection reset by peer]
Algernon91 has joined #commonlisp
Algernon69 has quit [Ping timeout: 268 seconds]
Everything has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
Lycurgus has quit [Quit: Exeunt]
dra has joined #commonlisp
aeth has quit [Ping timeout: 268 seconds]
aeth has joined #commonlisp
Colt has joined #commonlisp
rogersm has joined #commonlisp
gaqwas has quit [Remote host closed the connection]
nckxmas is now known as nckx
treflip has quit [Quit: ERC (IRC client for Emacs 27.2)]
tyson2 has joined #commonlisp
miique has quit [Read error: Connection reset by peer]
Algernon666 has joined #commonlisp
Algernon91 has quit [Ping timeout: 240 seconds]
attila_lendvai_ has joined #commonlisp
attila_lendvai has quit [Ping timeout: 250 seconds]
attila_lendvai_ has quit [Read error: Connection reset by peer]
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
attila_lendvai_ has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
alcaeus has joined #commonlisp
alcaeus has left #commonlisp [#commonlisp]
alcaeus has joined #commonlisp
dra has quit [Quit: Leaving]
gaqwas has joined #commonlisp
gaqwas has quit [Ping timeout: 240 seconds]
gaqwas has joined #commonlisp
Bike has joined #commonlisp
varjag has quit [Ping timeout: 240 seconds]
varjag has joined #commonlisp
VincentVega has joined #commonlisp
dra has joined #commonlisp
Inline has quit [Remote host closed the connection]
nitrowheels has joined #commonlisp
Noisytoot has quit [Ping timeout: 256 seconds]
Jing has quit [Ping timeout: 256 seconds]
Noisytoot has joined #commonlisp
gaqwas has quit [Remote host closed the connection]
Algernon666 has quit [Ping timeout: 240 seconds]
cosimone has quit [Ping timeout: 268 seconds]
VincentV` has joined #commonlisp
VincentVega has quit [Ping timeout: 256 seconds]
gaqwas has joined #commonlisp
Alfr has quit [Remote host closed the connection]
alcaeus has left #commonlisp [ERC (IRC client for Emacs 27.2)]
Alfr has joined #commonlisp
nature has joined #commonlisp
aeth has quit [Ping timeout: 256 seconds]
cosimone has joined #commonlisp
aeth has joined #commonlisp
rain3 has quit [Ping timeout: 240 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
casionaut has quit [Quit: o7]
amk has quit [Read error: Connection reset by peer]
amk has joined #commonlisp
<hobo>
does anyone know if there is an IRC channel for croatoan somewhere?
<rotateq>
hobo: no sorry not that i would be aware of. maybe you can ask in #clim too
<hobo>
rotateq: i'll try that, thank you
<rotateq>
just a random thought, as croatoan is also for graphical interfaces ^^
nitrowheels has quit [Quit: Leaving]
* edgar-rft
wants a channel with croutons
jstoddard has joined #commonlisp
Inline__ has quit [Quit: Leaving]
Inline has joined #commonlisp
Inline has quit [Quit: Leaving]
Inline has joined #commonlisp
gaqwas has quit [Remote host closed the connection]
epony has quit [Ping timeout: 240 seconds]
<jstoddard>
Last night I finished reading through "Ray Tracing in One Weekend" and implementing it in Common Lisp: https://github.com/jstoddard/rtiow
<jstoddard>
The code is a bit ugly because it's too faithful to the C++ original rather than idiomatic Lisp. It's also terribly inefficient (at the book's settings it will take a couple days to render the random scene on my computer).
<jstoddard>
But I'll worry about those details later. My brain is about to mutiny.
<jstoddard>
I'm just happy it works.
epony has joined #commonlisp
<phoe>
jstoddard: you should be able to replace your VEC3 implementation for a native vector of three double-floats, and properly adjust your accessors, to get an immediate significant speed boost
<phoe>
other than that, congrats!
<jstoddard>
phoe: Thanks! That will probably be the first thing I try.
fazz234234372 has joined #commonlisp
rgherdt has quit [Ping timeout: 240 seconds]
pve has quit [Quit: leaving]
shka has quit [Ping timeout: 240 seconds]
dra has quit [Quit: Leaving]
aartaka has quit [Ping timeout: 240 seconds]
<rotateq>
edgar-rft: :D
taiju has quit [Ping timeout: 256 seconds]
Algernon666 has joined #commonlisp
fazz234234372 has quit [Quit: Connection closed]
taiju has joined #commonlisp
<aeth>
you have to be careful with high-performance double float vec3's, actually
<aeth>
implementations will (probably) box them
<phoe>
only on the function call barrier though, right?
<aeth>
you have to make sure that the doubles themselves don't leave the scope of a function except inside of a vector to let implementations optimize double float operations
<phoe>
if a vector of three floats is passed around then the vector will act as a box
<phoe>
oh yes, right, that
<aeth>
so e.g. (setf (aref a 2) 42d0) is a bad last line, which you normally don't have to worry about for just about any other niche in CL... that implicit return value that's so common
<aeth>
(setf (aref a 2) 42d0) probably won't speed up your code that much if it winds up having to box it to return it (just to discard it later on because you never cared about it in the first place)
<aeth>
it shows up a lot if you just translate C/C++ numerical stuff
<aeth>
it also sets up a situation where you'll want to have 1-length or 0-dimensional vectors to store doubles (a manual box of sorts) when the C/C++ API will just use scalars
<jstoddard>
I shouldn't have a lot of that in my code to worry about. It's not anything near functional, but at least for the vec3's I think I've tended to return new vectors rather than modify elements.
<aeth>
(store doubles that cross the function call boundary, I mean)
<aeth>
(unless you put them in a struct instead, but I think only SBCL optimizes those)
gaqwas has joined #commonlisp
nature has quit [Quit: leaving]
Algernon91 has joined #commonlisp
Algernon666 has quit [Ping timeout: 250 seconds]
random-nick has quit [Ping timeout: 252 seconds]
attila_lendvai_ has quit [Ping timeout: 245 seconds]
yewscion_ has joined #commonlisp
dra has joined #commonlisp
yewscion_ is now known as yewscion
varjag has quit [Ping timeout: 268 seconds]
gaqwas has quit [Ping timeout: 260 seconds]
Algernon91 has quit [Read error: Network is unreachable]