在开发交互式算法 更不能用java和c++混合 而应该用单一语言 那就是c++ 这样设置 断点差错也方便 比如用 jna或者jni 调用c++库 出现的问题: JNA does not support mapping of c++ classes, so if you're using c++ library you will need a jni wrapper If you need a lot of memory copying. For example, you call one method which returns you a large byte buffer, you change something in it, then you need to call another method which uses this byte buffer. This would require you to copy this buffer from c to java, then copy it back from java to c. In this case jni will win in performance because you can keep and modify this buffer in c, without copying. 把一个3D图像从 c++ 复制到 java 修改 然后更改 复制到c++ 修改 不仅仅耗时 编程 序的人更要疯了 就跟上课在中文和英文互相切换 估计只有新加坡人能受得了
【在 N******K 的大作中提到】 : 在开发交互式算法 更不能用java和c++混合 而应该用单一语言 那就是c++ 这样设置 : 断点差错也方便 : 比如用 jna或者jni 调用c++库 出现的问题: : JNA does not support mapping of c++ classes, so if you're using c++ library : you will need a jni wrapper : If you need a lot of memory copying. For example, you call one method which : returns you a large byte buffer, you change something in it, then you need : to call another method which uses this byte buffer. This would require you : to copy this buffer from c to java, then copy it back from java to c. In : this case jni will win in performance because you can keep and modify this
w*r
20 楼
简单的说, 按过10个指头的, 不用去, 只按过2个, 4个或者0个的, 要去
【在 T**********t 的大作中提到】 : 请问lz,现在免面签还要去打印指纹吗?
c*t
21 楼
哈哈,dd是不是就木人理了?
【在 q*****5 的大作中提到】 : MM么??
g*g
22 楼
你小就不能歇歇,我又没说过java啥都适合,最典型的例子就是操作系统。 自己弄个风车还卯上了。 这年头竞争的不是语言,是生态系统。Objective C是这几年上升最快的语言,是因为 有多维数组,还是因为有 linq? IT业变化快,5年前mobile前端还是 win mobile and symbian的天下,首选语言是C++ ,现在又如何?
a*2
23 楼
我也想知道楼主妈妈多次入境在美国呆了多久,回国又呆了多久去签证的。 多谢!!
c*t
24 楼
原来music版功能这么强大...XD
【在 t*******r 的大作中提到】 : 先奔个歌,然后根据 available 的程度让 frada 包装一下去鹊桥版推广。 : // 我 run 走 …………
【在 N******K 的大作中提到】 : 在开发交互式算法 更不能用java和c++混合 而应该用单一语言 那就是c++ 这样设置 : 断点差错也方便 : 比如用 jna或者jni 调用c++库 出现的问题: : JNA does not support mapping of c++ classes, so if you're using c++ library : you will need a jni wrapper : If you need a lot of memory copying. For example, you call one method which : returns you a large byte buffer, you change something in it, then you need : to call another method which uses this byte buffer. This would require you : to copy this buffer from c to java, then copy it back from java to c. In : this case jni will win in performance because you can keep and modify this
Hybrid structure is the way to go. The power of C/C++ is on the lower level, including image processing. However, C/C++ is too rigid and too expensive. In most companies, there are differences between application developers and algorithm developers. The product of the latter is libraries only. They even don't have any say on threading models. Except some qt freaks, there is limited areas where C/C++ is needed to do the framework. Both java and .net are way better on this regard. Python binding, JNI, or managed C++ are decent glues. This has been the trend in industry for several years, however, html5 might change this trend. As a trade-off, C/C++ developers usually have better job securities and enjoy higher pays. Very few people dare to change bottom layer dramatically . Yes, the job pool is shrinking, so is the candidates pool.
【在 S**********n 的大作中提到】 : Hybrid structure is the way to go. : The power of C/C++ is on the lower level, including image processing. : However, C/C++ is too rigid and too expensive. In most companies, there are : differences between application developers and algorithm developers. The : product of the latter is libraries only. They even don't have any say on : threading models. : Except some qt freaks, there is limited areas where C/C++ is needed to do : the framework. Both java and .net are way better on this regard. Python : binding, JNI, or managed C++ are decent glues. This has been the trend in : industry for several years, however, html5 might change this trend.
Keep image data in native buffer all the time. .net/java manages meta data. Only commands and pointers are passing to/from these two layers, probably through JNI or C++/CLI. Threading could happen in java layer or native layer. Usually, architects don't believe C++ developer's knowledge on threading. As I said, this is standard practice in industry. Dealing with data on GPU might be a little bit different. For image data, even C++ containers are presumed to be bad. C, good old C, rocks. Copying large amount of raw datas between layers are assumed to be bad practcie with few exceptions. On this regards, managed C++ is better than JNI.
"They even don't have any say on threading models. " 此句本人不敢苟同。详情以後再谈。
are
【在 S**********n 的大作中提到】 : Hybrid structure is the way to go. : The power of C/C++ is on the lower level, including image processing. : However, C/C++ is too rigid and too expensive. In most companies, there are : differences between application developers and algorithm developers. The : product of the latter is libraries only. They even don't have any say on : threading models. : Except some qt freaks, there is limited areas where C/C++ is needed to do : the framework. Both java and .net are way better on this regard. Python : binding, JNI, or managed C++ are decent glues. This has been the trend in : industry for several years, however, html5 might change this trend.
This is arugable. Usually, threading model and scalability needs to be considered at framework level of the whole application, if performance of algorithm is predicatable. Agreed, some kind of threading is better done on algorithm level (and can only be done there). However, many companies might make do just put threading into java and .net level. Also many C/C++ algorithm engineers do not have the ability to write good concurrency codes. One of the dillemsa for C++ developer is that if you were young, people don' t trust you. If you were old, your knolwedge is ouptdated.
【在 k**********g 的大作中提到】 : "They even don't have any say on threading models. " : 此句本人不敢苟同。详情以後再谈。 : : are
N*K
59 楼
没人这么胡折腾 只是给版友提个醒 别被跳大神的忽悠了 java在这个领域根本行不通
data. probably with ,
【在 S**********n 的大作中提到】 : : This is arugable. Usually, threading model and scalability needs to be : considered at framework level of the whole application, if performance of : algorithm is predicatable. : Agreed, some kind of threading is better done on algorithm level (and can : only be done there). However, many companies might make do just put : threading into java and .net level. Also many C/C++ algorithm engineers do : not have the ability to write good concurrency codes. : One of the dillemsa for C++ developer is that if you were young, people don' : t trust you. If you were old, your knolwedge is ouptdated.
【在 S**********n 的大作中提到】 : : This is standard practice in industry!
S*n
62 楼
I think I see your point. Still, industry is different from academia. Eventually, "use cases" and "applications" would take hold most of the effots. It is sad but true. Partition codes into layers is the first step to solve the complicated problems. Even for complicated applications, real road block still could be isolated. Let C/C++ people eat the bone (more money) and let java people eat the meat. Algorithm complexity is different from I/O bound problems. From my limited expereince, hybrid is the mainstream of the industry. This model could be even extended (modified) to GPU and cell processor level.
【在 S**********n 的大作中提到】 : : I think I see your point. Still, industry is different from academia. : Eventually, "use cases" and "applications" would take hold most of the : effots. It is sad but true. : Partition codes into layers is the first step to solve the complicated : problems. Even for complicated applications, real road block still could be : isolated. Let C/C++ people eat the bone (more money) and let java people : eat the meat. Algorithm complexity is different from I/O bound problems. : From my limited expereince, hybrid is the mainstream of the industry. This : model could be even extended (modified) to GPU and cell processor level.
Don't pass in a Java callback or predicate. Instead, write the function in functional style - construct an expression tree using Java objects. Then the Java - C layer can parse and convert this expression tree into native C function structure. It won't be a single function, but at least it can be executed in pure C code.
Agreed. If parallelism only occurs at the framework level, then the latency of processing cannot be reduced, and the CPU will be under-utilized (if there are not enough requests at the framework level). Certain image processing operations are non-parallelizable - when considered alone. Examples are image decoding and encoding. However, that doesn't mean other image operations had to wait until these operations finish - other image operations can use partial results, and can do so from a different thread. Users of Intel IPP will remember that IPP is exactly not designed for such incremental usage. For this reason, it is in the process of being completely redesigned to be utilized in an incremental (and concurrently-driven) manner. A carefully-designed parallelized image processing framework would have very low overhead (CPU cycles overhead divided by CPU cycles spent on doing useful work), in the range of 0.1 percent. This is possible by choosing suitable chunk factors (granularity of work). Exploiting parallelism at the algorithm level requires both task- decomposition and data-decomposition. It will certainly increase development cost. The number of lines code in a parallelized implementation could easily exceed 10 times that of a sequential implementation. The software development effort will increase by more than 10 times. Intel TBB and Microsoft PPL (also known as ConcRT (Concurrency Runtime) or AAL (Asynchronous Agents Library)) provides an ABI-compatible way of developing parallel applications that can adapt to a reasonably large number of CPU cores. PPL is backward-compatible on Windows XP and Server 2003. Microsoft PPL provides task-oriented features not found on Intel TBB. OpenCV already uses Microsoft PPL on Windows for certain image operations, such as image resizing and rotation (known as "remaps"). concurrency codes. A robust understanding of reference counting is a basic requirement. For this reason, it is recommended that C/C++ engineers for Windows platform spend at least 3 years working with COM-based frameworks, and have thorough understanding and practice with Design Patterns using COM, before trying to apply to one of the core technology teams. Other must-knows are: atomic operations, CPU cache behavior, SIMD (SSE2, etc ), bit manipulation, message dispatch queues. If you meet deadlines, people will trust you. If you don't meet deadlines, people won't trust you. (unfortunately I'm in the latter category ...)
【在 S**********n 的大作中提到】 : : I think I see your point. Still, industry is different from academia. : Eventually, "use cases" and "applications" would take hold most of the : effots. It is sad but true. : Partition codes into layers is the first step to solve the complicated : problems. Even for complicated applications, real road block still could be : isolated. Let C/C++ people eat the bone (more money) and let java people : eat the meat. Algorithm complexity is different from I/O bound problems. : From my limited expereince, hybrid is the mainstream of the industry. This : model could be even extended (modified) to GPU and cell processor level.