<ermo>
I was recently doing some testing on speeding up the PGO build of python3 and used pyperformance to check that my tweaks weren't regressing performance.
<ermo>
so I went looking for something like that for racket and found the auto.rkt stuff in various subdirectories. I haven't really been able to find any upstream documentation/guidance on them. But then again, I have only looked since last night.
<ermo>
Huh. Looks like the rx benchmark auto.rkt tests racket against python and perl. Nice.
nullcone has quit [Quit: Connection closed for inactivity]
<samth>
ermo: there's no documentation for that
<ermo>
Hm. Perhaps I could learn enough to contribute some then. =)
* ermo
is currently reading through The Little Schemer 4th ed. and rather enjoying it
Lowl3v3l has quit [Read error: Connection reset by peer]
Lowl3v3l has joined #racket
<ermo>
samth: would it be naïve of me to expect a difference between a generic x86_64 build and a -march=native Racket build in terms of benchmark scores?
<samth>
ermo: I would be surprised if there was much difference
<ermo>
so far, I haven't noticed any difference except perhaps for the fibo benchmark
<samth>
ermo: does that generate very large numbers (more than 2^64)?
<ermo>
haven't checked
<samth>
in which case GMP might get optimized a bit
<ermo>
can the JIT be told to make use of -march=native CPU features when generating assembly or is that (far) out of scope?
* ermo
only has a vague understand of how this would be supposed to work, mind
<ermo>
s/assembly/machine code/ sorry
<ermo>
*understanding
<ermo>
and I can't type either
sz0 has quit [Quit: Connection closed for inactivity]
<ermo>
it'd be kind of cool if it could, though I can see why that might not be at the top of the priority list.
<ermo>
Being able to optimise for the underlying platform at runtime would be pretty awesome and represent a leg up on most other languages in its class. From what I've seen in C/C++, speedups of 5-10% for "free" via -march=native is nothing to sneeze at.
badkins has quit [Remote host closed the connection]
<ermo>
(vs generic x86_64 I mean)
badkins has joined #racket
<ermo>
But, again, this is without having a clue about what kind of work it would entail.
badkins has quit [Ping timeout: 256 seconds]
<samth>
ermo: the JIT can dynamically determine features and use them, but the hard part is changing the code generator to use fancier features
<dzoe>
samth: and what about the performance?
<samth>
dzoe: well, could it be implemented faster than the two comparisons?
<ermo>
so you prototype with contracts and do "proper" sw engineering with typed racket?
<dzoe>
Lots of futures, unsafe operations and crazy ideas.
<dzoe>
I think that is reasonably exact description.
gpanders has joined #racket
<dzoe>
But for this part I am mostly without TR - I used TR for verifying the correctness of the previous incarnation of this code.
<dzoe>
And actually it allowed me to identify some hidden problems (thanks to Robby and Sam!)
gpanders has quit [Client Quit]
<dzoe>
Also the latest version is well prepared for being gradually typed (most of it though ...).
gpanders has joined #racket
nullcone has joined #racket
notzmv has quit [Ping timeout: 264 seconds]
rj has joined #racket
<ermo>
dzoe: feels like a cross between wolfenstein 3D, doom and minecraft ^^'
<ermo>
(= not a bad combo!)
rgherdt has joined #racket
rj has quit [Ping timeout: 268 seconds]
rmculpepper has joined #racket
rmculpepper has quit [Quit: Leaving]
<dzoe>
ermo: actually you are not far from truth - the technique used for raycasting is the very same as in Wolf3D, however I extended it along the Z axis. The different heights of grid cells are handled the same way as in Doom.
<ermo>
lel
<dzoe>
But there is no Minecraft influence at all. The target is a raytraced rendering with the same capabilities as had the Ultima Underworld engine.
<ermo>
that was more the look of the textures and the sharp angles tbf
<ermo>
(and I'm sadly unfamiliar with the Ultima Underwold engine)
* ermo
goes watch videos
<dzoe>
So far the raycasting/tracing is actually useless, but with the geometry handling decoupled from texture mapping, I can cast shadow rays to light sources and compute real-time shadows.
<dzoe>
(It is shown in one of those videos - a simplified version though).
<ermo>
with zero actual graphics programming experience, this might be a *really* stupid q, but does the use of futures imply multithreading?
* dzoe
spent 90's programming game engines and to get away from his day to day work, he decided about a year ago to start playing which that again.
<dzoe>
Yes, heavy futures usage for multithreading is one of my goals (as I use futures extensively for my paid work).
<xandkar>
Is there a way to attach REPL to an already running Racket process?
<dzoe>
It is funny when I run this purely CPU-bound rendering and my CPU is ticking at 800MHz - futures are battery saver for my laptop.
<dzoe>
Trouble is that I have no idea (yet) how to render objects.
<dzoe>
Billboarding might be an option to incorporate sprites into this.
<ermo>
You might as well be speaking russian or chinese for all the good it'll do me ;)
<dzoe>
But I am afraid that full 3D models are beyond the capabilities of current CPUs for software-driven raytracing.
<dzoe>
Billboarding = flat surface with object texture on it ... basically you do not render true 3D objects, just project images into the world space.
<ermo>
but I'm assuming that billboarding is a technique using 2D surface with its normal is always pointing at the PC?
<ermo>
right
<dzoe>
And yes, brogue is a good example of where to start :)
<dzoe>
But that is long time in the future.
<ermo>
Commonly used in open world games with faraway trees, right?
<ermo>
(billboarding)
<dzoe>
My TODO list just for the world geometry is really long :)
<ermo>
I have no illusions that graphics programming and actually building a real-time engine is *hard*
<dzoe>
In wolf/doom and others, it was used for the enemies and all objects as well.
<ermo>
and rise of the triad as I recall
<dzoe>
ROTT pushed the original Wolf3D engine to its limits.
<dzoe>
The thing I really like is the math behind - it is actually pretty easy. And Racket is a great tool for exploring that math.
<dzoe>
(Although I am really good at hitting the limits ...)
<dzoe>
Yep, most of it is linear algebra - which plays well with futures (under Racket CS that is ... for BC I had to do so many weird hacks to make it work ...).
<dzoe>
Yes, those are the things on my TODO list ;-)
<ermo>
(didn't mean to downplay it, just trying to use my imagination to think what it might entail)
<dzoe>
That's OK, the underlying math really is easy.
<ermo>
there's just a LOT of it xD
<ermo>
(SIMD to the rescue!)
<dzoe>
I always show this to students when they complain that calculating fibonacci numbers is "hard" :-D
<ermo>
... students think that fib is *hard*?
<ermo>
ok
<dzoe>
Racket has no SIMD support so far :(
<ermo>
I guess I have limited imagination xD
<dzoe>
Well... I am teaching the introductory Algorithms and Data Structures for the 1st year students ...
<dzoe>
(In Clojure though ...)
<ermo>
Oh, ok. Well, I feel like the word they're really looking for is "new and unfamiliar" rather than "hard"
<dzoe>
Exactly
<ermo>
the two are easy to confuse
<ermo>
the difference is that the hard stuff stays hard even once you've mastered it
<ermo>
(or so I would imagine)
<ermo>
or, well, "tricky" I guess I should say
<dzoe>
Most of them are usually OK towards the end of the semester.
<ermo>
If you put in the work, you should be. Otherwise you aren't cut out for it tbh.
<dzoe>
And as this country is now "best in covid", they have plenty of time to sit at their desks and learn ;-)
<ermo>
(a bit harsh, but it feels like the honest truth)
<ermo>
you say learn, I say practice and repeat ;)
<ermo>
just as with math, you get used to programming and algorithms
<ermo>
some misattribute this to "learning"
<dzoe>
Well, the learning part is important as well. For example today I had a consultation with a student struggling with the `let' construct.
<ermo>
it's only "learning" in the sense that you're building new pathways I guess.
<ermo>
oh, the concepts you mean
<ermo>
well, ok. The concept part is learning.
<dzoe>
Once she grasped the idea that it is not a "statement" like `int i = 0;' she was fine.
<ermo>
But it's maybe 20% learning and 80% practice to reinforce it.
<ermo>
(if that constitutes learning-at-large, ok, I'll buy what you're selling)
<dzoe>
That's true. Especially for this class. It is just a basis for more advanced topics.
<ermo>
*everything* is just a basis for more advanced topics xD
<ermo>
("just")
<dzoe>
Hehe, yeah
<ermo>
dzoe: are you familiar with Barbara Oakley's "Learning how to Learn" work?
<ermo>
and Marty Lobdell's How to Study lectures?
<ermo>
That combination has been kind to me
<ermo>
In the sense that it's allowed me to use my time more effectively
<ermo>
Coupled with the Feynman technique
<dzoe>
Not really.
<ermo>
(i.e. explaining things in as simple terms as possible during recall excercises)
<ermo>
dzoe: well, for struggling students, those three sets of techniques could turn out to be useful.
<dzoe>
Yep, I like Feynman's approach.
<dzoe>
And I always quote him when describing what the "science" thing really is.
<dzoe>
You can conjecture whatever hypothesis you want - but then you have to put it to a test.
<dzoe>
And if it does not pass the test, you are wrong.
<dzoe>
Simple as that.
<dzoe>
I like simplicity.
<ermo>
My favourite one is Marty's use of "cues": As he tells it, he observed an experiment where one group consistently set a cue (turned on a designated "study lamp" before starting to study) and the control group didn't. The group that set the cue finished the class with +1 GPA
orivej has joined #racket
<ermo>
I was like "... wtf"
rj has quit [Ping timeout: 268 seconds]
<dzoe>
Humans are complex systems ...
<ermo>
sure, but the habits you build with cues tend to work well
<ermo>
even if the system behind it is complex, the outcome (on a macro level) appears reliable. I mean, the same techniques are used successfully to train all sorts of intelligent animals
<dzoe>
Which is (to me at least) a surprising result, but apparently a valid one nonetheless.
<ermo>
so why not homo sapiens as well?
<ermo>
the most surprising thing for me was oakley's point that if you work hard at something, stop the minute you find yourself getting frustrated.
rj has joined #racket
<ermo>
That's apparently a sign that you brain needs time to relax and move to "diffuse mode" where you interconnect new concepts to form new patterns (= new modes of understanding)
<ermo>
i.e. work hard (focused mode) then relax and do something else (diffuse mode)
<ermo>
because your brain apparently keeps working on the problem, just in a different way
<ermo>
so practicing an instrument, cleaning, going for a walk/run, play a game etc. is actually not wasted if you've put in the work first
<ermo>
anyway, this is #racket, not #howtostudy xD
<dzoe>
Sounds reasonable :)
<dzoe>
Yes, it is #racket, but large part of the Racket ecosystem is very educational-centric anyway ;-)
<ermo>
*phew* dodged that bullet then
<ermo>
I guess that's probably why I *like* the racket ecosystem
oriba has joined #racket
dbmikus has joined #racket
rj has quit [Ping timeout: 268 seconds]
rj has joined #racket
rj has quit [Ping timeout: 268 seconds]
notzmv has joined #racket
rj has joined #racket
rj has quit [Client Quit]
phillbush has joined #racket
<dzoe>
Is there a way to recursively extract all required modules?
<dzoe>
(Paths/names)
<samth>
dzoe: extract from what?
<dzoe>
From any-source-file.rkt - iterate recursively through all requires in all stages (normal, syntax, doc)
<dzoe>
Basically to find the dependencies automatically.
orivej has quit [Ping timeout: 246 seconds]
badkins has quit [Remote host closed the connection]
badkins has joined #racket
badkins has quit [Ping timeout: 245 seconds]
rj has joined #racket
badkins has joined #racket
louis771 has quit [Quit: My M1 has gone to sleep. ZZZzzz…]