oznek has quit [Remote host closed the connection]
pastelowl has quit [Quit: WeeChat 4.6.3]
grenierm has joined #ruby
nirvdrum741 has quit [Ping timeout: 248 seconds]
nirvdrum741 has joined #ruby
livoreno has joined #ruby
_whitelogger has joined #ruby
_whitelogger has joined #ruby
schne1der has joined #ruby
infinityfye has joined #ruby
grenierm has quit [Ping timeout: 272 seconds]
dionysus69 has joined #ruby
livoreno has quit [Quit: Connection closed for inactivity]
Linux_Kerio has joined #ruby
inline_ is now known as inline
GreenResponse has joined #ruby
oznek has joined #ruby
oznek has quit [Client Quit]
jmcantrell has joined #ruby
dionysus69 has quit [Remote host closed the connection]
<nekobit>
What exactly causes the ruby startup to be so slow?
<nekobit>
Compared to say, mruby?
<nekobit>
Im planning to embed ruby in a project, and i liked that ruby has jit however it has undesirable memory usage and startup
<adam12>
nekobit: Rubygems is one culprit.
<adam12>
nekobit: Depending on the size of app, $LOAD_PATH is also an issue.
<nekobit>
Im talking about a plain hello world script just to test out the waters
<adam12>
nekobit: Try disabling rubygems and compare.
<nekobit>
I remember trying that before and the difference wasnt noticable
<nekobit>
Actually
<nekobit>
It does indeed have a slight impact
<adam12>
bbl
<nekobit>
Anyway, one more question, just out of curiosity before i look into embedding ruby. How well does it do with memory? Im saying this because ive heard about some ruby programs like ROR consuming a large amount of memory, but again i dont actually know how large ROR is or what it mainly spends all that memory on
<nekobit>
My intentions are for a emacs clone which I'd imagine would be used in vps's with not much memory
jmcantrell has quit [Ping timeout: 248 seconds]
cappy has joined #ruby
user71 has joined #ruby
Vonter has joined #ruby
user71 has quit [Quit: Leaving]
crespire has quit [Killed (NickServ (GHOST command used by crespire1))]
crespire1 has joined #ruby
Vonter has quit [Read error: Connection reset by peer]
<The_Camel_>
nekobit, I say no worse than python.
<The_Camel_>
I wouldn't worry about memory if you're making an emacs clone.
fantazo has quit [Quit: Lost terminal]
<nekobit>
The_Camel_: alright, thanks
<nekobit>
Hopefully there's a way i can not duplicate strings in the c api
<havenwood>
nekobit: Usually the impact is more than slight. I've noticed it's further reduced by using mimalloc.
<nekobit>
I built ruby with jemalloc and a typical hello world takes ~20mb of memory
<havenwood>
hyperfine 'ruby --disable-all -e "0"' # 7.3 ms ± 0.3 ms
<havenwood>
hyperfine 'ruby -e "0"' # 24.3 ms ± 0.5 ms
<nekobit>
mruby sits at around 2mb of memory however
<havenwood>
nekobit: You can try mimalloc without rebuilding since it can dynamically link. Just prefix: DYLD_INSERT_LIBRARIES="/path/to/libmimalloc.dylib"
<havenwood>
On macOS, for example: brew install mimalloc
<havenwood>
On Apple Silicon: /opt/homebrew/opt/mimalloc/lib/libmimalloc.dylib
<havenwood>
nekobit: I've been a longterm jemalloc user but now that it's deprecated I'm switching to mimalloc.
<havenwood>
I've actually been really pleased with mimalloc. Looking good for future stuff like mmtk too, scaling better than the rest of the field. https://blog.peterzhu.ca/assets/ismm_2025.pdf
<havenwood>
And lighter weight and more ergonomic than tcmalloc. Certainly fewer deps!
<havenwood>
nekobit: With mruby, you have to build it with a ton of stuff to get Ruby-like parity. Ruby is _fairly_ low memory even with YJIT. If you want to really want to run minimally you'll probably want to even avoid a golang- or mruby-like runtime.
<havenwood>
nekobit: Just disabling gems and jit drops from 21.7 to 16.5 locally. You can tune Ruby to reserve less memory with the JIT and fibers, etc.
Albarello has quit [Ping timeout: 252 seconds]
<nekobit>
Looks like the ebuild for mimalloc is out of date
<nekobit>
Is jemalloc really discontinued? I remember freebsd uses it by default
<nekobit>
havenwood: I'm not aiming for parity honestly, mainly looking for a bloated lua alternative
<havenwood>
nekobit: MRuby was born of Lua envy. Makes sense.
<nekobit>
I might just give mruby a roll then, don't particularly need JIT if I'm being honest. maybe I'll try and tack cruby support with some ifdefs, the apis look roughly similar
<o0x1eef>
https://subtle.de/ is a project that embeds a Ruby runtime for scripting support. mruby didn't exist at the time, but if it did, I'm sure they would have used that.
<nekobit>
Performance is not a concern since C is doing the heavy lifting
<havenwood>
Trying to get a #![no_std] version of sleeping 30 seconds working in Rust to compare memory usage with Python, Ruby and MRuby now. 😂
<o0x1eef>
I'd think if you're gonna embed Ruby that mruby would be the first choice. That's what it is designed for. CRuby not as much.
<havenwood>
o0x1eef: I agree, just what MRuby is meant for.
<nekobit>
It's a bit funny, mruby calls itself embedded, however, all the examples hint more at embedding for actual embedded equipment
<nekobit>
Hence it's vm model
<havenwood>
nekobit: Yeah, you can run it in a bios. Kinda fun.
<nekobit>
Though i do need to implement require support and some basic stuff
<o0x1eef>
The other attribute of mruby that stands out is that it is a C programmer's runtime. Most mrbgems I saw solve problems in C rather than Ruby, and it seems to be normal.
<nekobit>
Right, and considering I'm using C i don't particularly need these
<The_Camel_>
6 more web ui pages. just 6 more.
<havenwood>
Welp, sleeping without std is a pain and not worth the memory savings.
<The_Camel_>
yeah, C++ is a lifesafer.
<havenwood>
2,416 KB in assembly and 2,768 KB with Rust std. I'll take the latter!
<havenwood>
Binary is bigger but go figure.
<The_Camel_>
ease of development beats optimization.
<havenwood>
The_Camel_: Just checking as per convo above about MRuby and Lua memory usage versus Python or Ruby.
<havenwood>
MRuby only having a couple MB overhead is nice.
<The_Camel_>
note to self. don't shove pen clip holder in moustache.
<havenwood>
The_Camel_: Yeah, assembly and WASM sleeping is awfully painful to do portably and even for one system the savings are meh.
<havenwood>
Std libs ftw.
<The_Camel_>
now part of my moustache is stuck in pen.
<The_Camel_>
after excruciating pain.
<The_Camel_>
havenwood, yeah, sometimes I wish ruby came with more libraries than it does.
<The_Camel_>
by default. internally.
<The_Camel_>
instead of me having to install gems.
<o0x1eef>
We're moving away from that rather than towards it.
<The_Camel_>
o0x1eef, I know. and I can't say I like it. but anyway.
<leftylink>
sad about sorted_set, but maybe it's in a better place now. since previously it would silently have bad perf if rbtree wasn't installed. now at least rbtree is a dependency
<leftylink>
not happy about having to install a gem for it, but I guess better than not having it at all
<nekobit>
havenwood: lua performance is great though, especially luajit
<nekobit>
Ruby with jit runs just as fast as lua without jit
<havenwood>
The_Camel_: I mosh rather than ssh, typically.
<The_Camel_>
havenwood, hah! now see, why isn't that a GNU tool?
<havenwood>
The_Camel_: Written in Golang in the last century.
<The_Camel_>
sigh.
<havenwood>
Or there's a cloud one, couldsync or something.
<havenwood>
Can use it between two servers.
<havenwood>
rclone.
<havenwood>
The_Camel_: I think do one thing and one thing well, is fair.
<havenwood>
Mosh + rclone is pretty battle tested.
<The_Camel_>
havenwood, I like that rule until you hit the "it's obvious to have x and y"
<The_Camel_>
to which, it should break the rule.
<havenwood>
The_Camel_: I'd rather mosh + croc than have mosh bloat.
<The_Camel_>
havenwood, thanks for croc.
<havenwood>
The_Camel_: np
<havenwood>
Maybe HTTP/3 will get supported and be able to keep connections alive across mobile network reconnections, but for now I consider mosh essential on that front.
<havenwood>
Not like it's progressing quickly, but it works and nothing has caught up and gotten standardized yet.
<The_Camel_>
I understandd.
<The_Camel_>
havenwood, but it's 2025.
<The_Camel_>
It's 2025!
<The_Camel_>
it's not like, it's a new thing.
<The_Camel_>
it's a MANDATORY THING that should've been built with GNU in 1990
<havenwood>
The_Camel_: Wait, back in 2025 I think we just made `/` a git repo and cloned it?
rvalue has quit [Changing host]
rvalue has joined #ruby
<The_Camel_>
havenwood, sftp behaves better!
<The_Camel_>
having the ability to copy files in the same session without requiring you to step out
<havenwood>
The_Camel_: It is interesting to be swapping out gnu tools one by one though.
<The_Camel_>
and having to be forced to specify the host again.
<testone>
tbh ssh and mosh shouldn't be able to transfer files in a shell session
<The_Camel_>
well, they already don't.
<The_Camel_>
what I mean is
<testone>
sftp pretend to be ftp-like, thus it should
<The_Camel_>
if I ssh'd into a machine, I expect that there should be a shorthand for copying files back to the origin I connected to
<The_Camel_>
without having to specify the host (again) - through scp/rsync.
<testone>
maybe I have different uses, but I very rarely have to do such a thing
<testone>
[it's true I keep public WWW dirs, usually]
<testone>
[I just ln -s inside public WWW dir, and done]
<The_Camel_>
i ssh into a machine for 2 primary reasons: to transfer data. to configure.
reset has quit [Quit: reset]
<testone>
by the way: I didn't know croc either, will be useful in interfacing with android and win users
Vonter has joined #ruby
<testone>
[when even a https link is too much to explain]
<o0x1eef>
I ssh for almost everything. I run emacs, weechat, etc over ssh.
rvalue has quit [Quit: reconnecting]
rvalue has joined #ruby
<The_Camel_>
22% 4053MB 4.2MB/s 55:01 ETA
<The_Camel_>
scp hanged at that for like 30 minutes now.
<The_Camel_>
this is why I hate scp/rsync.
<The_Camel_>
until I test croc out, for this file I think I'll cut it at 1GB per each
<testone>
I remember having used rclone some times and it seemed good
<o0x1eef>
rclone is awesome
<o0x1eef>
I use it to deploy one of my static websites w/ BunnyCDN
<The_Camel_>
bunneh
<The_Camel_>
did you know; if you exclude the ears on a rabbit, it's practically an oversized rodent.
<The_Camel_>
o0x1eef, havenwood, some games have gotten ridiculously large btw. Hitman 2 is like 120GB.
<testone>
o0x1eef: the loading 'pseudo-page' + hidden real content is like asking for a macumba, you know? :D
<havenwood>
The_Camel_: Looks like Assassin's Creed Shadows is almost exactly the same size. That's the only modern game I've played lately and was just blown away.
<o0x1eef>
There's a reason for that :) It lets the font load in the background, so when the content is shown, there's no flicker between different fonts
<The_Camel_>
havenwood, blown away by the size or gameplay?
<havenwood>
The_Camel_: The quality, scale, visuals all seem over the top. Been a while since I played a 3D game.
<The_Camel_>
havenwood, ooh
<havenwood>
It's just... epic.
<The_Camel_>
havenwood, yeah, graphics have gotten crazy.
<The_Camel_>
havenwood, to the point they focus more on it than gameplay sometimes T_T
<havenwood>
The_Camel_: This M4 Max 128GB can chew through it too.
<havenwood>
The_Camel_: I think that's what impressed me, the visuals _with_ gameplay. Anyways, offtopic for Ruby.
<havenwood>
DragonRuby is pretty nifty for 2D games, but 3D is ellusive.
<The_Camel_>
havenwood, I have ideas for games that require minimal graphics and focus largerly on gameplay. they're isometric game ideas.
<The_Camel_>
I'd use dragonruby. problem is, in a game, it's usually 90% assets
<The_Camel_>
I don't have graphic designers, animators, music producers...
<o0x1eef>
You have AI :)
<The_Camel_>
a game is a stupendously large project.
<The_Camel_>
o0x1eef, yeah.... :P
infinityfye has quit [Read error: Connection reset by peer]
GreenResponse has quit [Quit: Leaving]
ruby[bot] has quit [Remote host closed the connection]