Hacker News Reader

Comment by kyrra | Hacker News Reader

There is discussion about C# and Java being faster than Go, but one interesting thing to note is that both C# and Java have to use C to interface with the kernel.

Java: https://github.com/ixy-languages/ixy.java/blob/master/ixy/sr...

C#: https://github.com/ixy-languages/ixy.cs/blob/master/src/ixy_...

Java needs a bit more C to make it work. C# only seems to need it for DMA access. But when you look at the Go code, they got away with being pure Go and using the syscall and unsafe package. So that's at least one plus for Go.

(the main readme calls this out, but at least one thing worth mentioning here too).

As a Java coder for my day-job, I do like the breakdown they have of the performance of the different GCs for their Java implementation. https://github.com/ixy-languages/ixy-languages/blob/master/J...

View on HN

You can perfectly do in same in C# just like they did with Go.

We do it all the time in Windows low level coding within .NET, the reason why they didn't beats me, most likely not knowledgeable enough of .NET capabilities.

As for Java, hopefully with projects Valhala, Panama and Metropolis Java will finally have the performance language features that should have been part of Java 1.0.

Page 15 of https://www.net.in.tum.de/fileadmin/bibtex/publications/pape.... They couldn't access mlock in .NET. The amount of C involved is tiny.

The document has 14 pages and the only information I see is the mlock description, nothing about how they were unable to use System.Runtime.InteropServices, unsafe and DllImport to make use of it.

Sorry, wrong link: https://www.net.in.tum.de/fileadmin/bibtex/publications/thes...

>"As C# cannot call mlock or get a raw pointer from a memory mapped file, DMA memory allocation is performed in C and called with the C# P/Invoke mechanism. Fortunately, this is the only instance of the driver calling a C function and the total amount of C code is only around 30 lines."

Odd that they couldn't call mlock using PInvoke; it sounds like the PInvoke export metadata wasn't there rather than C actually being required.

On Windows even for really obscure FNs you can almost always PInvoke if you know the offsets, and if you really want to be evil you can traverse the PEB. There isn't much in low level terms that is beyond the reach of C# since you can manipulate memory directly. I've also accessed hidden COM interfaces by traversing V-Tables using similar direct memory techniques as you would in C.

> C# cannot call mlock or get a raw pointer from a memory mapped file

Why not? What am I missing? https://gist.github.com/Const-me/49f3da0ae744194fbf5be535527...

So something like

    [DllImport(..., EntryPoint = "mlock")]
    extern int MLock(UIntPtr addr, uint len);

And then getting the pointer either from MemoryMappedViewAccessor or AllocHGlobal?

Neither C# nor Java have C in the hot path; C# uses unsafe mode, Java sun.misc.Unsafe. JNI/C# native calls are either in the initialization or for an alternate implementation to compare them.

I can't really believe the Swift implementation needs to be that slow. Objective-C used to be 100% C compatible and Swift more or less has complete bridging to C because of the need to use these API's.

Objective-C was often called slow because iteration NSArray was much slower than doing it in C. Well, if you needed to do it fast in Objective-C you wouldn't do it using the user friendly and safe (for 1984) higher level objects.

I think only Rust really allows you to write really safe and still really fast code though.

Yes, we could write most of the critical part in C and it would probably be faster. But then it wouldn't be a Swift driver.

Are these benchmarks single-threaded? I took a brief look at the Swift codebase, and I noticed that you are using semaphores, but there doesn't seem to be any parallel execution anywhere in the project.

The Semaphore is only used during initialization, never in the critical path, see profiling results in the main repo

I don't think you need to write the critical part of the driver in C to speed up the swift implementation.

I clicked through to a performance analysis showing ARC taking about 3/4 the time (in the release build).

You don't really need to be doing a lot of ARC in the inner loops if you don't want to.

Yes, we do if we want to have an idiomatic interface for the application on top of the driver.

Pull requests proving otherwise are welcome

I don’t think it’s idiomatic to do a bunch of unnecessary memory management in inner loops, right?

The memory management is being done by the language.

ARC is implemented at the language level but it's not required. You can use it when and where you like.

One fundamental aspect of swift is the distinction between reference types -- which are reference counted -- and value types -- which are not. Generally in Swift you'd use a value type over a reference type unless you have reasons not to. E.g.: https://developer.apple.com/documentation/swift/choosing_bet...

I mean, I don't know what the right approach for this library is. The authors are going to have to fix their own code. IMO, coming up with a demonstrably poor solution and trying to defend it as "idiomatic" is pretty weak.

Well if the C# and Java implementations use C they're definitely not C# and Java drivers. But you don't need to use C directly, just use the C features that are supported by Swift itself.

C isn't in the critical path of either of those two implementations. GP is saying that it would be in a Swift version. Whether or not that's accurate I have no idea.

> I think only Rust really allows you to write really safe and still really fast code though.

Snabb (https://github.com/snabbco/snabb/) is written in LuaJIT . I assume an equivalent project in Rust would be a lot more expensive in implementation time and also lines of code.

There is also Common Lisp and SBCL in particular, which can produce extremely fast code without compromising on safety.

The Techempower Benchmarks covering a more professional state on that. When coded right, the frameworks typically are on-par in performance in the Plaintext area (where only processing matters). In the end, these drivers were mostly thesis documents.

It would be good to have them measure aspects other than performance, like how long it took to build each, was there a learning curve because it's an unfamiliar language, how secure the resulting code is, etc.

I'm pretty sure that an exhaustive answer to your last question is "the history will tell" with additional assumption that all those drivers would be deployed in many production environments.

An approximate answer is useful too.

Can you suggest ways to measure those things?

To measure how long it took to build it, track how many days it took to implement in each language.

To measure how secure the resulting code is, have a test suite of malformed packets or other input and see how many of them the code in each language handles.

I'm not qualified to judge the latter. But I can about the former.

That measures how well a particular developer takes, with some noise induced by the working environment (say there's construction noise during python week, not during java week, or more meetings one week than another, or the developer's has relationship troubles at home). Randomness happens.

Deducing a number that's more generally valid requires having n workers doing the same work and then doing statistical analysis. Happily that also takes care of the single-worker problem. Still, the cost of the experiment easily rises by a factor of twenty or a hundred, depending on how well the noise can be controlled and how much accuracy is needed.

Asking for improvements that would increase the cost of an experiment by many thousand per cent is a %$#@!%#@! $%#@!%@#$ thing to do. IMO.

The perfect is the enemy of the good. I'll take a rough estimate over no data at all. If the Python guy took 10 days and the Java guy took 20, then the conclusion is that Python is more productive than Java. Is it more productive exactly by 100%? No, maybe 60%, or maybe 120%. But whether the benefit is 60% or 120%, I know which tool I'll choose next time.

Reply on news.ycombinator.com