search for: paraleliz

Buenos días, alguien sabe si hay alguna manera de implementar una máquina de soporte vectorial (svm) con R-hadoop?? Mi interés es hacer procesamiento big data con svm. Se que en R, existen los paquetes {RtextTools} y {e1071} que permiten hacer svm. Pero no estoy segura de que el algoritmo sea paralelizable, es decir, que pueda correr en paralelo a través de la plataforma R-hadoop. Muchas gracias Un saludo MªLuz Morales [[alternative HTML version deleted]]

...ficiente porque mi > objetivo es trabajar con big data > > El 10 de diciembre de 2015, 13:23, Carlos Ortega <cof en qualityexcellence.es > > escribió: > >> Hola, >> >> ¿Y no te valdría el ejecutar tu código con "caret" y activar la opción de >> paralelizar?. >> El escenario "caret + paralelización + svm" funciona sin problemas. >> >> Adjunto una captura de pantalla del libro de "Kuhn" (Applied Predictive >> Modeling) con los tiempos de ejecución que se obtienen al ejecutar >> diferentes modelos (SVM...

...n sabe si hay alguna manera de implementar una máquina de soporte > vectorial (svm) con R-hadoop?? > > Mi interés es hacer procesamiento big data con svm. Se que en R, existen > los paquetes {RtextTools} y {e1071} que permiten hacer svm. Pero no estoy > segura de que el algoritmo sea paralelizable, es decir, que pueda correr en > paralelo a través de la plataforma R-hadoop. > > Muchas gracias > Un saludo > MªLuz Morales > > [[alternative HTML version deleted]] > > _______________________________________________ > R-help-es mailing list > R-help-es...

...edes usar R y cualquier paquete que incluya SVM. Si esto no te vale y quieres hacerlo sobre el total de los datos (En mi opinión esto no garantiza que vayas a conseguir mejores resultados..). Por lo que estuve investigando (si me equivoco que alguien me corrija!) los SVM no son de lo mejorcito para paralelizar, Spark como comentó Carlos tiene implementado SVM lineal pero hoy por hoy no lo podrás ejecutar desde R (si desde python). Otras opciones que te recomiendo es probar con otros algoritmos, mira por ejemplo h2o (http://h2o.ai/) (2) Con esto te vale perfectamente RHADOOP y cualquier svm implementa...

Buen día a todos, Agradezco su ayuda con lo siguiente: Tengo 100.000 registros con nombres de personas con su respectivo número de documento, quiero identificar casos que tengan un porcentaje de igualdad alto, no del 100% porque ya esos los tengo identificados, sino casos como por ejemplo: Nombre: Juan Pérez Documento: 123456789 Nombre: Juan Pérez Documento: 1234056789 Este caso sería una

...ter de este tipo no es trivial....hay ejemplos comentado por ahí de cómo hacerlo en EC2 Amazon. o Puedes ejecutar procesos de machine learning en modo paralelo, pero solamente los que incluyen las librerías MLlib de Spark que no son todos los que hay disponibles en CRAN, no todos los algoritmos son paralelizables. Pero sí que se contemplan los de clúster, los glm, randomForest, gbm, survival, etc (http://spark.rstudio.com/mllib.html). También es capaz de distribuir trabajos sobre H2O, que también tiene básicamente las mismas librerías que las MLlib con el añadido de "deeplearning". o En este...

...: Javier Marcuzzi CC: r-help-es Asunto: Re: [R-es] Alto rendimiento Hola, ¿qué tal? Spark correría en tantos hilos como estuviese configurado a utilizar (con límite en los existentes). La promesa de sparklyr es que se trata de una mera interfaz que delega el procesamiento de datos en Spark. Spark paralelizaría (que de eso trata). Un saludo, Carlos J. Gil Bellosta http://www.datanalytics.com El 11 de octubre de 2016, 15:55, <javier.ruben.marcuzzi en gmail.com> escribió: Estimados En el sitio de https://www.rstudio.com/  hay un aviso sobre http://spark.rstudio.com/index.html ( sparklyr )....

...bug information in one .pdb file AFAIK. That would make our links much faster I think as people either are changing headers (and then they know they have to wait) or changing a single/few .cpp files. It would be great to group our 3k obj debug information in groups so that this linking steps can be paralelizable. Is there any support maybe for merging pdb with pdb util and then feeding that to lld-link instead of .obj debug info? I also re-read the post about ghash and it says blink links in 88s, the 28s you talk about is with unrelased optimizations only? On Tue, Jan 30, 2018 at 5:54 AM, Zachary Tur...

...file AFAIK. That would make our links much faster I think as people either >> are changing headers (and then they know they have to wait) or changing a >> single/few .cpp files. It would be great to group our 3k obj debug >> information in groups so that this linking steps can be paralelizable. Is >> there any support maybe for merging pdb with pdb util and then feeding that >> to lld-link instead of .obj debug info? >> >> I also re-read the post about ghash and it says blink links in 88s, the >> 28s you talk about is with unrelased optimizations only? &...

...ne .pdb > file AFAIK. That would make our links much faster I think as people either > are changing headers (and then they know they have to wait) or changing a > single/few .cpp files. It would be great to group our 3k obj debug > information in groups so that this linking steps can be paralelizable. Is > there any support maybe for merging pdb with pdb util and then feeding that > to lld-link instead of .obj debug info? > > I also re-read the post about ghash and it says blink links in 88s, the > 28s you talk about is with unrelased optimizations only? > > On Tue, Jan...

...ake our links much faster I think as >>> people either are changing headers (and then they know they have to wait) >>> or changing a single/few .cpp files. It would be great to group our 3k obj >>> debug information in groups so that this linking steps can be >>> paralelizable. Is there any support maybe for merging pdb with pdb util and >>> then feeding that to lld-link instead of .obj debug info? >>> >>> I also re-read the post about ghash and it says blink links in 88s, the >>> 28s you talk about is with unrelased optimizations...

...make our links much faster I think as >>>> people either are changing headers (and then they know they have to wait) or >>>> changing a single/few .cpp files. It would be great to group our 3k obj >>>> debug information in groups so that this linking steps can be paralelizable. >>>> Is there any support maybe for merging pdb with pdb util and then feeding >>>> that to lld-link instead of .obj debug info? >>>> >>>> I also re-read the post about ghash and it says blink links in 88s, the >>>> 28s you talk about...

You can make a PDB per lib (consider msvcrtd.pdb which ships with MSVC), but all these per-lib PDBs would have to be merged into a single master PDB at the end, so you still can't avoid that final . In a way, that's similar to the idea behind /DEBUG:FASTLINK (keep the debug info in object files to eliminate the cost of merging types and symbol records) and we know what the problems with

...> as > >>>> people either are changing headers (and then they know they have to > wait) or > >>>> changing a single/few .cpp files. It would be great to group our 3k > obj > >>>> debug information in groups so that this linking steps can be > paralelizable. > >>>> Is there any support maybe for merging pdb with pdb util and then > feeding > >>>> that to lld-link instead of .obj debug info? > >>>> > >>>> I also re-read the post about ghash and it says blink links in 88s, > the >...

...hen they know they have to >> >>>> wait) or >> >>>> changing a single/few .cpp files. It would be great to group our 3k >> >>>> obj >> >>>> debug information in groups so that this linking steps can be >> >>>> paralelizable. >> >>>> Is there any support maybe for merging pdb with pdb util and then >> >>>> feeding >> >>>> that to lld-link instead of .obj debug info? >> >>>> >> >>>> I also re-read the post about ghash and it sa...