<d_bot>
<mbacarella> it does noticeably improve quality of life when compiling huge modules. just... curious what the runtime penalty to the resultant binary is
<companion_cube>
would be a good opportunity for benchmarks
<companion_cube>
in many cases it's probably not very significant
<d_bot>
<mbacarella> my big modules project compilation takes 45s with -linscan but 65s without it
bobo_ has quit [Quit: Konversation terminated!]
<d_bot>
<mbacarella> sadly, it's a not a CPU bound project so I don't think there's a good way to evaluate runtime tradeoffs
Serpent7776 has quit [Read error: Connection reset by peer]
drewolson has quit [Ping timeout: 252 seconds]
spip has joined #ocaml
Serpent7776 has joined #ocaml
drewolson has joined #ocaml
kurfen has quit [Ping timeout: 255 seconds]
kurfen has joined #ocaml
bobo_ has joined #ocaml
spip has quit [Ping timeout: 258 seconds]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<companion_cube>
if it's not a CPU bound project then you can use it without any worry, I think
vicfred_ has quit [Quit: Leaving]
spip has joined #ocaml
bobo_ has quit [Ping timeout: 244 seconds]
gentauro has quit [Read error: Connection reset by peer]
gentauro has joined #ocaml
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee has quit [Ping timeout: 260 seconds]
rgrinberg has joined #ocaml
sparogy has quit [Ping timeout: 272 seconds]
ns12 has quit [Ping timeout: 252 seconds]
rak has quit [Ping timeout: 272 seconds]
sim642 has quit [Ping timeout: 252 seconds]
towel has quit [Ping timeout: 252 seconds]
ns12 has joined #ocaml
rak has joined #ocaml
sparogy has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
towel has joined #ocaml
sim642 has joined #ocaml
gereedy has joined #ocaml
Haudegen has joined #ocaml
trev_ has joined #ocaml
gereedy has quit [Ping timeout: 240 seconds]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xgqt has quit [Ping timeout: 248 seconds]
xgqt has joined #ocaml
rgrinberg has joined #ocaml
<d_bot>
<Bluddy> I highly doubt anyone will feel anything either way. It's not like we're using highly efficient SIMD instructions in OCaml.
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
olle has joined #ocaml
gravicappa has joined #ocaml
mro has joined #ocaml
olle has quit [Ping timeout: 246 seconds]
recherche has joined #ocaml
recherche has quit [Remote host closed the connection]
ccx has quit [Ping timeout: 246 seconds]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
ccx has joined #ocaml
adanwan has quit [Ping timeout: 240 seconds]
olle has joined #ocaml
adanwan has joined #ocaml
kakadu has joined #ocaml
spip has quit [Quit: Konversation terminated!]
spip has joined #ocaml
mro has quit [Remote host closed the connection]
amk has quit [Ping timeout: 276 seconds]
amk has joined #ocaml
mro has joined #ocaml
mro has quit [Quit: Leaving...]
bartholin has joined #ocaml
<d_bot>
<Drup> typically, linear scan is "good enough" for almost everything that is not high performance computing
<d_bot>
<Drup> (especially with modern architectures with lot's of registers)
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 250 seconds]
aspe has joined #ocaml
aspe has quit [Remote host closed the connection]
chrisz has quit [Ping timeout: 248 seconds]
chrisz has joined #ocaml
omegatron has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
azimut has quit [Ping timeout: 240 seconds]
Sankalp has quit [Ping timeout: 256 seconds]
Sankalp has joined #ocaml
Haudegen has joined #ocaml
Sankalp has quit [Ping timeout: 248 seconds]
Sankalp has joined #ocaml
rgrinberg has joined #ocaml
<d_bot>
<mbacarella> well right. but what I want to avoid is baking a decision I don't fully understand into infrastructure. if i can help it
spip has quit [Ping timeout: 248 seconds]
spip has joined #ocaml
rgrinberg has quit [Ping timeout: 250 seconds]
<d_bot>
<Et7f3 (@me on reply)> Linear scan is an alternative register allocator. Register are faster to access than ram (stack) but space is limited (dozens of registers * 4 or 8 bytes) vs multiple GB. So compiler will try to manipulate most variables with register: if your code only have few local val/arg used at one point it should be easy to put almost all in register (I have seen a coding convention of max 4 args per fx with this rationale). I
<d_bot>
<Et7f3 (@me on reply)> The access time of register vs main memory depend also on the way you access data (main memory has cache) and also your hardware.
<d_bot>
<Et7f3 (@me on reply)> This matter mainly for CPU bound project
<d_bot>
<Bluddy> I really don't think it has much impact nowadays, given how big caches are (including L1 cache). A few more values spilled to the stack just aren't going to make a statistically significant difference.
rgrinberg has joined #ocaml
<d_bot>
<Bluddy> accessing fresh memory that isn't in the cache is easily going to dominate it, and that's going to be dominated by IO, etc
<Corbin>
It matters for processors with few general-purpose registers and no speculative execution or reordering. There was a recent era of 32-bit ARM and low-power x86, and maybe it'll be the case again in the future.
<companion_cube>
@Bluddy the top of the stack will be in the cache, sure
<companion_cube>
but you still pay to move stuff from/to the stack whenever you access it
<companion_cube>
for OCaml code it's probably not that important
<d_bot>
<Bluddy> so it is 3-5 times slower than a register access, depending on architecture
<d_bot>
<Bluddy> however, very few applications will actually feel this difference, given the cost of actually loading from memory or a lower level cache
<companion_cube>
yeah if you're at that level of optims, you want C++ or rust
<companion_cube>
avoid allocations, pointers, put more stuff on the stack, use simd…
<Corbin>
Those are good answers. An important nuance that they aren't bothering to point out is that "the register file" might not exist as a single location on-die. (Deja vu, did I just say this a bit ago?) A logical register might be implemented as something more efficient than a physical register. This isn't the case for cache, which claims to be fast RAM and usually *is* fast RAM.
<companion_cube>
also, if stuff is already in registers, you can manipulate it directly since most instructions operate directly on registers
<Corbin>
Yep. Recently I've implemented what I'm calling "term operations" or "term ops" for CAM. The CAM has one (1) register, and it turns out that the vast majority of bytecodes just operate on the register alone. All of my ALU stuff is done as term ops now.
<d_bot>
<Bluddy> what is CAM?
<Corbin>
CAM is the Categorical Abstract Machine. It's an 80s-era abstract machine from OCaml's history.
<companion_cube>
ah yeah it's the same for the modern bytecode VM I think
<companion_cube>
it has a stack and an "accumulator"
<qwr>
ocaml is Objective CAM Language ;)
<d_bot>
<Bluddy> yeah stack + accumulator is a pretty common design
<d_bot>
<Bluddy> I recently reverse engineered an animation engine from ~1989 and it used this format too
<Corbin>
Good times. I just wrote a program to animate my CAM bytecode. As my docs say, "this concept is perennial."
<companion_cube>
otoh, one of the most widely used bytecode stack VM (the JVM) has local variables, but instructions operate on the stack
<companion_cube>
so it's a bit the opposite :D
<Corbin>
VMs get weird when they're intended for JIT. Many of those decisions then get cargo-culted. Python's VM also has local variables in a "frame", which turns out to be suitable for JIT.
<companion_cube>
lua does, too
<companion_cube>
lua's instructions are funny, they operate on the local variables
hexology- has joined #ocaml
hexology has quit [Quit: hex on you ...]
aanmdsa has joined #ocaml
aanmdsa has quit [Client Quit]
neilthereildeil has joined #ocaml
neilthereildeil has left #ocaml [#ocaml]
troydm1 has joined #ocaml
troydm has quit [Read error: Connection reset by peer]
<qwr>
afaik none of these VMs were meant for JIT - i.e. JVM and python were created before JIT was popular and LUA creators probably didn't intend to use JIT and wanted just a fast bytecode interpreter
<qwr>
(official Lua still don't have any JIT)
<companion_cube>
hmmm I think the JVM was very explicitly designed for JIT
<companion_cube>
in the wake of smalltalk/strongtalk or whatever
<companion_cube>
(for python, sure. it was never designed to be fast)
<qwr>
maybe, but the local variables in byte code are probably primarily for aiding debuggers with direct mapping to source code
<qwr>
with debug info you can mostly recreate the source from java byte code with little ambiguity
<Corbin>
The locals were for speedups. Java was an iteration on JIT technology; its ancestor Self put all locals on the stack, and had a deliberately minimal bytecode with only like eight ops.
<companion_cube>
qwr: I think the locals are there to avoid the intricate stack manipulations you have to do in pure stack languages like forth
<companion_cube>
easier to compile, too
<companion_cube>
just allocate one local per variable in scope
<qwr>
seems you're right, gosling was involved with self and java had jit like in 2 years after initial version
<qwr>
and i learned that java unicode support originates from apples taligent...
<companion_cube>
alas they picked utf16 :/
<qwr>
somehow everyone picked utf16 in late nineties, and then about 5 years later started to curse it
Haudegen has quit [Quit: Bin weg.]
<qwr>
reminds the 640kB is enough joke
trev_ has quit [Remote host closed the connection]
bartholin has quit [Quit: Leaving]
<d_bot>
<Bluddy> how do you guys handle automatic serialization and deserialization with opaque types?
<d_bot>
<Bluddy> like, I want to serialize automatically, but also put in default values
<d_bot>
<Bluddy> for complex types
<companion_cube>
I'd have the opaque type export its own serialization?
<companion_cube>
unless it's an external type, is that your issue?
<d_bot>
<Bluddy> I don't want to serialize it
<companion_cube>
well put a serializer that does nothing, and a deserializer that returns the default value
<d_bot>
<Bluddy> can I get the output of the ppx derivers with dune somehow?
<companion_cube>
I use `ocamlc -dsource _build/default/foo/bar.pp.ml | less`
<d_bot>
<octachron> You can also use the ppx executable built by dune somewhere in `_build`.
<rgrinberg>
there's a dune describe subcommand that makes this easy now
Haudegen has joined #ocaml
zebrag has joined #ocaml
<d_bot>
<Bluddy> rgrinberg: which subcommand do I need?
<rgrinberg>
dune describe pp
hsw_ has joined #ocaml
bgs_ has joined #ocaml
daimrod1 has joined #ocaml
greenbagels has quit [*.net *.split]
fds has quit [*.net *.split]
klu_ has quit [*.net *.split]
daimrod has quit [*.net *.split]
dh` has quit [*.net *.split]
hsw has quit [*.net *.split]
bgs has quit [*.net *.split]
bgs_ is now known as bgs
fds has joined #ocaml
klu_ has joined #ocaml
greenbagels has joined #ocaml
<d_bot>
<Bluddy> trying `dune describe pp filename.ml`, I just get a printout of the file, with no ppx output
<rgrinberg>
does filename.ml belong to a stanza that use ppx?
<rgrinberg>
oh you might be using ppx_import, which uses staged_pps. I'm not sure it works for that
<d_bot>
<Bluddy> oh. dang
<companion_cube>
now that dune talks to ocaml-lsp, any chance it could provide a command to show the preprocessed file? :)
<companion_cube>
a lsp command*
<rgrinberg>
Sure but which lsp request should we use?
<companion_cube>
right, nothing that will display nicely in the editor
<companion_cube>
the .pp.ml file could certainly be a new buffer, but you can't make a new "go-to-preprocessed-file" command…
<rgrinberg>
It's kind of possible now perhaps
<rgrinberg>
We could add a code action for it that calls window/showDocument
<rgrinberg>
Could you make a feature request on the lsp side?
<companion_cube>
on ocaml-lsp? sure
<rgrinberg>
yes please
<companion_cube>
#721
<companion_cube>
thank you :)
<rgrinberg>
I might use this to add support for -dlambda as well :)
<companion_cube>
😍
<companion_cube>
tooling has improved considerably, thank you again rgrinberg
<d_bot>
<Bluddy> indeed
<rgrinberg>
np guys
<companion_cube>
the LSP server is a big deal; and dune is also indispensible at this point
<d_bot>
<Bluddy> thanks rgrinberg: I was able to debug the issue by temporarily disabling ppx_import
<d_bot>
<Bluddy> but ppx_import is the bee's knees
<rgrinberg>
yes, it's not a fundamental issue. describe pp was made by an external contributor, and he decided not to support staged_pps for an initial version
<rgrinberg>
perhaps you could convince him to add support for it
Tuplanolla has joined #ocaml
<d_bot>
<Bluddy> is there a way to export Random.State.t and then later import it?
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
adrien_ has joined #ocaml
kakadu_ has joined #ocaml
Anarchos has joined #ocaml
kandu_ has joined #ocaml
olle_ has joined #ocaml
Putonlalla1 has joined #ocaml
azimut has joined #ocaml
Cypi_ has joined #ocaml
Geekingfrog_ has joined #ocaml
tristanC_ has joined #ocaml
gentauro_ has joined #ocaml
bacam_ has joined #ocaml
waleee has joined #ocaml
emp_ has joined #ocaml
troydm1 has quit [*.net *.split]
kakadu has quit [*.net *.split]
olle has quit [*.net *.split]
gentauro has quit [*.net *.split]
emp has quit [*.net *.split]
perrierjouet has quit [*.net *.split]
bacam has quit [*.net *.split]
Putonlalla has quit [*.net *.split]
nore has quit [*.net *.split]
Geekingfrog has quit [*.net *.split]
notnotdan has quit [*.net *.split]
tristanC has quit [*.net *.split]
adrien has quit [*.net *.split]
kandu has quit [*.net *.split]
Leonidas has quit [*.net *.split]
johnel has quit [*.net *.split]
asm has quit [*.net *.split]
Cypi has quit [*.net *.split]
Leonidas has joined #ocaml
Geekingfrog_ is now known as Geekingfrog
johnel has joined #ocaml
troydm1 has joined #ocaml
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
perrierjouet has joined #ocaml
asm has joined #ocaml
Haudegen has joined #ocaml
nore has joined #ocaml
notnotdan has joined #ocaml
<d_bot>
<octachron> If you mean the domain-wide Random.State.t global, `Random.{get,set}_state `.
<companion_cube>
not serializable though, sadly
<companion_cube>
octachron: hey, how likely would these few string functions be accepted? to_hex/of_hex, possibly base64?
<companion_cube>
the stdlib is making progress but I think we lack a few crucial things for the 21st century, like json or, hmm, gzip :D
<octachron>
I would say very likely?
<octachron>
Random has many active maintainers.
<octachron>
(with many ="more than 3!" in OCaml land)
<sim642>
Just Marshal the state :P
gravicappa has quit [Ping timeout: 240 seconds]
<d_bot>
<leviroth> companion_cube: are you asking about Random.State serializations, or miscellaneous functions for the String module?
<companion_cube>
functions for the string module
<companion_cube>
being able to dump Random.State.t into bytes could be nice but well
dh` has joined #ocaml
szkl has quit [Quit: Connection closed for inactivity]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
rgrinberg has joined #ocaml
<d_bot>
<Bluddy> and to restore it
<d_bot>
<Bluddy> I can't believe Jane Street haven't needed to do that
<companion_cube>
they have their own (splittable) random generator, at least for tests
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bacam_ is now known as bacam
<d_bot>
<Bluddy> oh. interesting
<d_bot>
<Bluddy> well I think this is a necessary feature for many applications
<companion_cube>
never met this need :p
<companion_cube>
generally I'd rather use a seed and serialize that
<Corbin>
I didn't need it in [my offtopic language] at all. If I needed to do repeatable random state for tests, then I used a deterministic RNG and a fixed seed. For serious services, I used the system's CSPRNG via libsodium.
Serpent7776 has quit [Quit: leaving]
Tuplanolla has quit [Quit: Leaving.]
Haudegen has quit [Ping timeout: 260 seconds]
olle_ has quit [Ping timeout: 276 seconds]
xgqt has quit [Ping timeout: 276 seconds]
xgqt has joined #ocaml
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away,and yet it always breaks free.]