From the numbers I don’t think VM then is a good idea :(
but mlir is still a valid cause, mlir gets adopted by llvm and is very performant.
EDIT: I suspect this depends on your program’s characteristic, whether it’s IO-bound or
Cpu-bound, for typical web apps that’s IO-bound.
I’m reading this one now
It seemed Java outperformed Go:
And here:
rainbow/impl/hashtable/README.md at master · RemyDeWolf/rainbow · GitHub
Java can outperform a lot of languages, certainly, but it is unique in that the JVM has had millions of dollars a year invested into making it fast for almost 30 years. Crystal does not have anywhere near that level of investment. You are not comparing the same things.
An app can’t be I/O-bound. A single HTTP request can be I/O-bound when it comes to latency (when the CPU time per request is tiny compared to the time spent waiting on DBs, caches, etc), but all it means for an entire app to be I/O-bound is that it has more CPU capacity than is required. It’s either low-traffic or overprovisioned, but calling it I/O-bound is inaccurate.
Even when you’re doing primarily network I/O, that I/O still requires CPU for the syscalls required to send the data over the wire, serialization to and deserialization from wire formats into language- and framework-level objects, and encryption for TLS. You can still saturate CPUs with I/O.
then let the interpreter go down the VM path, then
someone in the future can develop some rails-like framework,
so if modify one file and save, refresh browser and sees the change.
I have no evidence to support this, but I believe that if everything that can be done in Ruby can be done in Crystal, the result will be a programming language with the same execution speed as Ruby. Over the past few years, many people have tried to speed up Ruby. There has also been a lot of investment (compared to Crystal). I don’t think there will be a free lunch.
quite the contrary, the ruby is slow because ruby VM still needs to support
a lot of dynamic features, while crystal VM can be fast because it only
needs to support static features.
Even if that is correct, if you really want to use VM, it is still better to modify a simple Ruby implementation like mruby/c or picoruby than to modify Crystal. I thought these used a common bytecode with mruby.
Have you read the long discussion in the thread presented by MistressRemilia? Aside from VM, incremental compilation is a feature that does not exist because it is difficult to achieve, even though many people want it.
Does the concept of compiled objects/libraries without type definitions exist in any other programming language?
If you truly believe it can be done the way you say, by all means give it a try
This is the best result, i don’t think you will get any support from core member, just fork, and try it.
I would rather explore the multi level bytecode path,
compiling *.crgb → llvm ir, to implement incremental compilation,
but guess I have to learn llvm ir first, a lot to learn.
Is there any existing efficient binary Marshal protocol?
I found msgpack-crystal, but from the example
it seemed has field names which I don’t want have,
I only want to efficiently marshal ASTNode.
crystal-community/msgpack-crystal is the easiest to use. I use it as the serialization format for Armature::Cache, so any MessagePack primitive type or any object that includes MessagePack::Serializable can be memoized in the cache trivially:
getter search_results do
cache.fetch "search#{normalize_params(params)}", expires_in: 10.minutes do
Search.new(params).results
end
end
What field names are you talking about that you don’t want to have, though? It doesn’t force any fields on your objects.
struct Thing
include MessagePack::Serializable
# Provide a default initializer because
# MessagePack::Serializable defines one to initialize from a
# MessagePack::Unpacker instance.
def initialize
end
end
# Serializes to a single byte with no fields serialized
pp Thing.new.to_msgpack # => Bytes[128]
There’s also jeromegn/protobuf.cr which is theoretically more performant (I need to check benchmarks) but requires a lot of ceremony. It isn’t going to be transparent the way MessagePack::Serializable will.
There isn’t anything like Ruby’s Marshal library, but IIRC that’s based on MessagePack anyway.
@jgaskins thanks for the information.
I don’t understand you, then how do you make it interact with crystal?
I know nothing about this field. But I can easily imagine that creating a VM is not an easy task. So I would just start by observing and modifying small Ruby implementations like picoruby or mruby/c. If you can make a VM from the beginning, you don’t need to do this.
Crafting Interpreters is a great introduction to language crafting, bytecode, runtimes and language VMs for those willing to take a look if you’re not familiar with creating languages, VMs and such.
Cheers,