Thank you for the insightful comment. Facebook is no worse than any other communication channel. I do not like its realname policy, but it's not unprecedented - an absolutely voluntary FidoNet in 1980-1990s also required real names. And there are a lot of people who don't abide by it anyway.
IMHO: live and let live. If anything, I'd prefer sites to have some ads than paywalls. I'm Okay with a reasonable amount of advertising, there's no free lunch after all. And sometimes I learn about existence of new products that way.
Uhm, not really:) I used Fido which was almost the same. But both have much higher latency than Twitter, and what's worse, messages tend to grow in size (and time needed to consume them). Twitter's forced laconicism is very good at keeping discussions short and focused.
I may be missing something, since I haven't tried all of them, but it seems that none of those platforms can be called an "asynchronous IRC"? That's the appeal of Twitter for me:
Like on IRC, nobody expects you to write blog posts but short messages.
Like on IRC, you are talking to complete strangers and can be anonymous if wished.
Like on IRC, you can mention anyone and the rest can join the conversation if they want to.
Unlike on IRC (not accounting for bots), each message is automatically logged and can be shared via a unique and permanent URL.
Oh, and like on IRC, technically minded people tend to gravitate to the platform. Is there anything except Twitter that would offer the same features? There used to be identi.ca, but seems like it's gone now.
Ok, I should have said "surge of refugees from both Syrian and Ukrainian wars that highlighted inefficiency of EU bureaucracy and its inability to timely accommodate them".
When reaching out via Twitter, the conversation is public - and you cannot share a phonecall. As for other services, what would they be? Facebook is too personal, at least for me - I tend to not friend people whom I didn't meet. On Twitter I follow anyone who tweets on topics I'm interested in.
Not just English speaking word. I can give personal account that Poland is also affected by increased tensions between "right" and "left", to the point that the left set up a "Democracy Defense Committee" and does regular anti-governmental marches, while conservatives "unmask" them as traitors. Russia has seen its conservative "Movement against illegal immigration" banned by Putin due to concerns that it is leading straight to disintegration of the country by attacking (nominally) Russian citizens from North Caucasus.
Not from my personal experience, but my friends living in Hungary (remember Putin-leaning Orban?) and Scandinavian countries (remember Breivik?) are saying that intra-country social tensions are on the rise there too. The "migrant crisis" that is affecting the Europe at large is only exacerbating this.
Could you provide a bit more context? I'm interested, but I cannot find a reference of Microsoft ever providing Win32 implementation for Unix. Did you maybe mean SFU (which would be the other way around)?
Not sure. They are often configured with additional software (e.g. https://steelseries.com/engine), but I did not need any of that just to use such keyboards on Windows. However, since Windows installs USB drivers automatically when you plug the device (either from device partition or downloading from the net), I cannot 100% tell whether a special keyboard driver was needed or not. I guess I could check in Hardware Manager but I'm too lazy to boot that machine right now:)
#3 (X server) is not so guaranteed these days. On an unrelated note - systemd is actually a positive development in that context (of standardization Linux ecosystem).
Yes. Pretty much no existing API would be applicable since the abstraction jumped down several levels - like going from Java to C. You are now allocating and freeing memory buffers on the hardware, filling them out with the complete pipeline state information and passing to GPU to execute as is. I guess one could bolt this onto existing OpenGL API (NVidia tries to do that with GL_NV_command_list), but a) it is still higher level and b) interaction with the rest of GL remains problematic implementation-wise. Naturally a question arises: if that part of API is not interoperable with the rest, why not just separate the two?
That is very true. Software may be written against "standards", but it is tested and optimized against other software. Linux is not a binary stable platform, and you can have two users who claim to run Linux but share almost nothing except the kernel and possibly libc. How can a big software house test and optimize the game? The test matrix would be unreasonable! In order to ship software for Linux, one has to either limit support to particular distribution and drivers, or to waive all guarantees.
Curiously enough, gaming keyboards can have problems on Linux: https://www.reddit.com/r/linux... - I experienced it myself. I guess it's because of extra functionality (programmability, color lights etc)?
He does forbid redistribution of the said binary drivers together with the kernel, so you cannot have them "out of the box" - user has to be the one making the "mix" of proprietary and non-proprietary code. And Stallman does put limitations on the developers - their philosophy essentially fights the contractual freedom between them and their users. Gladly, it is about to die finally, most recent and influential projects (clang/LLVM, docker, nginx) shun GPL.
You seem to contradict yourself. If you're fine with proprietary software (I am as well), then why are you against "trusted path" in the kernel - in what way proprietary kernel is different from a proprietary user application? Are you going to access their content not on their, but on your terms? If not, then why does the existence of the said path matter to you? Just install untrusted Linux kernel and forfeit your ability to access paid content.
Vulkan is not close to OpenGL at all, the design API is completely different. OpenGL has few thousands APIs, some of them are obsolete, Vulkan has 100. "Hello triangle" program in OpenGL (depending on the version) is a few tens of lines, but about 600 for Vulkan.
No, I'm saying it performs as well as C++ in most cases. Virtual method handling is one example as to why, the JIT has a better view at execution time as to what can and can't be inlined, so it can inline much more than a statically compiled C++ program possibly can.
You realize that JIT is inherently limited to a tiny bit of program which it compiles? JVM cannot spend neither time nor RAM building a whole program tree and making global optimizations like compilers can. And by the way, if you think that compilers are limited to static analysis only - there's also profile-guided optimization.
Well that's precisely the problem you face if you don't have an explosion of optimised binaries, unless you want to accept that the JVM is going to optimise more efficiently. It's not just about compiling for different architectures, it's about the JIT automatically being able to optimise to take advantage of extensions, and other hardware that may be present too. It can optimise dependent on amount of RAM, cache sizes etc. - something that just isn't known when you compile a plain old generic C++ binary for, say, the generic x86 platform.
But there are a number of other things it can do better too - better loop vectorisation (as a result of better inlining of virtual functions) and more efficient heap allocations for example.
In theory, it could do that. But if you do a reality check, you'll find out that JVMs right now are pretty mediocre compilers that lack even basic optimizations. Again, everything that JVM does, can be done by a compiler, but not vice versa. Compilers have nearly unlimited time and can spend gobs of RAM analyzing the program. They can use profile-guided optimization, allowing you to gather stats from a compiled program and then recompile it to better account for runtime behavior - if needed.
Oh, and while we're at it, fine-tuning assembly with specific CPU in mind does not matter these days except for SIMD ops. Waiting for memory accesses dominates CPU time - and here Java is at inherent disadvantage because you cannot really control memory layout of your data.
"Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance."
This is nonsense. It depends entirely on the application. A heavy load web server for example may not really be I/O bound in the slightest depending on the size and what it does. Bulldozer is designed for optimisation of performance per watt, you're again confusing cause and effect as to why some things are the way they are.
Before you call this nonsense, go read some analysis and check benchmarks.
"That's not a problem of Java, though, but all managed languages -.NET also sucks."
Really, the problem is simply that you don't understand managed languages. Your understanding of the optimisations performed by JIT compilers is clearly woefully inadequate to being making this sort of comment. Your comments on server applications just don't even make sense for the most part to the point I'm not even sure you have the slightest grasp of what sort of things servers commonly serve.
"Microsoft tried to build an OS which would be.NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native:)"
This is just further nonsense. There was a Microsoft research project to try and build such a thing, and they did, and open sourced it. I don't know what you mean by "Now they are going native:)", they've always been native with
You are very optimistic. Right now even C++ compilers (which, believe me, are very much performance-oriented and rather are not memory-constrained) have problems with producing a good vectorized code, but thanks God we have assembly intrinsics and use them a lot. For JVM, that is even harder for multiple reasons (and unfortunate - historical - choice of Java bytecode is one of them). Sure, there's a broad class of software where performance does not matter, but as I said again, that is a boring software I don't want to work on. Writing such software is better to be outsourced somewhere where people crave for money more than I do.
As for HFT, I don't think that using Java is a good decision. If you can optimize for certain (best in its class) hardware, why do you need to hop through all the extra abstraction layers of Java? Sure you probably can, but it's like artificially limiting yourself.
JIT is generic in a sense that each program (and even different parts of a single program) is different and you cannot base them all on a common framework. E.g. in C++ sometimes you have to abandon STL at all because you cannot allow dynamic memory allocation (and memory fragmentation it causes). I wouldn't say that "Java performs as well as C++", unless you are speaking about UI-heavy programs where bottleneck is user input - or, alternatively, C++ programs written by people who don't know how CPUs implement a virtual method call and why it's slower than a non-virtual one.
Yeah, with native languages you are bound to a specific architecture (and even variations of it, e.g. AVX, SSE), but is it better to be a jack of all trades and master of none? And also, there's no "explosion of binaries" anymore - unfortunately, the number of architectures available is continuously shrinking (kind of undermining that design goal of Java). "Boring" native software that is not performance-tuned may very well ship just a generic binary targeted at, say, all Pentium IV and higher CPUs.
Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance. That is also the reason why Java can be used server-side without much problems, too. However, once you bring it to desktop, where performance matters, it starts to suck immediately. That's not a problem of Java, though, but all managed languages -.NET also sucks. Microsoft tried to build an OS which would be.NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native:)
Sure, when I'm forced to use Java (e.g. Android), I immediately use the JNI window to escape. I am not interested in "benefits" of Java, if it means that I need to waste even more time trying to profile the application. Is there any low-level Java profiler, by the way, which would tell where CPU is burning cycles in your code at? Down to the level of assembly - i.e. something like perf annotate.
Slashdot Mirror
Isn't Uber "Over" in German anyway? Kinda prophetic.
Thank you for the insightful comment. Facebook is no worse than any other communication channel. I do not like its realname policy, but it's not unprecedented - an absolutely voluntary FidoNet in 1980-1990s also required real names. And there are a lot of people who don't abide by it anyway.
IMHO: live and let live. If anything, I'd prefer sites to have some ads than paywalls. I'm Okay with a reasonable amount of advertising, there's no free lunch after all. And sometimes I learn about existence of new products that way.
There's no NWO. There's a scared, weak Europe of 450M people who are afraid that ~1M hungry and dirt poor refugees will take over.
Uhm, not really :) I used Fido which was almost the same. But both have much higher latency than Twitter, and what's worse, messages tend to grow in size (and time needed to consume them). Twitter's forced laconicism is very good at keeping discussions short and focused.
I may be missing something, since I haven't tried all of them, but it seems that none of those platforms can be called an "asynchronous IRC"? That's the appeal of Twitter for me:
Oh, and like on IRC, technically minded people tend to gravitate to the platform. Is there anything except Twitter that would offer the same features? There used to be identi.ca, but seems like it's gone now.
Ok, I should have said "surge of refugees from both Syrian and Ukrainian wars that highlighted inefficiency of EU bureaucracy and its inability to timely accommodate them".
When reaching out via Twitter, the conversation is public - and you cannot share a phonecall. As for other services, what would they be? Facebook is too personal, at least for me - I tend to not friend people whom I didn't meet. On Twitter I follow anyone who tweets on topics I'm interested in.
Twitter is really good at reaching out to people directly and in a semi-realtime fashion. It's like asynchronous IRC.
Not just English speaking word. I can give personal account that Poland is also affected by increased tensions between "right" and "left", to the point that the left set up a "Democracy Defense Committee" and does regular anti-governmental marches, while conservatives "unmask" them as traitors. Russia has seen its conservative "Movement against illegal immigration" banned by Putin due to concerns that it is leading straight to disintegration of the country by attacking (nominally) Russian citizens from North Caucasus.
Not from my personal experience, but my friends living in Hungary (remember Putin-leaning Orban?) and Scandinavian countries (remember Breivik?) are saying that intra-country social tensions are on the rise there too. The "migrant crisis" that is affecting the Europe at large is only exacerbating this.
Could you provide a bit more context? I'm interested, but I cannot find a reference of Microsoft ever providing Win32 implementation for Unix. Did you maybe mean SFU (which would be the other way around)?
Not sure. They are often configured with additional software (e.g. https://steelseries.com/engine), but I did not need any of that just to use such keyboards on Windows. However, since Windows installs USB drivers automatically when you plug the device (either from device partition or downloading from the net), I cannot 100% tell whether a special keyboard driver was needed or not. I guess I could check in Hardware Manager but I'm too lazy to boot that machine right now :)
#3 (X server) is not so guaranteed these days. On an unrelated note - systemd is actually a positive development in that context (of standardization Linux ecosystem).
Yes. Pretty much no existing API would be applicable since the abstraction jumped down several levels - like going from Java to C. You are now allocating and freeing memory buffers on the hardware, filling them out with the complete pipeline state information and passing to GPU to execute as is. I guess one could bolt this onto existing OpenGL API (NVidia tries to do that with GL_NV_command_list), but a) it is still higher level and b) interaction with the rest of GL remains problematic implementation-wise. Naturally a question arises: if that part of API is not interoperable with the rest, why not just separate the two?
The sources are still under NDA, but this was information is public thanks to AMA with LunarG. You can read it here: http://www.phoronix.com/scan.p...
That is very true. Software may be written against "standards", but it is tested and optimized against other software. Linux is not a binary stable platform, and you can have two users who claim to run Linux but share almost nothing except the kernel and possibly libc. How can a big software house test and optimize the game? The test matrix would be unreasonable! In order to ship software for Linux, one has to either limit support to particular distribution and drivers, or to waive all guarantees.
Curiously enough, gaming keyboards can have problems on Linux: https://www.reddit.com/r/linux... - I experienced it myself. I guess it's because of extra functionality (programmability, color lights etc)?
He does forbid redistribution of the said binary drivers together with the kernel, so you cannot have them "out of the box" - user has to be the one making the "mix" of proprietary and non-proprietary code. And Stallman does put limitations on the developers - their philosophy essentially fights the contractual freedom between them and their users. Gladly, it is about to die finally, most recent and influential projects (clang/LLVM, docker, nginx) shun GPL.
You seem to contradict yourself. If you're fine with proprietary software (I am as well), then why are you against "trusted path" in the kernel - in what way proprietary kernel is different from a proprietary user application? Are you going to access their content not on their, but on your terms? If not, then why does the existence of the said path matter to you? Just install untrusted Linux kernel and forfeit your ability to access paid content.
Vulkan is not close to OpenGL at all, the design API is completely different. OpenGL has few thousands APIs, some of them are obsolete, Vulkan has 100. "Hello triangle" program in OpenGL (depending on the version) is a few tens of lines, but about 600 for Vulkan.
No, it will have 1.3 men per one woman. Roughly one man and one Javascript programmer per each woman.
No sources though.
No, I'm saying it performs as well as C++ in most cases. Virtual method handling is one example as to why, the JIT has a better view at execution time as to what can and can't be inlined, so it can inline much more than a statically compiled C++ program possibly can.
You realize that JIT is inherently limited to a tiny bit of program which it compiles? JVM cannot spend neither time nor RAM building a whole program tree and making global optimizations like compilers can. And by the way, if you think that compilers are limited to static analysis only - there's also profile-guided optimization.
Well that's precisely the problem you face if you don't have an explosion of optimised binaries, unless you want to accept that the JVM is going to optimise more efficiently. It's not just about compiling for different architectures, it's about the JIT automatically being able to optimise to take advantage of extensions, and other hardware that may be present too. It can optimise dependent on amount of RAM, cache sizes etc. - something that just isn't known when you compile a plain old generic C++ binary for, say, the generic x86 platform.
But there are a number of other things it can do better too - better loop vectorisation (as a result of better inlining of virtual functions) and more efficient heap allocations for example.
In theory, it could do that. But if you do a reality check, you'll find out that JVMs right now are pretty mediocre compilers that lack even basic optimizations. Again, everything that JVM does, can be done by a compiler, but not vice versa. Compilers have nearly unlimited time and can spend gobs of RAM analyzing the program. They can use profile-guided optimization, allowing you to gather stats from a compiled program and then recompile it to better account for runtime behavior - if needed.
Oh, and while we're at it, fine-tuning assembly with specific CPU in mind does not matter these days except for SIMD ops. Waiting for memory accesses dominates CPU time - and here Java is at inherent disadvantage because you cannot really control memory layout of your data.
"Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance."
This is nonsense. It depends entirely on the application. A heavy load web server for example may not really be I/O bound in the slightest depending on the size and what it does. Bulldozer is designed for optimisation of performance per watt, you're again confusing cause and effect as to why some things are the way they are.
Before you call this nonsense, go read some analysis and check benchmarks.
"That's not a problem of Java, though, but all managed languages - .NET also sucks."
Really, the problem is simply that you don't understand managed languages. Your understanding of the optimisations performed by JIT compilers is clearly woefully inadequate to being making this sort of comment. Your comments on server applications just don't even make sense for the most part to the point I'm not even sure you have the slightest grasp of what sort of things servers commonly serve.
"Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)"
This is just further nonsense. There was a Microsoft research project to try and build such a thing, and they did, and open sourced it. I don't know what you mean by "Now they are going native :)", they've always been native with
You are very optimistic. Right now even C++ compilers (which, believe me, are very much performance-oriented and rather are not memory-constrained) have problems with producing a good vectorized code, but thanks God we have assembly intrinsics and use them a lot. For JVM, that is even harder for multiple reasons (and unfortunate - historical - choice of Java bytecode is one of them). Sure, there's a broad class of software where performance does not matter, but as I said again, that is a boring software I don't want to work on. Writing such software is better to be outsourced somewhere where people crave for money more than I do.
As for HFT, I don't think that using Java is a good decision. If you can optimize for certain (best in its class) hardware, why do you need to hop through all the extra abstraction layers of Java? Sure you probably can, but it's like artificially limiting yourself.
JIT is generic in a sense that each program (and even different parts of a single program) is different and you cannot base them all on a common framework. E.g. in C++ sometimes you have to abandon STL at all because you cannot allow dynamic memory allocation (and memory fragmentation it causes). I wouldn't say that "Java performs as well as C++", unless you are speaking about UI-heavy programs where bottleneck is user input - or, alternatively, C++ programs written by people who don't know how CPUs implement a virtual method call and why it's slower than a non-virtual one.
.NET also sucks. Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)
Yeah, with native languages you are bound to a specific architecture (and even variations of it, e.g. AVX, SSE), but is it better to be a jack of all trades and master of none? And also, there's no "explosion of binaries" anymore - unfortunately, the number of architectures available is continuously shrinking (kind of undermining that design goal of Java). "Boring" native software that is not performance-tuned may very well ship just a generic binary targeted at, say, all Pentium IV and higher CPUs.
Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance. That is also the reason why Java can be used server-side without much problems, too. However, once you bring it to desktop, where performance matters, it starts to suck immediately. That's not a problem of Java, though, but all managed languages -
Sure, when I'm forced to use Java (e.g. Android), I immediately use the JNI window to escape. I am not interested in "benefits" of Java, if it means that I need to waste even more time trying to profile the application. Is there any low-level Java profiler, by the way, which would tell where CPU is burning cycles in your code at? Down to the level of assembly - i.e. something like perf annotate.