Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Not just a GUI toolkit (Score 1) 79 79

Thanks. That's useful feedback. Obviously, this topic is complicated with several factors to muddy the waters.

> 90% of your time is usually spent in 5% of your code, so it's really the ability to optimize easily when you need to without resorting to convoluted tricks and hooks into other languages.

Interestingly, the Python/glue-language philosophy is just the opposite, for exactly the same reasons. Since it is just the 5% of the code that needs optimization, it says: why not write that in C/C++ and the rest in something easier?

These days, you can get GPU power outside C++. For instance, Theano brings GPU math to Python. I don't have experience with comparing the performance differences between say PyCUDA/jcuda vs straight C/C++ CUDA. The net difference may not be 100x, but C/C++ programmers will certainly tend to do deeper optimizations.

Comment: Re:Not just a GUI toolkit (Score 1) 79 79

You can bundle JRE with your jar/exe, if you don't want the user to separately download a runtime. Many Eclipse Rich Client Apps do this. I have done it myself. As someone who used Delphi/C++ Builder and is very used to static linking to a 1-2 MB distributables with no further dependencies, I am not that happy with Qt dll sizes for client apps. Its certainly better than Java, but is quite bloated for native code. All other native solutions are much more compact (Qt of course wins by feature set). Static linking with Qt is possible, but not recommended.

I was looking for info on Qt server apps. On the server, runtimes aren't a concern. Startup times are also not important for HPC apps with long execution times. What is important is how things go after the startup. JVM does need to set more memory aside for the GC. Micro benchmarks typically put C++ at 1.5-2.0x faster than Java. I wondered how real world performance differs.

Comment: Re:Not just a GUI toolkit (Score 1) 79 79

I understand all that. I used Qt myself, but just for simple GUIs. I was just wondering what his real world numbers were. I was not challenging him for his choice. I know the micro-benchmarks between native and VM code. I was curious of how things fared in his larger apps. I normally do JVM for long-running server code, but C++11 and onwards is increasingly attractive, although JVM is still a bit simpler to work with, on the whole. I am exclusively interested in his (or anyone else's) real world experiences on the performance differences between JVM HPC code (server VM config) and C++ server code that uses Qt as the main library.

Comment: Re:Universal App APIs are too limited (Score 1) 186 186

> but I suspect it would be a giant mash up of "if mobile do X else do Y," which isn't really "universal" in my mind

Well, it would link against different runtime libs, either static or dynamic, with the same interface - it would not bundle the binaries of all platforms (closer to Apple's use of the term Universal). Universal API is just cross-platform API, like Qt or anything similar.... except with support for a lot more disparate architectures... like FireMonkey. Or it is just better Java. Java, Qt (QtQuick is much closer), wxWidgets, LCL... all support multiple platforms. But they never really grew beyond the traditional x86/64 desktop/server (Java Mobile and Android Java were not seamless). This would just add mobile platforms to the mix with near complete API.

> They used to provide a library (skypekit) to do that but they decided to cut it off

Sure. I am not arguing about their business choices, just the technical ones. It is fairly easy to port the protocol code across different architectures. I used to use SIP, in preference to Skype. It worked well enough. So the problems are not technical, if they try.

Comment: Re:Universal App APIs are too limited (Score 1) 186 186

You are not arguing against the Universal API. You are arguing against mobile specific UIs on the desktop.

Skype UI isn't that complicated to replicate. In mobile development, it is typical to maintain multiple UIs. That's not considered the main challenge. The original Skype was developed in Delphi. AFAIK, it still is. Delphi today supports multi-platform apps and UIs (with platform specific behaviors), with a UI designer tailor-made for that role, although it uses its own FireMonkey framework (not sure about the extent to which it supports Universal API) which supports both Desktop and Mobile apps. Skype UI was written on VCL. It is supposed to be fairly easy to port to FireMonkey. Modern frameworks, especially the modern mobile frameworks, make it quite easy to scale to a wide range of resolutions and devices, as long as devs keep that in mind. The Skype dev team might have gone with MS API since FireMonkey was perhaps not mature enough then.

I recall that the protocol code was written in C++, which I assume is portable C++, since Skype is already available on all platforms and I doubt that they have multiple code bases for protocol code. I am not sure how good the native code interop is in Universal API.

Comment: Re:Averages (Score 1) 109 109

> Makes me wonder how I managed a 16 hour surgery the other day without ever getting bored or distracted (kind of hard to do when the patient is trying so hard to die on your table).

Clearly, without your patient's help in keeping you focused, you would have gotten distracted and wandered away from the OP after seeing a squirrel in the window :-).

Seriously, you know enough Statistics to know that your circumstance does not make a case against the study in any way, even if it was a comparable task. Your surgery task is a compound, concurrently distributed team task. It is not anything like the candidate tasks under consideration in this study. You don't need to have special powers of concentration to not be distracted in a surgery (at least no more than passing boards).

Comment: Re:Why not Python? (Score 1) 94 94

I mean the full Python stack (IPython notebook + Spyder with IPython, PyLab, Pandas, statsmodels).

For almost everything in stats, I prefer the RStudio experience. The flow feels much better, even though my Python is much better than my R. Machine Learning is one stats topic though, where I still prefer Python - I just like Scikit-learn.

If I was doing linear algebra directly, I would have preferred the Python stack with NumPy. PyLab stack is more for Matlab users than R users. On the stats side, Pandas and statsmodels are still not yet an R replacement for me. They are a great start though and seem to have gotten everything right so far.

Comment: Re:Why not Python? (Score 1) 94 94

I use both R and Python. R itself is actually quite nice and more efficient for interactive use, once you get used to it. For interactive exploration with statistics, I actually prefer it to Python (and I have been using Python for ~15 years). Lots of helper functions. Everything uses the DataFrame datastructure. Good, concise and consistent documentation.

Unless you are a R library dev, for most users, its best to see R as a shell for statistics, rather than a programming language. So its language horribleness does not matter much.

I use Python to process data and R to explore it. Once I settle on something, if I need to put it into a larger pipeline, I either find an implementation in Python or link R to Python via rpy2.

> A python statistics library with some funky C linkage to the R library would take over in milliseconds

That's what rpy2 is.

Comment: Re: What has Rust been used for? (Score 1) 181 181

> there's nothing else out there that is even attempting to solve the same problems.

You mean move semantics? That would be the main innovation of Rust. C++ also has them now. Perhaps Rust has them better, but it would be inaccurate to say that no one is even attempting to solve these problems.

Comment: Re:Hasn't Google been doing that for a while now? (Score 1) 109 109

I do indeed prefer mplayer over VLC since the CPU utilization is better. However, my mplayer does not do VP9. VLC nightly was suggested and it worked. But I would like to switch back to mplayer as soon as I can.

I did update my ffmpeg. The one that comes with Trusty did not work with youtube-dl.