Jne Management: Fill & Download for Free

CS-Cart JNE Shipping Method: Integrate JNE shipping with CS-Cart and calculate shipping rates in real time with this magnificent add-on. JNE is a popular shipping service in Indonesia. People trust JNE for their accurate and prompt delivery. The speed and reliability of services consistently make JNE higher credible among customers.FeaturesWell integrated with CS-Cart Multi-Vendor.Functionality to calculate real-time shipping rates.Supports below mentioned JNE Services:1. Trucking, Trucking (motorcycle 250 cc) , Trucking (motorcycle below 150 cc) , Trucking (motorcycle below 250 cc)2. Ongkos Kirim Ekonomis3. Yakin Esok Sampai, CTC Yakin Esok Sampai4. BOX 3kg , 5kg5. POPBOX6. PELICON7. Regular8. SPSEasy to configure and manage at admin end.The codes are open to being further customized easily.

The name “Expression Template” is a term coined by Todd Veldhuizen for a C++ technique that he and I invented in the early 1990s. Todd’s 1995 Dr. Dobb’s article made the technique popular.I’m going to illustrate it using a modern approach. The original approach was considerably more complex (among others, because we had no member templates back then).Suppose you have a simple Array class:#include <initializer_list> template<typename T, int N> struct Array {  Array() = default;  Array(Array const&) = default;  Array(Array&&) = default;  Array(std::initializer_list<T> list) {  int k = 0;  for (auto &e: list) {  this->elems[k++] = e;  }  }  ~Array() = default;  Array& operator=(Array const&) = default;  Array& operator=(Array&&) = default;  T& operator[](int k) { return this->elems[k]; }  T const& operator[](int k) const { return this->elems[k]; } private:  T elems[N]; }; (I’ve intentionally kept it minimal.)Suppose further that we’d like to perform arithmetic on such Arrays. E.g.:#include <iostream> Array<double, 100> x = { 1.0, 2.0, 3.0 },  y = { 4.0, 5.0, 6.0 }; int main() {  x[20] = 20.0;  y[20] = y[40] = 4.0;  Array<double, 100> r = x+2.0*y;  std::cout << r[2] << '\n'; } All right, that’s easy to do: We just introduce the right operator functions to perform the needed operations. For example:template<typename T, int N> auto operator+(Array<T, N> const &x,  Array<T, N> const &y)  -> Array<T, N> {  Array<T, N> result = {};  for (int k = 0; k<N; ++k) {  result[k] = x[k]+y[k];  }  return result; }  template<typename T, int N> auto operator*(T const &s,  Array<T, N> const &x)  -> Array<T, N> {  Array<T, N> result = {};  for (int k = 0; k<N; ++k) {  result[k] = s*x[k];  }  return result; } That works, but it is quite sub-optimal:Every operator invocation introduces a temporary.Every operator invocation performs a loop, but the computation could be done with a single loop: for (int k = 0; k<N; ++k) {  result[k] = x[k]+s*y[k];  } A potential solution to this are expression templates, which are templates that represent an expression in quasi-symbolic form, instead of representing the result of the expression. Let me show what it could look like for the array class above. Note that there are many variations on this theme — this is not the “one true way” of expression templates…First, I’ll introduce an additional parameter to my Array template:template<typename T, int N, typename Repr = T const*> struct Array; The Repr parameter will describe the underlying access representation of the array in a compact way. By default, the representation is just a pointer to the underlying storage (T const*). I can write a partial specialization for that case that looks a lot like my original Array template, but I also add members that implement copying from another representation, as well as a member to access the underlying access representation:#include <new> template<typename T, int N> struct Array<T, N, T const*> {  Array() = default;  Array(Array const&) = default;  Array(Array&&) = default;  // Copy from other representations:  template<typename Repr>  Array(Array<T, N, Repr> const &x) {  for (int k = 0; k<N; ++k) {  new(this->elems+k) T(x[k]);  }  }  Array(std::initializer_list<T> list) {  int k = 0;  for (auto &e: list) {  this->elems[k++] = e;  }  }  ~Array() = default;  Array& operator=(Array const&) = default;  Array& operator=(Array&&) = default;  // Copy from other representations:  template<typename Repr>  Array& operator=(Array<T, N, Repr> const &x) {  for (int k = 0; k<N; ++k) {  this->elems[k] = x[k];  }  return *this;  }  T& operator[](int k) { return this->elems[k]; }  T const& operator[](int k) const { return this->elems[k]; }  T const* representation() const { return this->elems; } private:  T elems[N]; }; For our first alternative representation, let’s create a class template that represents the sum of two array types:template<typename R1, typename R2> struct Sum {  Sum(R1 const &r1, R2 const &r2): r1(r1), r2(r2) {}  Sum(Sum const&) = default;  ~Sum() = default;  Sum& operator=(Sum const&) = delete;  auto operator[](int k) const  { return this->r1[k] + this->r2[k]; } private:  R1 r1;  R2 r2; }; Notice how this is a read-only array-like type that doesn’t actually store individual elements. Instead, when you give it an index value, it computes the corresponding sum on the fly from its embedded access representations. To be able to construct an Array from that representation, we define the generic case of Array (i.e., not the one with an actual underlying array, which we specialized above) as follows:template<typename T, int N, typename Repr = T const*> struct Array {  Array(Repr const &repr): repr(repr) {};  Array(Array const&) = default;  ~Array() = default;  auto operator[](int k) const { return this->repr[k]; }  Repr representation() const { return this->repr; } private:  Repr repr; }; That allows us to write code like this:#include <iostream> int main() {  using Arr = Array<int, 10>;  Arr x = { 1, 2, 3 };  Arr y = { 2, 3, 4 };  Arr r = Array<int, 10,  Sum<int const*, int const*>>(  Sum<int const*, int const*>(x, y));  std::cout << r[1] << '\n'; // Should print "5". } Notice how the initializer for r is an array that doesn’t store the elements of x+y, but instead it represents that sum, and whenever we call operator[] on that representation, the corresponding element is computed. Now, the initialization or r itself is performed by this constructor template defined earlier on:template<typename T, int N> struct Array<T, N, T const*> { [...]  // Copy from other representations:  template<typename Repr>  Array(Array<T, N, Repr> const &x) {  for (int k = 0; k<N; ++k) {  new(this->elems+k) T(x[k]);  }  } [...] }; That loops of x[k] and each expression x[k] computes the sum on the fly. At the end of the loop, the T[N] array (this->elems) will contain the sums. Of course, writing something like Array<int, 10, Sum<Arr, Arr>>(Sum<Arr, Arr>(x, y)) is not what we want, but we can write an operator+ that does it for us:template<typename T, int N, typename R1, typename R2> auto operator+(Array<T, N, R1> const &x,  Array<T, N, R2> const &y) {  using R = Sum<R1, R2>;  return Array<T, N, R>(R(x.representation(), y.representation())); } and with that our previous main() function can be simplified to:#include <iostream> int main() {  using Arr = Array<int, 10>;  Arr x = { 1, 2, 3 };  Arr y = { 2, 3, 4 };  Arr r = x+y;  std::cout << r[1] << '\n'; // Should print "5". } The code we wrote for the sum case can be duplicated for the product case:template<typename R1, typename R2> struct Prod {  Prod(R1 const &r1, R2 const &r2): r1(r1), r2(r2) {}  Prod(Prod const&) = default;  ~Prod() = default;  Prod& operator=(Prod const&) = delete;  auto operator[](int k) const  { return this->r1[k] * this->r2[k]; } private:  R1 r1;  R2 r2; };  template<typename T, int N, typename R1, typename R2> auto operator*(Array<T, N, R1> const &x,  Array<T, N, R2> const &y) {  using R = Prod<R1, R2>;  return Array<T, N, R>(R(x.representation(), y.representation())); } (All I had to do was rename Sum to Prod and change + to *.) With that, I can now not only handle array multiplications, but also combinations of multiplications and additions:#include <iostream> int main() {  using Arr = Array<int, 10>;  Arr x = { 1, 2, 3 };  Arr y = { 2, 3, 4 };  Arr r = x+x*y;  std::cout << r[1] << '\n'; // Should print "8". } Hopefully, that illustrates why Array can be called an expression template: It’s a template that represents an expression in its template argument structure.Revisiting the Original ExampleLet’s add one more representation to handle scalar operations:template<typename T> struct Scalar {  Scalar(T const &s): s(s) {}  Scalar(Scalar const&) = default;  ~Scalar() = default;  Scalar& operator=(Scalar const&) = delete;  T const& operator[](int) const { return s; } private:  T const &s; }; I.e., this is a representation that always returns the value passed to its constructor. Let’s also add an operator* that makes use of it (you could add many other variants):template<typename T, int N, typename R2> auto operator*(T const &x,  Array<T, N, R2> const &y) {  using R = Prod<Scalar<T>, R2>;  return Array<T, N, R>(R(Scalar<T>(x), y.representation())); } With that, we can execute our original main() function again:#include <iostream> Array<double, 100> x = { 1.0, 2.0, 3.0 },  y = { 4.0, 5.0, 6.0 }; int main() {  x[20] = 20.0;  y[20] = y[40] = 4.0;  Array<double, 100> r = x+2.0*y;  std::cout << r[2] << '\n'; } The same result is produced. But the generated code is very different. For this last version, the inner loop of that code (with high levels of optimization) is:.L2:  movapd xmm0, XMMWORD PTR y[rax]  addpd xmm0, xmm0  addpd xmm0, XMMWORD PTR x[rax]  movaps XMMWORD PTR [rsp+16+rax], xmm0  add rax, 16  cmp rax, 800  jne .L2 I.e., a single tight loop does not involve any temporary arrays.Compare that to the code for the original version:.L2:  movapd xmm0, XMMWORD PTR y[rax]  addpd xmm0, xmm0  movaps XMMWORD PTR [rbp+0+rax], xmm0  add rax, 16  cmp rax, 800  jne .L2  mov rdx, rsp  mov ecx, 100  xor eax, eax  mov rdi, rdx  rep stosq .L3:  movapd xmm0, XMMWORD PTR x[rax]  addpd xmm0, XMMWORD PTR [rbp+0+rax]  movaps XMMWORD PTR [rdx+rax], xmm0  add rax, 16  cmp rax, 800  jne .L3 which is two loops plus intermediate storage (pointed to by rbp) to store the result of the first loop.BewareFor expression templates to work correctly, it’s important that in the end, the access representation be copied to a stored representation. In our example, that’s done by the initialization of the variable r, which calls a constructor template that stores the actual results:Array<double, 100> r = x+2.0*y; Note in particular, that the following would not work:auto r = x+2.0*y; because now r would be of a type Array<double, 100, Sum<…>> that refers to storage that might not remain alive. Joel Falcou tried to convince the committee to develop a solution for that issue (by being able to override how auto type deduction works), but that didn’t gain enough traction, unfortunately.Other ApplicationsExpression templates aren’t limited to array operations. Many other applications exist. For example, before C++11 introduced lambda expressions, Boost.Lambda implemented a different kind of lambda expressions in C++03 using expression templates.EpilogueI developed a version of this technique some time in 1994. At the time there were no member templates, which made this critical part:template<typename T, int N> struct Array<T, N, T const*> { [...]  // Copy from other representations:  template<typename Repr>  Array(Array<T, N, Repr> const &x) {  for (int k = 0; k<N; ++k) {  new(this->elems+k) T(x[k]);  }  } [...] }; a problem. Instead I used a more complex scheme involving implicit conversion functions and virtual function dispatch. That introduced a single virtual call at the top of initializations and assignments, but for large-enough arrays it was worth it.I posted the to the technique to comp.lang.c++ with relatively little reaction. A while later, someone mentioned in that same group that the standardization committee was working on reworking the standard library to be templatized, and that the standard numeric array types floatarray, doublearray, and intarray would instead become valarray. I had never even heard of the former, but I asked if they were taking into account my technique. The committee’s representative of Cray (the legendary supercomputer company) replied that he didn’t know, but he was very kind to send me (by USPS!) a document describing the proposed interface. (I was a student at the time and I’m very sorry I don’t recall the representative’s name, because I owe him big.) By then member function templates had been added to the language and I wrote a proposal that slightly modified the interface of std::valarray to enable the technique described above. I somehow managed to get the committee’s attention for that proposal (Nathan Myers was another person that helped me a lot back then) and that’s how I was invited to participate in committee discussions, and soon thereafter attend my first meeting. That in turn got me my first career job.

Python is slower than C because it is an interpreted language.This amplifies the number of actual CPU instructions required in order to perform a given statement.In a Python program, you may add the value 1 to a variable, or compare the value of a variable to see whether it is less than a certain value, greater than a certain value, or precisely equal to a certain value, such as in:x = 0 while x < 50 # compare less than  x += 1 # increment  print(x)  if x == 25 # compare equal to  print(x, 'Half done')  elif x == 50 # compare equal to  print(x, 'Done') In assembly language, you can similarly do this loop:mov $r1, 0 ; x = 0 while_label:  cmp $r1, 50 ; while x < 50  jge greater_or_equal  inc $r1 ; x += 1  ; print x  ...  cmp $r1, 25 ; if x == 25  jne skip_25_print  ; print x  ...  ; print 'Halfway'  ... skip_25_print:  cmp $r1, 25 ; if x == 25  jne skip_25_print   ; print x  ...  ; print 'Done'  ...  jmp while_label greater_or_equal: ; loop termination The difference is that the python code will be interpreted, instead of directly by the CPU.This makes all the difference in the world, with regard to performance.Python code almost always runs in a virtual machine.(I say “almost” because it doesn’t have to, but except under really limited circumstances — no, actually, it really has to)Another name for a virtual machine is a “bytecode interpreter”.Interpreted code is always slower than direct machine code, because it takes a lot more instructions in order to implement an interpreted instruction than to implement an actual machine instruction.Example time! Yay!For example, let’s take the x += 1. In an Intel CPU, an increment of a register is a single op, has a latency of 1, and a reciprocal throughput value of 1/3.In other words: it’s about the fastest CPU instruction it’s possible to have on an Intel processor.How is this x += 1 accomplished in Python?In order to know this, you have to know how Python works internally.Internally, Python is composed of a tokenizer, a lexical analyzer, a bytecode generator, and a bytecode interpreter:TokenizerThis converts input Python code (ASCII text files) into a token streamLexical AnalyzerThis is the part of Python that cares all about those meaningful spaces and indentation. This is where syntax checking happens.Bytecode GeneratorThis is the Part of Python that does the optimizations, if any; because Python is not actually a compiled language, the range of optimizations is limited, compared to the optimizations which you might get out of a C compiler.Bytecode InterpreterThis is the part of Python that operates on the bytecode stream, and maintains the state of the Python virtual machine.Bytecode, once generated is typically cached in memory.This provides a speed improvement, because it means you can avoid repeating the tokenization, lexical analysis, and bytecode generation steps for code that Python has already seen.So when we iterate our while loop, we can skip the tokenization an lexical analysis and bytecode generation steps, and just hand the bytecode off to the bytecode interpreter, again and again.This is fast, right?Actually, no.While it is faster to use cached bytecode, this is not the same thing as operating as quickly as machine code.A virtual machine is not the actual CPU on which the code is running.A short intro to virtual machines.One of the earliest used virtual machines was called the UCSD p-System, from the University of California, San Diego. It was around in 1972.Shortly afterward, Microsoft released their version of BASIC (based on Dartmouth College BASIC from 1964), which tokenized the BASIC code in much the same way that Python tokenizes today. BASIC is stored in memory the same way Python bytecode is stored in memory following tokenization, although BASIC delays some of the lexical analysis stage until runtime. In its virtual machine: the BASIC interpreter.Other than not having line numbers for each line, and using spacing as a statement block management technique, instead of not having one and using GOTO instead, Python largely resembles the BASIC interpreters we had 40 years ago.“Compiling” vs. compiling.Compiled UCSD Pascal was not compiled to assembly language, like in other compiled languages at the time.Instead, it was compiled into p-Code.Apple, where I worked, had the only non-revokable license to the UCSD p-Code system. This was a licensing mistake which UCSD did not later repeat.Most of ProDOS on the Apple II was written in Pascal, and almost all code to do QuickDraw in the early Macintoshes was written in Pascal.So when you think of a “compiled Pascal program”, at the time, you were talking about p-Code. Or “bytecode”, if you are a Java or Python fan, and want to pretend you invented something new.Python also has the concept of “compiled Python”; this is Python code that has gone through the tokenizer, the lexical analyzer, and the bytecode generator, to get what you’d have in memory as cached bytecode, which was ready to feed to the bytecode interpreter (AKA the Python Virtual Machine).Whenever you see a file that ends in .py, this is an ASCII text file that contains Python source code.When you see a file that ends in .pyc, this is “PYthon, Compiled”.The resulting code still runs in a virtual machine.Native code.A program isn’t really native code until it’s been compiled, and a program hasn’t actually been compiled to native code until it’s compiled to the native binary CPU instructions on the platform it targets.This normally involves generating assembly code instead of bytecode, passing the assembly code to an assembler, and the assembler spitting out platform specific object files.After that, the program is still not ready to run, until it’s linked to a platform runtime. A runtime sets up the environment in which the code expects to run, and can provide a number of runtime services such as dynamic object loading. Compiled C has a runtime. Compiled C++ has a runtime.Mostly, these runtimes just set up the environment, and jump to your code. In other words: they have a one-time cost.The process of associating a generated object file with a runtime (and any support libraries) to generate a standalone executable is called “linking”.Virtual machines do not do linking; the closest they get is loading additional modules into the virtual machine. While these modules can themselves be compiled — in fact, this is the basis of some python modules to speed operations in Python up, and it’s the basis of the JNI (Java Native Interface) — the modules are generally written in a compiled language, such a C or C++, or if they are something like a math library, they might even be written in assembly.Something isn’t compiled, then, unless it becomes a native binary for the platform it’s running on.Why running in a virtual machine makes you slow.Running in a virtual machine requires interpreting a bytestream, and then running native code on behalf of the bytestream.So let’s go back to our example:x += 1 We’re just adding one, right?What actually happens under the covers to implement this in Python, even after it has been converted to bytecode, is (according to my profiler) 378 machine instructions executed by the Python virtual machine.Doing the same thing in C:x++ costs 1 machine instruction, because C compiles that down to assembly language, and that assembly language looks like this:inc $r1 So you end up doing a ton of work to accomplish something, when just a little work would do the job.Why Python itself is intrinsically slow on top of that.CPython is the C implementation of Python, which is the default Python implementation utilized practically everywhere.CPython interpreters can not take substantial advantage of multithreading.Why is this?CPython has what’s called a global interpreter lock. This is utilized by the interpreter to ensure that there’s only one thread executing Python bytecode at a time. If a thread calls into an external module, or it blocks, then another Python thread is able to run.You may have 5,000 cores in your machine, but you’re only going to be running Python on one of them at a time.External modules written in something other than Python can provide substantial performance improvements, because they can use this multithreading — this is called Apartment Model Threading, and it was “invented” by Microsoft in 1996 or so as part of their ViPER framework, which was their way of adding multithreading support in NT 3.51.Once the CPython thread goes into the “Apartment” (module), it drops the global interpreter lock, and can use multiple threads in the C/C++/other code all it wants — until its time for it to come back out of the apartment.Like a human who enters their own apartment: it can take it’s clothes (the lock) off, and dance around naked, if it wants.Making Python faster.Java has a technology called JIT, or Just In Time compilation. What a JIT does is takes the bytecode, and converts it into native assembly language for the platform it’s running on.Another name for this technology is dynamic compilation.What a JIT does is do the missing pieces between the bytecode and the assembly code; it converts the bytecode into assembly code, and then caches that for re-execution.A JIT can be nearly as fast a a natively compiled program, but has runtime overhead for the conversion, every time you run it. It’s an incremental overhead, that results in the code not being as fast as it could be.To combat this, you probably want to compile Java to native code; there’s a commercial product, called Excelsior JET, that you can buy to do this. There’s also the old GCJ (GNU Compiler for Java), which has been removed. You can find it in archives, but the version will not support most recent versions of Java. It was discontinued after the Oracle license change, on GNU philosophical grounds.But back to Python!Are there JITs for Python?Absolutely! There’s PyPy, there’s Numba, and Microsoft has Pyjion (the link is to GitHub sources). There are a few others, which tend to be less well known and therefore less utilized or maintained.The Numba project can even statically compile Python — or a subset of RPython, which is itself a subset of Python — to native code.Unfortunately, when you use Python, you’re probably not using any of these, and you’re probably using the standard Python implementation, CPython instead.So the bottom line?Python is slower because it’s an interpreted language.