6 ms·

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 kerne

by kyrra 7y ago

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/src/ixy/c/ixy.c https://github.com/ixy-languages/ixy.java/blob/master/ixy/sr... C#: https://github.com/ixy-languages/ixy.cs/blob/master/src/ixy_c/ixy.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/Java-garbage-collectors.md https://github.com/ixy-languages/ixy-languages/blob/master/J...

pjmlp 7y ago
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.
- voltagex_ 7y ago
  Page 15 of https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/ixy-writing-user-space-network-drivers.pdf https://www.net.in.tum.de/fileadmin/bibtex/publications/pape.... They couldn't access mlock in .NET. The amount of C involved is tiny.
  - pjmlp 7y ago
    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.
    - voltagex_ 7y ago
      Sorry, wrong link: https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-ixy-c-sharp.pdf 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."
      - optimiz3 7y ago
        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.
      - pjmlp 7y ago
        So something like [DllImport(..., EntryPoint = "mlock")] extern int MLock(UIntPtr addr, uint len); And then getting the pointer either from MemoryMappedViewAccessor or AllocHGlobal?
      - Const-me 7y ago
        > 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/49f3da0ae744194fbf5be53552735431 https://gist.github.com/Const-me/49f3da0ae744194fbf5be535527...
kartickv 7y ago
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.
- Arnt 7y ago
  Can you suggest ways to measure those things?
  - kartickv 7y ago
    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.
    - Arnt 7y ago
      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.
      - kartickv 7y ago
        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.
emmericp 7y ago
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.
dep_b 7y ago
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.
- emmericp 7y ago
  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.
  - skohan 7y ago
    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.
    - emmericp 7y ago
      The Semaphore is only used during initialization, never in the critical path, see profiling results in the main repo
  - jmull 7y ago
    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.
    - emmericp 7y ago
      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
oaiey 7y ago
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.

by kyrra 7y ago

pjmlp 7y ago

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.

voltagex_ 7y ago
Page 15 of https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/ixy-writing-user-space-network-drivers.pdf https://www.net.in.tum.de/fileadmin/bibtex/publications/pape.... They couldn't access mlock in .NET. The amount of C involved is tiny.
- pjmlp 7y ago
  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.
  - voltagex_ 7y ago
    Sorry, wrong link: https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-ixy-c-sharp.pdf 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."
    - optimiz3 7y ago
      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.
    - pjmlp 7y ago
      So something like [DllImport(..., EntryPoint = "mlock")] extern int MLock(UIntPtr addr, uint len); And then getting the pointer either from MemoryMappedViewAccessor or AllocHGlobal?
    - Const-me 7y ago
      > 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/49f3da0ae744194fbf5be53552735431 https://gist.github.com/Const-me/49f3da0ae744194fbf5be535527...

kartickv 7y ago

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.

Arnt 7y ago
Can you suggest ways to measure those things?
- kartickv 7y ago
  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.
  - Arnt 7y ago
    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.
    - kartickv 7y ago
      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.

emmericp 7y ago

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.

dep_b 7y ago

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.

emmericp 7y ago
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.
- skohan 7y ago
  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.
  - emmericp 7y ago
    The Semaphore is only used during initialization, never in the critical path, see profiling results in the main repo
- jmull 7y ago
  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.
  - emmericp 7y ago
    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

oaiey 7y ago

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.