DonPellegrino

This episode of the Jane Street podcast (Signals & Threads) discusses a recent optimization to the GC (pointer prefetching) that's had impressive results. Part of why it has worked so well is the pointer tagging/63-bit integers.

Great episode, I highly recommend it to all interested in language runtime design.

https://signals-threads.simplecast.com/episodes/memory-manag...

> Lea became very slow in recent Intel cpus? News to me.

Article is from 2014. The "recent" CPUs they are discussing is the Sandy Bridge architecture launched in 2011.

See this discussion about the performance impact of LEA in Sandy Bridge: https://github.com/ocaml/ocaml/issues/6125#issuecomment-4729...

It's not bad at all https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...

This top bit is used by the garbage collector for performance. OCaml's GC is light enough that it simply does not feel like it exists at all. Integers also do not cause allocations.

Jane Street's blog explains the reasoning in detail[0]

[0] https://blog.janestreet.com/what-is-gained-and-lost-with-63-...

AMD has confirmed that they've been able to replicate the Linux bug and that it only happens on Ryzen, ThreadRipper and Epyc do not suffer from that issue.

Nordam Group | Fullstack Software Developer | Tulsa, OK | Onsite (relocation available)

We’re an independent development team inside The NORDAM Group building a brand new public web service. The aerospace industry we’re modernizing has yet to fully benefit from the data revolution. We pride ourselves on our “startup” approach: we leverage modern technologies and methodologies and we prefer results over tradition. By being a totally separate unit in a large corporation, we benefit from its support and extensive business network, without all the downsides that come with software development at larger companies.

Our product needs to handle information at scale, safely. We deal with items often worth tens of thousands of dollars or more. We do things the right way from the first time - cutting corners is not worth it in our case.

You know Ruby inside and out, both the pretty and the ugly. You can tell when a piece of code will be inefficient just by looking at it and you know how to optimize it. However, you are not married to any programming language and would welcome the opportunity to learn a new one on the job with open arms.

As an early dev hire, you will be in a unique position to work on virtually all aspects of our product and have a strong voice in product and technology strategy. This position is a great opportunity for a smart and ambitious developer to advance their career and have a major impact on a large, important and clean project

Contact me at simon.grondin@outlook.com and I'll put you in touch with the right people.

Nordam Group | Fullstack Software Developer | Tulsa, OK | Onsite (relocation available)

We’re an independent development team inside The NORDAM Group building a brand new public web service. The aerospace industry we’re modernizing has yet to fully benefit from the data revolution. We pride ourselves on our “startup” approach: we leverage modern technologies and methodologies and we prefer results over tradition. By being a totally separate unit in a large corporation, we benefit from its support and extensive business network, without all the downsides that come with software development at larger companies.

Our product needs to handle information at scale, safely. We deal with items often worth tens of thousands of dollars or more. We do things the right way from the first time - cutting corners is not worth it in our case.

You know Ruby inside and out, both the pretty and the ugly. You can tell when a piece of code will be inefficient just by looking at it and you know how to optimize it. However, you are not married to any programming language and would welcome the opportunity to learn a new one on the job with open arms.

As an early dev hire, you will be in a unique position to work on virtually all aspects of our product and have a strong voice in product and technology strategy. This position is a great opportunity for a smart and ambitious developer to advance their career and have a major impact on a large, important and clean project

Contact me at simon.grondin@outlook.com and I'll put you in touch with the right people.

F# lacks all the most advanced module capabilities of OCaml, is tied to the CLR and isn't free of the Null problem.

It checks that the first column of each row is not null, that's what the '1' stands for.

This is a "10 tonne truck" we're talking about. They also mention how once they needed 3 trucks to pull them out.

It would have to be Core_kernel, the subset of Core that doesn't interact with the runtime or OS. I'm very curious about this and would like to know, too.

You're confusing UdeM with UQAM. UdeM is the more prestigious one by far, but it's also smaller than UQAM. There's at least 6 universities in Montreal, it's easy for outsiders to get lost.

I pick some technology that has the following characteristics:

- A complete paradigm shift. I want something that will force me to rethink how I approach problems. I want to force my brain to develop new pathways, so to speak.

- Something will at least a minimum of documentation and community online. I've had to abandon dreams of learning some really awesome language before (ATS) because there was simply no resources and that would make my progress too slow.

- Something that could be fun to use in a side project. I need to be able to find occasions to use it. I learn best by doing rather than by only reading. If I can't think of an application, then I won't be able to become proficient, so I'd rather learn something else.

- And finally, it has to be something fun that feels like falling in love with programming all over again.

EDIT: I usually don't pick more than 1 technology to REALLY LEARN per year, so I don't make these decisions lightly.

The point of the article was to show how the % of used memory will affect performance in a non-linear manner. It's obvious once you know, but it's not if you've never experienced it before.

There's also [Bottleneck](https://github.com/SGrondin/bottleneck) for more fine grained concurrency.

Indeed! It was explained in the 3rd article of this series: https://mastermind.atavist.com/he-always-had-a-dark-side

The frontend part of my team is using Mithril for a serious project. They seem to be enjoying it. It was chosen for the reasons you listed.

When open source implementations, reference guides/manuals and public internet forums (in that order from biggest to smallest sign) start being ubiquitous.

Thanks, I'm honored!

Author here, I originally posted this to https://www.reddit.com/r/ocaml to gather some feedback prior to posting it here. It was a surprised when my boss told me "Hey, you're top 10 on HN right now". Glad to know someone liked it enough to post it here before I could :)

It's something I've been working on for quite a while, because I wanted to answer the question "Why do you like OCaml so much and why should I care?" once and for all. Hope you enjoy it.

Speaking of OCaml, all the traffic going to my blog is going through HARchiver [0], a very high performance proxy and reverse-proxy 100% written in OCaml that gathers datapoints for use with Mashape Analytics [1]. Disclaimer, I work at Mashape.

[0] https://github.com/Mashape/HARchiver

[1] https://www.apianalytics.com/

Check out Kong, even easier, built on nginx and better docs too: https://github.com/Mashape/kong

Napoleon was absolutely not comparable to Hitler in terms of popularity. Your assumption is a classic historical question that many people have asked themselves since WWII. It has been debunked over and over.

This, I'd love to give it a try, but I'm not going to touch it until there's a Makefile and a minimal documentation. Until then, it feels like an engineering experiment, not a major company-backed project.

You sort of can with functors or GADTs.

Why is this even being upvoted? it confuses important concepts and what isn't wrong is irrelevant.

The thing is that numbers are usually wrapped in other things, like objects, hashtables, arrays, etc, and OCaml is a beast at dealing with that kind of code.

From a purely numbers perspective, its operations on integers have to use the LEA instruction instead of ADD (for example) because of the 1-bit tag, which slows things down a bit, but the speed at dealing with symblic code as I explained above more than makes up for it.

For those asking "How the hell does OCaml not support multicore in 2015????", this is my reply, crossposted from /r/ocaml:

You can make OS level threads, but they can't be both running at the same time due to the GIL (Global Interpreter Lock). Then why are they even there you might ask? Because it allows you to do a blocking call on a thread and to keep executing other stuff in the main thread. Other languages that have a GIL (and the same restriction) are Javascript (including Node.js), Ruby and Python.

Now, IN PRACTICE, things are a bit different. You're never gonna make your own thread to block on things. You're gonna use Lwt to manage all your concurrency so you can do tons of blocking stuff at the same time and combine the tasks nicely without ending up in a Node.js-style "callback hell".

But still, even with tons of concurrency, you don't have parallelism. It's all you need for 98% of your programs, but if you then need to do heavy number-crunching it won't be enough. This is the exact same situation that happens in Node.js, Python, etc, except that OCaml is massively faster than those languages, so even some CPU-bound work is acceptable because OCaml is really performant.

Currently, there's 2 options if you wanna do CPU-bound work: you can use ctypes to call C code easily (from Lwt_preemptive) and then release the lock from within C with caml_release_runtime_system(), so your C code will be truly parallel (and running in the thread pool automatically managed by Lwt_preemptive), and you can call caml_acquire_runtime_system() before returning the result back to OCaml to get the lock back and merge back with the normal code.

The second option is to do an oldschool fork() and communicate with message-passing. Or have a master that manages workers and communicates with ZMQ, HTTP, TCP, IPC, etc. Or use a library that does it all for you like parmap, Async Parallel, etc etc.

What this "multicore support" means is that you'll be able to have threads in the same process that run in parallel because the GIL is going away. In practice it'll probably be implemented directly into Lwt so you'll be able to do something with Lwt_preemptive and just tell it to run some function in a separate thread and then use >>= to handle its result. It's gonna be simpler than both options I described above.

Again, more technical information is available in my r/ocaml post

In practice the generated code is already extremely fast and the 1-bit shorter ints help make the GC one of the fastest I've seen. If you do a lot of floating point calculations, you can put your floats in an array and they'll become unboxed.

More information is available

in my original post in r/ocaml: https://www.reddit.com/r/ocaml/comments/36ninh/403_scheduled...

in the repost in r/programming: https://www.reddit.com/r/programming/comments/36ppx0/ocaml_4...

If you look at "old timey" boxing pictures, you'll see that their stance is very different. Rather than protecting their chin and their jaw, they're protecting their upper body because that's where most of the hits would go to. People ONLY started dying in boxing once gloves were introduced.