I think it's problem of believe and the cure is simply trying it
out.
Belief in what exactly? I'm not arguing that your solution is fast. It can even be faster than LuaJIT 2 (though I still want to do benchmarking). But this does not make it viable for my production environment. I believe that I thoroughly explained the reasons yesterday — the risk is too high, the benefit is too low.
On 3/20/11 10:50 PM, Alexander Gladysh wrote:
On Sun, Mar 20, 2011 at 22:28, Henning Diedrich <hd2010@eonblast.com> wrote:
On 3/20/11 1:49 AM, Alexander Gladysh wrote:
On Sun, Mar 20, 2011 at 03:33, Henning Diedrich <hd2010@eonblast.com> wrote:
Fleece is a ~ 10 times faster Lua to JSON converter.
I would very much like to see comparison of this module performance
with fine-tuned LuaJIT2/FFI implementation.
Totally seconded. I tried and didn't get too far, e.g. with JIT+Yajl,
JIT+JSON4.
Um. No, I mean plain Lua code under JIT, without bindings — assuming
"ideal" compiler you do not need any if you're only generating JSON,
not parsing it.
Well, again: because it is very much faster.
Sorry, where is the "Why?" question to this because? Probably lost in quotations.
It's a byproduct of an actual problem, and its solution, so let's
leave the theorizing + principles level behind.
If you simply can't believe it, the right thing is to try it out -
but insisting on disbelief doesn't change reality. Well, at least
not that of others.
Again, believe *what* exactly (see above)?
So if you would like to discuss, you are invited to try it out. That
might make all further talk idle.
AND I will grant the possibility any time that I am wrong.
I still am not sure though that you actually yet looked too closely
at Fleece. You might have found described (and tried out) that the
last 10% of performance come from hand written assembler.
And so what? This is one more reason for me to discard this library — at least until I will be *ultimately* pressed by the performance in JSON serialization.
It tells you where the C source is at that assembler only gets
another 10%.
JITs can get faster than C, breaking that sound barrier is their
real magic. But I don't know that they can get faster than manually
tuned assembler. And it's not like gcc is too stupid either.
I'm not discussing the speed. I do not know why are you doing it.
Regarding the (not) need of bindings, you could of course build a
Firewall with a plain packet filter, which could cover a couple of
use cases. It's definitely not what we needed.
Just as the existence of packet filters is no sufficient argument
against the existence of Firewalls.
Sorry, but I fail to see why would you mention this here.
But still, if you gave me any simple snippet of source that
generates JSON, I'll be happy to benchmark it for you. Unless it's
simply 'print("[1,2,3]"), you might be surprised.
See remarks about speed above.
I did it before starting Fleece and it was not convincing. Here is a
recent experiment with LuaJIT, from a source, I think that Roberto
wrote originally:
<snip>
I'll get back to it when I get my hands on the benchmarks.
No, it's native Lua. You could use this instead of JSON4.
Can you please add it alongside of JSON4 to your benchmarks?
As I tried to convey in other posts in this thread, I consider the
programming practice when one accesses private internals of a complex
third party system to be inacceptable in all, except the most
exceptional cases.
You're entitled to your opinion but let's look at facts.
There was a use case we needed this for, so it makes little sense to
argue that it's useless.
I never said it is useless. Please re-read my post — I repeated at least three times that I see the use cases for this.
There was a clear priority that guided the development. It makes
less sense to state that priorities can be different. They sure can.
Also, Lua is not that complex and it is sufficiently slow with
releases, as explicit policy.
To give some idea, here is the part where Lua 5.1 and LuaJIT 2 must
differ. Lua 5.1 first, then LuaJIT
<...>
This changes little.
You still violate the contract of the library.
This is the thing that violates my "code of engineering" in a
hard way.
But the golden rule can be overwritten by tools by people going by
the initials of M.P.? Or what is the consistency with the
exceptions?
LuaJIT 2 was throughly tested by our team and a few of fellow teams before it was accepted into production environment. Besides, in case of LJ2 it is not a case of violating the contract — it is a compatible implementation, not a dirty hack.
I just want to know, why did you do this in that way?
Speed. If you get something twice as fast, or even five times
faster, it allows for new things.
Specifically for us, reducing shards, empowering game designers.
I think the problem is just that you don't believe how much this was
a bottle neck and that it's possible to speed things up so much.
Care to share some numbers? (Sorry, I maybe missed them in your text.) What I'm interested in is: what is the percentage of total time spent by your system in the JSON serialization before and after Fleece was integrated. Also the average size of JSON data chunk is of interest.
Alexander.
