badkins has quit [Remote host closed the connection]
badkins has joined #racket
orivej has joined #racket
badkins has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 272 seconds]
selimcan has quit [Quit: Leaving]
ArthurStrong has joined #racket
vraid has quit [Ping timeout: 264 seconds]
KindTwo has joined #racket
KindOne has quit [Ping timeout: 256 seconds]
dddddd has quit [Ping timeout: 264 seconds]
KindOne has joined #racket
KindTwo has quit [Ping timeout: 272 seconds]
YuGiOhJCJ has joined #racket
efm has joined #racket
orivej has joined #racket
iyzsong has quit [Ping timeout: 272 seconds]
Sgeo has quit [Read error: Connection reset by peer]
lbeckman314 has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 256 seconds]
narimiran has joined #racket
badkins has joined #racket
badkins has quit [Ping timeout: 246 seconds]
Sgeo has joined #racket
_whitelogger has joined #racket
sauvin has joined #racket
ArthurStrong has quit [Ping timeout: 258 seconds]
narimiran has quit [Quit: leaving]
ArneBab has joined #racket
badkins has joined #racket
ArneBab has quit [Quit: No Ping reply in 180 seconds.]
badkins has quit [Ping timeout: 256 seconds]
aidalgol has quit [Read error: Connection reset by peer]
aidalgol has joined #racket
Sgeo has quit [Read error: Connection reset by peer]
tilpner_ has joined #racket
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
rgherdt has joined #racket
Sgeo has joined #racket
Sgeo has quit [Read error: Connection reset by peer]
epony has quit [Ping timeout: 258 seconds]
epony has joined #racket
orivej has joined #racket
dddddd has joined #racket
_whitelogger has joined #racket
_whitelogger has joined #racket
selimcan has joined #racket
true-grue has joined #racket
badkins has joined #racket
selimcan has quit [Ping timeout: 264 seconds]
badkins has quit [Ping timeout: 265 seconds]
ridik has joined #racket
badkins has joined #racket
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #racket
_whitelogger has joined #racket
doyougnu has joined #racket
acarrico has joined #racket
badkins has quit [Remote host closed the connection]
badkins has joined #racket
epony has quit [Ping timeout: 258 seconds]
badkins has quit [Ping timeout: 264 seconds]
badkins has joined #racket
epony has joined #racket
badkins has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 272 seconds]
epony has quit [Remote host closed the connection]
epony has joined #racket
rgherdt has quit [Ping timeout: 265 seconds]
orivej has joined #racket
efm has quit [Quit: Konversation terminated!]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
rgherdt has joined #racket
<dzoe>
samth: I am really looking forward trying unboxed flonums in CS - I've just finished simplified Phong lighting model with multiple light sources which means the rasterizer is more advanced than the one used in Quake 1.
<dzoe>
And still pure Racket, no external C/asm code.
<dzoe>
Let's see what the "final" version will look like: bilinear u/v interpolation should make it even faster and clipping against frustrum should make sure the performance is consistent no matter what is in the active scene.
<dzoe>
If it would have about twice the performance, I would be considering adding dynamic shadows using something like Carmack's reverse (but that requires multiple rendering passes).
<dzoe>
The biggest problem with boxed flonums (right now) is GC.
<dzoe>
Although it does not interfere with the futures, in the rest of the pipeline, it is quite flonum-heavy and it triggers GC more than often.
<dzoe>
But the real deal is in the racket/future module.
<dzoe>
What is the workload you want to run in parallel?
* zig
reading
SGASAU has joined #racket
<zig>
There is several use of os threads in my app.
<zig>
First, the foundationdb client is a shared library that is heavy in terms of algorithms (foundationdb can work and usually work distributed) and clients are smart.
<zig>
that is one can not easily recreate the wire protocol and call it a day. I know nobody that does that. Everybody binds the officiel client library in their language of choice
<zig>
That bound client library, will in the init step, require an os thread in the host language (I do not remember what it does, but it is called "network thread")
<zig>
well, that particular thread aka. network thread is "fork and forget", one never interact with it directly.
<zig>
I do not know the purpose of it in fact.
<dzoe>
OTOH, with Racket-CS, I would assume you could use the scheme code you mentioned above with only minor changes.
<zig>
That's where things become somewhat complex.
<zig>
FoundationDB client API support both sync and async
<zig>
And it happens that for performance reasons, I need to use both
<zig>
in my application, the mainthread is asynchronous but looks sequential (thanks to call/cc) that is what I call `untangle` and the mainthread can spawn threads to do heavy computations
<dzoe>
"heavy computations" in Scheme?
<zig>
heavy computation in the sense, it would block the async main thread.
<zig>
it is not solar system tesselation or weather forcasting.
<dzoe>
Well, judging from what you have just written, I'd assume you can live with green threads fine and for those heavy computations use futures.
<dzoe>
If you design it properly, it would run in parallel on multi-core systems.
<dzoe>
I mean just spawn (thread something) and if it is really computation-heavy, use futures inside that thread.
narimiran has quit [Ping timeout: 240 seconds]
<zig>
ok then, where do I start regarding HTTP stuff, I am used to Guile and Python's WSGI / ASGI approach, I am not sure about racket way of doing that
<dzoe>
By using the thread, you make sure it won't be blocking.
<dzoe>
By using futures, it may run physically in parallel.
<dzoe>
Depends on what you really want to achieve here.
<dzoe>
You start by reading everything Bogdan has written :)
<zig>
websocket support would be neat
<dzoe>
I am using racket web-server for production software, but I am no way an expert on that.
<dzoe>
Read racket-users archives, lookup Bogdan Popa's packages and articles and that should give you a great boost for a start.
<greghendershott>
dzoe: IIUC you're working on making racket/future be able to parallelize more than just numeric operations?
<greghendershott>
That's really cool! But until that's available, in the meantime would zig maybe get better results from Racket places than futures?
<greghendershott>
(I have almost zero hands-on experience with either. I'm basing that on what I've read... but maybe it's outdate.)
<dzoe>
greghendershott: it can already do more than just numeric operations - as long as you don't allocate too much memory or hit some future-unsafe operations, you can do a lot
<dzoe>
The work on supporting more hasn't started yet. But more generic data partitioning using futures is something I'd like to work towards.
Codaraxis has quit [Quit: Leaving]
selimcan has joined #racket
badkins has quit [Remote host closed the connection]
badkins has joined #racket
badkins has quit [Ping timeout: 265 seconds]
selimcan has quit [Ping timeout: 264 seconds]
true-grue has quit [Read error: Connection reset by peer]